[Piglit] [PATCH 05/13] cmake: Support CMakeLists.gles3.txt
Chad Versace
chad.versace at linux.intel.com
Wed Nov 28 13:08:57 PST 2012
On 11/28/2012 12:32 PM, Eric Anholt wrote:
> Chad Versace <chad.versace at linux.intel.com> writes:
>
>> Add "gles3" as a new api in PIGLIT_TOP/cmake/target_api. Now, you can
>> build GLES3 tests and libraries by placing the build rules in files
>> named CMakeLists.gles3.txt.
>>
>> I dislike the CMake hackery of havining multiple builds for each target
>> api. But, because GLES2 and GLES3 use different headers (gl2.h vs gl3.h),
>> until piglit-dispatch gains support for GLES the most sensible way to add
>> GLES3 support to piglit is to continue the tradition of adding a new
>> target api into PIGLIT_TOP/cmake/target_api.
>
> More per-api makefiles? D:
>
> What if the APIs were separated by subdirectories? It's not like we've got
> GLES tests under tests/spec/glsl-1.30.
But we do have extensions that are exposed in multiple api's, and it's
nice to have all tests in the same directory, spec/$ext_name. For example,
- spec/oes_compressed_etc1_rgb8_texture-basic.c is a GLES1 test
- spec/oes_compressed_etc1_rgb8_texture-miptree.c is a GLES2 test
A more fundamental reason is that, because we need to build a
libpiglitutil_gles3, there must be separate makefiles in tests/util
anyway due to CMake's lovely architecture. That is, unless we wish to
fork the tests/util directory and populate it with symlinks to common
files, which seems less desirable than simply dropping a new makefile
in the directory.
I don't like this mess either. But all alternatives look worse
than the current situation until piglit-dispatch gains GLES support.
More information about the Piglit
mailing list