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

[Emil Velikov]

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*

Interesting stuff :)

Emil