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

Chad Versace chad.versace at linux.intel.com
Mon Dec 1 10:17:00 PST 2014



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.
>  
>> Things are rather messy...
> 
> Yes, indeed. It's a mess.
> 


More information about the Piglit mailing list