Support #include

[torelode]

Thanks for a great vs code plugin! Would it be possible to add support for #include of other files, e.g. as in ARB_shading_language_include?

WebGL2 doesn't support said extension, but rolling my own mini-preprocessor would be way better then manual copy & paste duplicate code everywhere.

Alternatively, code injection could be extended to specify a file to inject, rather than just static text. This is not as flexible, but probably easier to do and still very useful.

[racz16]

Hello, and thank you for the kind words. The problem with ARB_shading_language_include - as you said - is that it's not a WebGL extension. I believe I support all the possible WebGL extensions, but I don't want to support desktop-only OpenGL extensions. There are 2 reasons for that: the first one is that I don't want to create a situation where you use a desktop-only extension, like including files, which seemingly works fine in VS Code, but it won't work in the browser. Because in WebGL you have to use the browser's built-in shader compiler, you can't use another compiler, generate SPIR-V, or do other things you can do with desktop OpenGL. The second reason is that I don't really have the time to add major features to the code, now I only do bug fixes and small updates. So I'm very sorry, but I can't support #include.

[matt-curtis]

I'd love something like this as well, even if it's implemented via comments:

//webglsleditor:include "something.h"

if a consensus could be reached on a possible design (configurable/opt-in via settings) I'd happily explore implementing it.

[matt-curtis]

glslify seems like a good candidate to support.

[dimateos]

glslify seems like a good candidate to support.

Maybe that would be too much browser centric?

The other two posted ideas seems more general and simple to me (plus reuses current code):

• Allow injecting from a local file specified in settings, on top of the current plain text. Kind of the same logic, open the file and paste the text.
• Somehow be able to trigger this same injecting logic per shader too, e.g. with a comment as suggested.
  • On top of the comment I would also support regular #include "file.glsl" for usability. This makes me think of another setting to specify the prefix that the extension should look for: //webglsleditor:include, #include or whatever the user specifies.

This seems promising :)

Passing the preprocessed includes to the glslValidator seem to avoid the problem with the error diagnostics noted in #30.

Basically you would need the -l to trigger full stage linking (only path in the CLI that supports #includes). But this changes the output format a bit (adds filename to the codeline) which breaks the current executeValidation addDiagnostic.

[matt-curtis]

Maybe that would be too much browser centric?

Yeah I can see that. I think glsify stood out to me because it has a lot of adoption. (Also technically, this extension is for WebGL which makes it sort of browser-centric.)

But I agree — I lean towards a user-configurable, prefix/comment-based system

[jimhigson]

vite-plugin-glsl also adds an #include. I think this is a very good feature to support, since writing shaders in a single file gets unmanageable quite quickly.

I think as a basic minimum but usable design, it could treat the included file as if it were inlined, using a permissive module resolution model that will be able to find the included files for the main implementations of #include.

[ChemistAion]

@torelode @matt-curtis @dimateos @jimhigson

#86 addresses the nested #include machinery and enables full, related editor processing features.

[matt-curtis]

@torelode @matt-curtis @dimateos @jimhigson

#86 addresses the nested #include machinery and enables full, related editor processing features.

Thank you @ChemistAion for working on this!