Proper ways to use external shader

[funatsufumiya]

First of all, I think this is a problem of zig dependency structure (probably related to ziglang/zig#14288, and this comment in it) , maybe not a problem of Delve Framework itself.

Description

I know that I can add custom shader by modifying Delve Framework source code itself.

However, when I use Delve Framework as a dependency of some application (with build.zig.zon and addModule("delve", ...) in build.zig), accessing children dependencies can cause problem, such as sokol.

At very first of additional.glsl.zig, we need to solve const sg = @import("sokol").gfx;, but if we add sokol as additional dependency besides to delve, causes error: file exists in multiple modules. (and additionally, using other commit-id's sokol, causes other problems.)

But, when exposes sokol in delve like below, we need to make a change in additional.glsl.zig: const sg = @import("delve").sokol.gfx; instead of const sg = @import("sokol").gfx;.

diff --git a/src/framework/delve.zig b/src/framework/delve.zig
index 0b621e3..0609032 100644
--- a/src/framework/delve.zig
+++ b/src/framework/delve.zig
@@ -87,6 +87,10 @@ pub const shaders = struct {

 pub const imgui = @import("cimgui");

+// sokol
+
+pub const sokol = @import("sokol");
+
 // initial setup. Call before any other Delve Framework functions!
 pub fn init(allocator: std.mem.Allocator) !void {
     mem.init(allocator);

( funatsufumiya@77a6ffb )

Modifying auto-generated .glsl.zig code would not be nice. So I'd like to know the proper way to use external shader ( and way to use sokol also in application ), without cloning source code of Delve Framework for each applications.

（There might be a way to properly handle sub-modules, and I will add it when I look into it. This article may be related.）

[funatsufumiya]

I tried fixing this by using addModule, but @import("sokol") can make conflicts in many places (between delve's dependency sokol and exposed sokol) if not using different names.

This would be hard problem to solve perfectly... (without zig itself's dependency tree support, or true solution of this comment in ziglang/zig#14288)

[Interrupt]

I ran into this myself recently in my test game. I had to add Sokol as another dependency which works but is not super ideal - if I tried to pluck the Sokol module out of the Delve module instead, that gave me the file exists in multiple modules error but just adding it as a base module seemed to work for some reason.

Commit where I added a custom shader is here:
Interrupt/super-boarding-party@a9042bd

[Interrupt]

Thinking about this more, the best thing to do for the moment would be to have the delve framework expose its sokol, and make a custom fork of sokol-tool that modifies one line to be the proper import for the delve framework: @import("delve").sokol

https://github.com/floooh/sokol-tools/blob/d54971ace95b014779b68140818c5e1ccffc6547/src/shdc/generators/sokolzig.cc#L14

Longer term, we could submit a PR to the sokol-tools project to make that header value overridable - flooh would appreciate that I'm sure.

[funatsufumiya]

just adding it as a base module seemed to work for some reason.

Commit where I added a custom shader is here:
Interrupt/super-boarding-party@a9042bd

Thank you for your information. This is valuable for me.

expose its sokol, and make a custom fork

I think so. In the meantime, it seems to be temporarily quicker that to write a shell script (or build.zig) to do that.

submit a PR to the sokol-tools project to make that header value overridable

Interesting. Sounds useful.

[funatsufumiya]

After I read around this comment (which I quoted manytimes before) in ziglang/zig#14288, this issue may be solved in zig 0.14.0-dev. (but no proof while I find exact issue tracker.)

Porting current code base into 0.14.0-dev would be a little hard work, but I'd like to check it if I had time.

[funatsufumiya]

@Interrupt
I finally found the easiest solution.

(1) add this single line to Delve Framework's build.zig

// Add sokol as module, using dependency module itself
try b.modules.put("sokol", dep_sokol.module("sokol"));

( see https://github.com/funatsufumiya/delve-framework/blob/1211a792c9795642f564ce6c6b9e1b7c8334acfd/build.zig#L117 for detail)

(2) now we can use sokol as delve's module (just like as delve), so we just add single line below to new application's build.zig

exe.root_module.addImport("sokol", delve_dep.module("sokol"));
// just like:
// exe.root_module.addImport("delve", delve_dep.module("delve"));

( see https://github.com/funatsufumiya/zig-delve-pbr-study/blob/25310f578f7a4d59df9cd21f96212a6ef6f685c7/build.zig#L48 as an example. )

This makes no conflict when using @import("sokol"). I apologize for my lack of knowledge.

[Interrupt]

Great find! That looks like the best way to do this, would you like to open a PR for that build.zig change, or should I make the change?

[funatsufumiya]

@Interrupt OK. Which dependencies should be exposed as modules like this in addition to sokol?