Zig also comes with a compilation toolchain for C/C++projects. Is there any way to make them dependencies in build.zig.zon without changing the original C/C++project?
Simply put, can Zig use projects built without build.zig as dependencies?
1 Like
Yes it does, in fact this is often how zig bindings for c/c++ libraries are made, having the upstream library as a depedency.
Often they will port that project to the build system, but that is not necessary.
1 Like
You might find the project you want in All Your Codebase · GitHub, these are just C / C++ projects that have been ported to the Zig build system.
I’ve also had some moderate success in using Zig only as a compiler for C++ projects and re-using a project’s cmake build system (just adding a preset that uses Zig as the C and C++ compiler). Moderate because I still have to use cmake which is atrocious.
You can also use system dependencies and link to those from your build.zig
1 Like
Edit: this is expanding on the reply by @vulpesx regarding adding the upstream project as a dependency.
For how to get the dependency, use zig fetch --save=<name> <url> to add it to your build.zig.zon. Then access it in your build.zig with const dep = b.dependency("<name>", .{});. From there you can e.g. dep.path("some/path/to/foo.c") to get a LazyPath to a file relative to the root of the fetched content.
This is pretty handy for grabbing small C projects or single file header libraries without vendoring them (at least one stb header seems to find its way into most of my projects 
). I can’t comment on how practical this is compared to forking + vendoring for larger projects such as SDL, however.
3 Likes
If you only need a couple of files, adding the repository to your build.zig.zon and accessing the files is quite easy, like others showed. But since you mentioned the fact that Zig has a C/C++ compiler, you are probably interested in large projects that use Make or CMake. Sadly, the answer is that you’re going to have to recreate their build process. People have already mention All Your Codebase. It’s great if the project you’re interested is already there, but if not, you can still use it as an example.
For the most part, you’re going to add all C/C++ source files (.c, not .h) to a module, add all include paths and link whatever is necessary. Header files can be auto-translated via translate-c, or you can manually write your bindings. Zig can generate headers from templates (template.h.in), but you’re going to need to fill in the necessary details, most of which are features present in the host system or the target.
I’m looking forward to the day someone is going to write a make and cmake emulator that can be baked into Zig. What a dream that would be.
1 Like
I would still do this for large dependencies, the only time I would fork it is if I needed to change the source, or upstream is open to using the zig build system.
Whether you fork it or not, the process is almost identical.