mesa/src/glsl/glcpp at da7f226a2711450bf92dcc9e2e1e1052111683ff - mesa

Files

T

Carl Worth da7f226a27 glsl/glcpp: Fix to emit spaces following directives

The glcpp lexer and parser use the space_tokens state bit to avoid emitting
tokens for spaces while parsing a directive. Previously, this bit was only
being set again by the first non-space token following a directive.

This led to a bug where a space, (or a comment that should emit a space),
immediately following a directive, (optionally searated by newlines), would be
omitted from the output.

Here we fix the bug by also setting the space_tokens bit whenever we lex a
newline in the standard start conditions.

2014-07-29 15:11:48 -07:00

tests

glsl/glcpp: Fix to emit spaces following directives

2014-07-29 15:11:48 -07:00

.gitignore

glcpp: Add back tests/*.out to .gitignore

2013-01-11 11:49:33 +01:00

glcpp-lex.l

glsl/glcpp: Fix to emit spaces following directives

2014-07-29 15:11:48 -07:00

glcpp-parse.y

glsl/glcpp: move macro declaration before code to fix MSVC build

2014-07-10 08:08:10 -06:00

glcpp.c

glcpp: Rename the variable used to enable debugging.

2014-01-31 10:02:58 -08:00

glcpp.h

glsl/glcpp: Once again report undefined macro name in error message.

2014-07-09 12:05:13 -07:00

pp.c

glcpp: Resolve implicit GLSL version to 100 if the API is ES.

2014-01-27 21:15:35 -08:00

README

glcpp: Update README for new support of __LINE__ and __FILE__.

2012-11-29 13:03:02 -08: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).