On 11/28/2012 12:32 PM, Eric Anholt wrote: > Chad Versace <[email protected]> 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. _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
