Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#include directive support #46

Merged
merged 5 commits into from Aug 5, 2015

Conversation

antiagainst
Copy link
Contributor

These commits add #include directive support in glslang. We
use a flexible mechanism so that different contributors can
have different implementation for file searching and #include
directive substitution. (A ForbidInclude is supplied though.)

Please refer to individual commit messages for more details.
This fulfills the third step mentioned in Issue #37.

Dejan Mircevski and others added 4 commits July 31, 2015 19:41
When an include directive is recognized by the preprocessor, it
executes a callback on the filepath argument to obtain the file
contents.  That way the compilation client can deal with the file
system, include paths, etc.

Currently only accepts quoted filepaths -- no angle brackets yet.
This patch introduces a new extension, GL_GOOGLE_include_directive,
to enable support #include directives. It depends on the extension
GL_GOOGLE_cpp_style_line_directive.
After parsing a #include directive, we push a TokenizableString
which contains the content of the included file into the input
stack. Henceforth, tokens will be read from the newly pushed
TokenizableString. However, the scanner in TParseContext still
points to the previous input stream. We need to update the scanner
to point to the new input stream inside TokenizableString. Thus,
the setCurrent{String|Line|..} method in TParseContext updates
the status of the correct input stream. After finishing the newly
pushed TokenizableString, we need to restore the scanner to the
previous input stream.
Also changed the includer interface to let it return the actual
full path of the included file.
@johnkslang
Copy link
Member

Cool stuff.

One simple concern: It seems easy to accidentally not use the preprocessor version of requireExtensions() et. al. There is now ppError() and error(). Would it be safer if there was also ppRequireExtensions() and requireExtensions(). Seems that would be better, due to consistency and clarify, assuming it could be done without too much code duplication of the internals of requireExtensions().

Thoughts?

Thanks.

Now extensions required by preprocessor should be checked via
the ppRequireExtensions method. This is more clear and coherent
with the rest of the code.
@antiagainst
Copy link
Contributor Author

@johnkslang: Yeah, agreed that a separate ppRequireExtensions is more coherent with the rest of the code. I've pushed out a new commit for that.

johnkslang added a commit that referenced this pull request Aug 5, 2015
@johnkslang johnkslang merged commit d618070 into KhronosGroup:master Aug 5, 2015
@antiagainst antiagainst deleted the include-directive branch August 5, 2015 16:46
qingyuanzNV pushed a commit to qingyuanzNV/glslang that referenced this pull request Oct 18, 2022
…inker

Register the Khronos SPIRV-Tools Linker
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants