[Piglit] [PATCH] util/gl: link against OPENGL_gl_LIBRARY on waffle aware systems

[Chad Versace]

On 12/03/2014 05:16 AM, Emil Velikov wrote:
> On 01/12/14 18:17, Chad Versace wrote:
>>
>>
>> On 12/01/2014 09:41 AM, Chad Versace wrote:
>>> On 11/26/2014 01:11 AM, Emil Velikov wrote:
>>>
>>>> Things are not as black and white as you might think. Most of piglit
>>>> uses what I call "target-less rules", which means that when one does
>>>>
>>>>    add_definitions ( -DPIGLIT_USE_GLX )
>>>> or
>>>>    link_libraries(${OPENGL_gl_LIBRARY})
>>>>
>>>> the rule is applied for up-to XX (don't remember the limit) cmake files.
>>>> Meaning that despite the PIGLIT_USE_GLX define being inside
>>>> tests/util/CMakeLists.gl.txt it will be applied when building any of the
>>>> es* targets.
>>>
>>> Nope. Piglit has multiple CMake files per directory exactly to circumvent
>>> that CMake behavior. Each target-less rule (add_definitions, link_libraries, etc)
>>> that occurs in an api-tagged CMake file (such as CMakeLists.${api}.txt) applies
>>> to that CMakeLists and, for all subdirectories, to each CMakeLists with the *same* api tag.
>>>
>>> Suppose you have the two files below:
>>>
>>>
>>>   # file: tests/foo/CMakeLists.gl.txt
>>>   add_definitions(-DA_MACRO_ONLY_FOR_GL_BUILDS)
>>>
>>>   # file: tests/foo/CMakeLists.gles2.txt
>>>   add_definitions(-DA_MACRO_ONLY_FOR_GLES2_BUILDS)
>>>
>>> Then the GL build does not see A_MACRO_ONLY_FOR_GLES2_BUILDS and the
>>> GLES2 build does not see A_MACRO_ONLY_FOR_GL_BUILDS.
>>>
>>> Well, at least that's how everything worked when I created Piglit's
>>> api-suffixed CMake files. If they no longer work like this, then I'd
>>> like to know why it was changed.
>>>  
> If it still works as described, then I would assume that something fun
> as the following is happening:
> - CMakeLists.gl.txt builds tests/util/piglit-dispatch.{c,o}
> - CMakeLists.gles*.txt reuses the built object, effectively
> ignoring/invalidating the defines set in the buildfile.
> - piglitutil_gles* ends up using glXGetProcAddress*

Nope, because...

> Interesting stuff :)

Piglit's CMake is absurdly interesting ;)

In your example, test/util/piglit-dispatch.c gets built once per
CMakeLists.${API}.txt. No object files get re-used across API boundaries.
Here's the exactly what happens with piglit-dispatch.c:

  $PIGLIT_TOP/tests/util/piglit-dispatch.c -> CMakeLists.${API}.txt -> $PIGLIT_TOP/target_api/${API}/tests/util/CMakeFiles/piglitutil_${API}.dir/piglit-dispatch.c.o

Earlier this year I began working on consolidating Piglit's build system so that each file would be built at most once, but disatractions pulled me away from that project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20141203/867f5c05/attachment.sig>