mesa/src/compiler/glsl/glcpp
Daniel Stone c60cea0daa glsl/test: Don't run whitespace tests in parallel
For some unfathomable reason, three out of these four tests often time
out when running within CI. On the assumption that there is some
parallelisation badness happening rather than the non-UNIX tests
entering infinite loops, try just marking them as serial-only.

This should have a negligible impact on runtime since they are quick to
execute.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6301>
2020-08-17 17:44:26 +00:00
..
tests tests: Make tests aware of meson test wrapper 2020-05-20 17:57:15 +00:00
glcpp-lex.l glsl: add preprocessor #include support 2019-11-20 05:05:55 +00:00
glcpp-parse.y glsl: fix crash on glsl macro redefinition 2020-06-10 03:29:39 +00:00
glcpp.c Fix scons build 2018-04-12 19:55:01 -04:00
glcpp.h glsl: add preprocessor #include support 2019-11-20 05:05:55 +00:00
meson.build glsl/test: Don't run whitespace tests in parallel 2020-08-17 17:44:26 +00:00
pp.c glsl: pass gl_context to glcpp_parser_create() 2019-11-20 05:05:55 +00:00
pp_standalone_scaffolding.c mesa: add support cursor support for relative path shader includes 2019-11-20 05:05:56 +00:00
pp_standalone_scaffolding.h mesa: add support cursor support for relative path shader includes 2019-11-20 05:05:56 +00:00
README

glcpp -- GLSL "C" preprocessor

This is a simple preprocessor designed to provide the preprocessing
needs of the GLSL language. The requirements for this preprocessor are
specified in the GLSL 1.30 specification availble from:

http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.10.pdf

This specification is not precise on some semantics, (for example,
#define and #if), defining these merely "as is standard for C++
preprocessors". To fill in these details, I've been using a draft of
the C99 standard as available from:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Any downstream compiler accepting output from glcpp should be prepared
to encounter and deal with the following preprocessor macros:

	#line
	#pragma
	#extension

All other macros will be handled according to the GLSL specification
and will not appear in the output.

Known limitations
-----------------
A file that ends with a function-like macro name as the last
non-whitespace token will result in a parse error, (where it should be
passed through as is).