mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-24 21:28:10 +02:00
ea373f03e8
Everyone at the Khronos meeting was as surprised that GLSL didn't already support this as we were. Several vendors said they'd ship it, but there didn't seem to be enough interest to put in the effort to make it ARB or KHR. v2: Fix a couple typos and rename the spec file to EXT_shader_integer_mix.spec. Suggested by Roland. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitignore | ||
| glcpp-lex.l | ||
| glcpp-parse.y | ||
| glcpp.c | ||
| glcpp.h | ||
| 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 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).