sokol glsl included examples gave build error

[tehando]

vmodules: /user_name/.vmodules
vroot: /user_name/v
vexe: /user_name/v/v
vexe mtime: 2022-10-19 13:49:14
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.1 71bff21.d781396
Git version: git version 2.38.0
Git vroot status: weekly.2022.41-27-gd7813965
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3

platform = Linux-6.0.2-arch1-1-x86_64-with-glibc2.36
glslang package version 11.11.0-1

What did you do?
$ v run cube_glsl.v

What did you expect to see?
run like 01_cubes example

What did you see instead?
[user_name 02_cubes_glsl]$ v run cube_glsl.v
builder error: 'cube_glsl.h' not found

[Larpon]

Run v shader . in the same directory. The shader code needs to be generated before first run

[tehando]

After v shader . command, all glsl example worked. You can close this issue. Lastly is it mandatory step to build this or should we write any build script? Is it possible to automate it with single command?

[JalonSolov]

It is a mandatory step that it be done, but it would be nice if the error message told you what to do, instead of just saying that the file wasn't found.

[Larpon]

It is a mandatory step that it be done, but it would be nice if the error message told you what to do, instead of just saying that the file wasn't found.

Fully agree - I'm simply clueless as to how we should detect it since it's an #include entry and we have no chance of knowing if a header include is shader code 🤷🏻‍♂️

Maybe a special #shader ... entry?

[JalonSolov]

@spytheman (or someone equally talented) added a feature where you can put an extra "comment" after the #include, that gets displayed if the include isn't found... like this one from the V source:

 #include <X11/Xlib.h> # Please install a package with the X11 development headers, for example: `apt-get install libx11-dev`

[JalonSolov]

Even if it isn't displayed automatically, it would be good to have that where needed, so people know what to do.

[Larpon]

That's nice, but requires all programmers to be consistent and have good discipline when they include shaders in their code. It's easy for the V project to add this to our examples - but in the wild this approach will have mixed end user experiences. I can only think of solutions where the compiler needs to know it's handling shaders. If it knows, it would also open the door for it to compile the shaders automatically, and completely eradicate the need for users to manually run v shader (on supported hosts, ofc).

I think this is a separate issue and need it's own issue, that's why I closed it, btw