Right, that’s the part I’m trying to figure out, and almost wonder if they need to be in separate build.zig files.
All of the C headers are implementation details within the library (currently, they’re all specific to wayland.zig). None of them will be used outside the library, no user should care that C files are used.
So forcing the user (or in this case, the example executable) to include them to be able to compile is not desirable.
I’ve used Zig packages in the past that internally had C headers (like GLFW wrappers), and didn’t have to deal with this, but I’m assuming that having everything in the same build.zig is making that separation more difficult?
I think you may need to use something like this used in raylib:
For the headers which are used with the cImport, it seems to me that the installHeader-headers are then accessible for later dependencies so if you add installHeader lines to your lib for the headers needed by your cImport in your module, I think that may make those headers availailble for use in the cImport and people may be able to just depend on your module.
That is my current guess, but I don’t know the details of how installHeader works and if this would be the correct/idiomatic way to bundle this stuff.
I don’t really think that it needs to be a separate build.zig.
If installHeader doesn’t work, I guess we will have to look at other projects or wait for somebody who has a bit more knowledge about these things.