If you’re anything like me, you were probably somewhat overwhelmed by the build system when you started out with Zig—powerful, yes, but daunting with all that build.zig scripting. That’s where zbuild comes in. It’s an opinionated tool that swaps out the featureful-but-verbose script for a clean, JSON-based config (zbuild.json), letting you define your project’s builds declaratively while it generates the Zig build files for you. Think simpler setup, less boilerplate, and even IDE support with a schema for validation. It’s still evolving (check the GitHub for the latest), but if you’re looking to streamline your Zig workflow—or just dip your toes in without drowning in build code—zbuild might be worth a spin!
Yea thats fair.
It essentially exposes a subset of the build system and acts as a thin wrapper around zig build/zig fetch. It’s not introducing any additional concepts into the mix. So for a power-user, the utility would be the conciseness and consistency.
I think like the xkcd and history in other programming languages suggest, it is probably inevitable that there will be many different variants on tooling that will be explored by the community.
So even though I don’t quite agree on something like this being needed, I also can see how tools like this allow to explore different design decisions and customize based on personal preference, maybe even inspire specific features that didn’t exist previously.
So welcome to the forum, don’t let me stop you and hopefully my opinion didn’t come across harshly!
I do expect we’ll eventually see something a lot like this, but in Zon, as a widely-used DSL for handling undemanding build scripts.
I have a real dislike for JSON as a configuration language, it’s ok (not great) for its original purpose of sending data around networks, but it has many features which a sane configuration language would never choose.
It’s good that the space is being explored, the JSON is a dealbreaker for me but that’s a matter of taste. If you ever decide to port it to Zon that would be a different story. It has comments, and isn’t a sadist about commas. To name a couple of things.
Something any good system like this must be able to do, is preserve customization of build.zig beyond what the DSL is able to provide. This is a difficult problem, but without solving it, the system is just scaffolding, used to build simple projects but tossed away as soon as the need for a Turing complete language manifests, as it so often does.
as a widely-used DSL for handling undemanding build scripts.
Yesss exactly the idea. Simplify the common cases.
I come from the javascript ecosystem (pls don’t stone me) and part of the motivation for this project was to try to emulate the comparatively easy experience of building, managing packages and dependencies in a nodejs monorepo. By comparison, the zig experience is very raw. (I guess thats what several decades and millions of developer-hours head start will get you)
I just went with JSON to flesh out the idea, also not a fan of how strict it is. (I wish std.json supported JSONC.) Originally, I was thinking about YAML but fell back to JSON when I saw it wasn’t in std. But YAML is no panacea either, being such a huge and meandering spec.
Definitely an interesting and good idea to use Zon, it wouldn’t be too hard to port it over.
Something any good system like this must be able to do, is preserve customization of build.zig beyond what the DSL is able to provide. This is a difficult problem, but without solving it, the system is just scaffolding
Yup, the current implementation is only the scaffolding as you say. Any customization of build.zig would either mean tossing the DSL away after the initial codegen or boxing up the customization into a separately-managed subdirectory dependency.
If anyone has any ideas here, definitely interested in hearing them.
By comparison, the zig experience is very raw. (I guess thats what several decades and millions of developer-hours head start will get you)
A big part of it just comes down to the kind of development you’re doing and what the expectations are for that kind of development process, not hours spent working on it.
Coming from the C ecosystem, which probably has a comparable amount of developer hours poured into it, Zig is a big improvement in many areas and about par for the course in the rest.
I’d much rather write Zig than CMake at this point, for example.
the kind of development you’re doing and what the expectations are for that kind of development process
Definitely. For example, developing a Zig wrapper around a C library often requires compilation flags / c macros, linked objects, etc to be set conditionally based on compilation target, etc. Every project there may be unique.
But for “vanilla libraries” (for example, a library implementing some datastructure) the amount of conditional linking and other complex build rules is approximately zero. Especially on day 1 of a project. It’s for these cases that this project exists.
Coming from the C ecosystem … Zig is a big improvement in many areas
After this project, I have a lot more love for the build system. It’s extremely powerful, and as an alternative for the C ecosystem and its patchwork of tooling, its a godsend.
Awesome. I was really missing something like this. Coming from rust, I much prefer the rust way where you work with cargo by default and then drop down to a build.rs for when needed.
I’ll be exploring this.
