libXext libfontenc libXau libX11 libXinerama mesa libXdmcp git update 28 jan 2011

1 files changed, 32 insertions, 55 deletions

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