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
_______________________________________________
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
