Anders StenbergMar 7

I've got a Zig question if anyone out there happens to know.

I'm wrapping the wgpu_native library into a zig build system package like in the screenshot. This works and can be consumed by another project.

However, I want to _also_ package a file (include/webgpu/webgpu.h) along for the consuming project to be able to use. (I have another wrapped C library that uses webgpu as well that needs to include that header when building.) How would I do that?

#zig #ziglang

Show threadLoris Cro ⚡

@SonnyBonds You have two main kinds of consumers: Zig and C (either directly or FFI). For the former you want to create zig modules, like you are doing in the screenshot, while for the latter you want to create libraries (b.addLibrary), which will also install headers that you specify via installHeader. Zig users don't need header files if you give them a translate-c module.

I've recently made this package that you can use as a reference https://github.com/allyourcodebase/rnnoise notice how I'm creating:

- a module that contains the full implementation (+ the translate-c output as the root file)
- a module that only contains translate-c definitions in case that the user just wants those and plans to use a system-provided dynamic library
- static and dynamic library artifacts for non-Zig consumers, which also install public header files.

The only thing that I'm missing in that package is system integration options, which I have yet to really learn how to use.

GitHub - allyourcodebase/rnnoise: https://github.com/xiph/rnnoise

https://github.com/xiph/rnnoise. Contribute to allyourcodebase/rnnoise development by creating an account on GitHub.

GitHub
Mar 7 at 11:18amWeb
Show threadAnders StenbergMar 7

@kristoff Thank you, your description sounds like I've understood it so I must've just got some detail wrong. That package sounds like basically the same kind of setup as I want so I'll have a look at that.

(I know my example had just the Zig module, but I've tried having a library in parallel. But yeah, apparently did something wrong.)

Show threadAnders StenbergMar 7
@kristoff To be exact, this is the part after that initial screenshot:
Show threadAnders StenbergMar 7

@kristoff Managed to get it working. This part was correct, it was the consuming end that did it wrong. The path I needed to grab was not the module path, but "emittedIncludeTree". Like this:

consuming_module.addIncludePath(wgpu_dep.artifact("wgpu").getEmittedIncludeTree());

Show threadLoris Cro ⚡Mar 7
@SonnyBonds usually if you're going down that path you just do `mod.linkLibrary(wgpu_dep.artifact("wgpu"))` and that also adds the include paths, but if you want only the header file that's one way. Another is to do `mod.addIncludePath(wgpu_dep.path("path/to/headers")`
Show threadLoris Cro ⚡Mar 7
@SonnyBonds correction, since in your case wgpu_lib is the upstream project, then you would have to do something along the lines of `wgpu_dep.builder.dependencies("wgpu_lib", .{})`. This is the super manual version where you reach for your dep's dependenncies. There are less invasive methods where you expose a path to consumers (similarly to how you can expose modules and artifacts) but at this point your method seems preferable (if you want only the header files, if you want the full lib you can just linkLibrary).
Show threadAnders StenbergMar 7

@kristoff linkLibrary works and definitely feels like the Way It's Meant To Be Played. I feel like I've tried that already, but the stars probably were misaligned some other way then.

Thanks for the pointers! Feels like things are like they're supposed to be now.