Apologies if the question was already asked and answered and I couldn’t find it.
For my vulkan experiment project, I am trying to add a asset library.
This library contains a zig module (the public API) and depends on C source code (compression library etc).
This asset “system” needs to be added to two executable. On is an asset converter (from all sort of formats like obj and png etc) to a processed and compressed format.
The other one, is the main exe that needs to load and uncompress those processed assets.
My first idea was to use a module, but modules don’t have a way to carry C dependencies. That would mean - unless I am missing something - that I would need to add the C source files/libaries to both exes to link.
One alternative would be to make the asset code into a static/dynamic library.
However, that means I also need to create a module for the zig code to import in the exes.
I am wondering if there is a better way create a single “dependency” that carries the zig module and C in a single step.
If that is not possible, I am interested to know what is the conventional wisdom about the best way to deal with a similar scenario
1 Like
I am no expert in the Zig build system, but I think that one static library and one module which are then added to each exe is probably the way to go.
You could group the C library and Zig module into a directory with its own build.zig and add that as dependency to the exe project(s) via a build.zig.zon or just std.Build.anonymousDependency. This doesn’t really solve your problem though since I believe that you would still need to grab the library and module from the dependency and then link/add them to each exe.
I suppose that you could write a function taking a compile step that goes through the dependency adding the modules and linking the libraries. Probably way overkill for adding a module and a library to two exes though.
Why is that a problem? Ultimately, each compiled executable is ging to have a copy of the library in its binary. That’s unavoidable, unless you put the common code in a shared library.
1 Like
It is not really a problem and as long as itś just a couple of exes and libraries that is fine.
Just more of a scalability issue as a project either gets more dependencies or you try and share this code between different projects. You have to remember to add the module and the library and the include directories everywhere.
Even making the logic into a function, if you share it as a package you’d have to explain your user how to use your package.
Those kind of custom logic might end up hurting an ecosystem, as anyone that had to deal with several cmake packages knows 
But then again, there might be some really obvious solution or workaround I am not aware of or I haven´t thought about yet.
1 Like
Yeah, the distribution side of Zig still requires some work…