[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