From cacf23d832a26e35851c9cc666304ac72cf8fe34 Mon Sep 17 00:00:00 2001 From: marha Date: Sat, 29 Jan 2011 18:43:24 +0000 Subject: libXext libfontenc libXau libX11 libXinerama mesa libXdmcp git update 28 jan 2011 --- mesalib/src/glsl/glcpp/README | 87 ++++++++++++++++--------------------------- 1 file changed, 32 insertions(+), 55 deletions(-) (limited to 'mesalib/src/glsl/glcpp/README') diff --git a/mesalib/src/glsl/glcpp/README b/mesalib/src/glsl/glcpp/README index 9cc00e927..735b27d44 100644 --- a/mesalib/src/glsl/glcpp/README +++ b/mesalib/src/glsl/glcpp/README @@ -1,55 +1,32 @@ -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). - -Known deviations from the specification ---------------------------------------- -As mentoned above, the GLSL specification (as of 1.30.10) is fairly -vague on some aspects of the preprocessor, and we've been using C99 to -fill in details. Here is a list of cases where we have deviated from -the behavior specified in C99 to obtain better compatibility with -other GLSL implementations: - - * Redefining a macro with a different value - - C89 says that a macro "may be redefined ... provided that the - second definition [is equivalent]" (Section 3.8.3 Macro - Replacement/constraints) - - C99 is even more explicit, saying tthat a macro "shall not be - redefined by another #define preprocessing directive unless the - second definition [is equivalent]" (Section 6.10.3 Macro - Replacement/Constraints) - - In spite of this, glcpp emits a warning rather than an error for - non-equivalent redefinition of macros since this matches the - behavior of other, widely-used implementations. +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). \ No newline at end of file -- cgit v1.2.3