On Thu, Feb 27, 2014 at 2:43 PM, Dylan Baker <[email protected]> wrote: > This small series replaces glsl_parser_test.py's standalone > functionality with a small utility script for running a single > glslparsertest. > > The output of this file is less than ideal, however, that is becasue > core.Test does some very silly things with the output of a test. That is > a patch for another day. > > I'm not set on where to put the utility files, Fabian suggested that it go > in tests/ somewhere, I like the idea of keeping little utilites > together (I'd like to move generate-glean-test.py, > piglit-print-commands.py, and piglit-merge-results.py into the utils > folder as well), and putting them in tests feels odd to me, since that > is a folder for tests, not little utilities.
These ideas may be apparent to everyone, but thought I'd mention them anyways: Piglit is composed of 2 largely unrelated bits -- a bunch of tests for various opengl/etc functionality, and a framework to run tests (which, perhaps not entirely coincidentally, are those very same opengl/opencl/etc tests). There is a funny overlap region, which sets up mechanisms to run individual tests which are fancier than just "execute this command". But the fact that opengl tests are executed is dictacted by passing in tests/all.py as the "seed the tests" file. I instead could pass in /path/to/other_file.py which would add tests to the framework that are of an entirely different nature, and as long as those tests abide by the API for returning results, the framework would be none-the-wiser. IMHO GLSLParserTest does not belong in framework at all, and should instead be in tests (perhaps tests/util or tests/bin). Similarly for ShaderTest -- the reason it exists at all seems to be to determine whether a particular shader test is GL/GLES2/GLES3 and execute the appropriate binary. And it's advantageous to have only one of those due to the regex compiling... but it's not exactly a surprise to the author of a shader_test which API it specifies (be it a human being or a python script), one could certainly imagine using diff extensions for the diff ones, much as diff binaries are used. Looking through glsl_parser_test.py -- import_glsl_parser_tests/add_glsl_parser_test seems like it'd belong in tests/all.py. Most of the rest is concerned with parsing the test file to provide appropriate options to the glslparsertest command. This seems like it'd belong in tests, and all.py would just add executors for the python wrapper script. All of this would take a lot of refactoring/changing, so feel free to ignore. (And also, I'm just a newcomer with crazy ideas, so feel free to ignore for that reason as well :) ) Just providing my 2c... Cheers, -ilia _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
