mesa/src/glsl/glcpp
Olivier Galibert 199771bc32 glsl: Scaffolding for ARB_shader_bit_encoding.
That adds support for activating the extension.  It doesn't actually
*do* anything yet, of course.

Signed-off-by: Olivier Galibert <galibert@pobox.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-07 00:06:00 -07:00
..
tests glsl: Add glcpp tests for a macro used twice 2012-02-02 12:05:21 -08:00
.gitignore Add .deps/, .libs/, and *.la to toplevel .gitignore 2012-03-20 11:50:50 -07:00
glcpp-lex.l glcpp: Fix so that trailing punctuation does not prevent macro expansion 2012-02-02 12:05:21 -08:00
glcpp-parse.y glsl: Scaffolding for ARB_shader_bit_encoding. 2012-06-07 00:06:00 -07:00
glcpp.c
glcpp.h glcpp: Don't strlen() the output for every token being printed. 2012-02-28 13:07:12 -08:00
pp.c
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 handles according to the GLSL specification
and will not appear in the output.

Known limitations
-----------------
The __LINE__ and __FILE__ macros are not yet supported.

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).