How to zig a C project?

A few weeks ago Andrew and Kristoff made a video about converting C projects/libs to the Zig build system. There was a very clear explanation by Andrew about how the cache system works and explanation about the different conversion approaches. Anyway, for a stupid person like me, that was a precious source of information but for some reason, twitch videos are ephemeral and now it’s all gone.

One approach was to fork the C project/lib and add a build.zig to it. What was the alternative?


I don’t know the video you’re referring to, but in the official build system documentation, there were some unfinished sections related to package management, one of them being related to packaging a C library, and the subheadings listed two approaches: one is the fork approach you’re referring to, and the other is titled the “pristine tarball strategy”.

What I believe this is referring to is the ability of the Zig package manager to fetch non-Zig dependencies (e.g. plain tarball distributions of C libraries) and then refer to files and directories within them using std.Build.Dependency.path, which returns a std.Build.LazyPath referring to the path within the package.

Here’s an example of a PR I made to a project a little while ago to convert it from the fork strategy to the tarball strategy: Update to latest Zig master and use package manager by ianprime0509 · Pull Request #1 · mitchellh/zig-build-libxml2 · GitHub Here, the build.zig.zon has a libxml2 dependency which fetches an upstream release tarball as-is: zig-build-libxml2/build.zig.zon at update-zig · ianprime0509/zig-build-libxml2 · GitHub This tarball doesn’t have any build.zig, so it has to be treated as a plain bundle of files. Since most build-related functions use LazyPath to refer to paths, you can then pretty much just write your build.zig as you would if you forked the project, but replace LazyPaths like .{ .path = "foo/bar" } with upstream.path("foo/bar") so they refer to the path within the tarball you fetched (example: zig-build-libxml2/build.zig at update-zig · ianprime0509/zig-build-libxml2 · GitHub).

There are pros and cons to both approaches. If you’re going to be maintaining the project long-term and making changes to it, I think the fork strategy makes sense; on the other hand, if all you want to do is package an existing library without changing any of its code, I think the upstream tarball approach is better, since it makes it easier for you as a maintainer to manage updates from upstream and for users to verify that no changes have been made to the upstream sources.