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.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit

Reply via email to