[Piglit] replace glslparsertest standalone functionality

[Ilia Mirkin]

On Thu, Feb 27, 2014 at 2:43 PM, Dylan Baker <baker.dylan.c at gmail.com> 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