[Feature Request] Controlling the extension with comments

[Clocktown]

When developing shaders, it is common to split one shader into multiple files, reuse files, and generally generate some parts of Code in the application in order to make things easier.

Unfortunately, this does not go well with extensions like this that compile these files without any knowledge about what happens on the side of the application. Thus, I propose to add functionality to accomodate these issues. Ultimately, this will be comments that are transformed into Code before compiling.

Shader includes

When using shader includes (either using the GLSL extension or by manually processing shaders), things can get wrong. Especially when using the GLSL extension, the path inside the Shader may not actually map to the filesystem on disk:

#include "/utils.glsl" // Actually located at ../include/utils.glsl

I thus propose to be able to add the real location to that file in a comment, like so:

#include "/utils.glsl" //! ../include/utils.glsl

Instead of a !, any kind of identifier could be used.
Using this, you could load the referenced include when compiling, which will then not produce errors.

Missing version, work group size, defines...

Sometimes, we may only add #version, compute work group sizes or some defines used in a shader from the application, without writing it in the actual source. It would be nice if we could specify these inside of comments, such that this extension can use these and compile without errors, e.g.:

//! #version 430
//! #define WORK_GROUP_SIZE 32

A note on !

It would probably be a good idea to have two different identifiers, e.g. ! and ?. ! would always be expanded to code, while ? would only be expanded if the file being compiled has not been included, e.g.:
File A.glsl

//? #version 430 // Only expanded if this file is compiled directly, not when included in B.glsl
// Lots of utility functions

File B.glsl

//! #version 430
#include "/utils.glsl" //! A.glsl

[danielscherzer]

Nice idea! If I understand correctly the include case is special, because here I would have to replace everything inside the quotation marks with the code behind the "//!", but otherwise it should be a removal of "//!" and what remains should be valid code. Do I understand this correctly?

[Clocktown]

Yes, you got that right.

And btw: I really like that you chose to create a proper GL Context to check errors. Atom's glsl-linter only uses the reference compiler, which leaves no hope for many things.

[danielscherzer]

Thanks! I'm still thinking about the #include special case...
One could remove this special case by the following augmented replacement rule:
If an //! is present in a line , the code before the //! is removed and replaced by the code behind the //!. So #include "/utils.glsl" //! #include "../include/utils.glsl" becomes #include "../include/utils.glsl", which should resolve your use case and maybe this comes in handy for other usage scenarios. What do you think?

[Clocktown]

Yes, I think your idea will suffice. And it is certainly easier to implement.

[danielscherzer]

Ok. I think I have a working implementation. I will push it after updating the readme. Are you ok if I take some of your explanation text from above for an updated readme?

[Clocktown]

Yes, that's okay