pico-zdk, it uses a custom build runner to get paths to the produced build artifacts since othewise you just gotta guess.
The new maker code already has everything needed to return this information but its not included in the build graph output nor is it possible to write your own maker, despite what Andrew had said on his stream :/
I’m confused. Zig’s build system APIs are quite powerful, and this blog post covers approximately none of that. How are you jumping to a take like this from a blog post discussing one specific implementation detail?
edit: I see from your profile you’re a solutions engineer at a company selling Bazel; your income is literally dependent on seeing a nail (build systems) and using your hammer (Bazel). I’ll assume your comment is in good faith, but you should know that the way you wrote it, I wouldn’t blame anyone for assuming otherwise.
Zig’s build system is pretty fundamentally just a content addressed build graph. It has a lot of APIs for Zig-specific stuff, but you can build any C project too. It is heavily cached, supports incremental rebuilds, and while it’s possible to break the ‘hermetic seal’ if you want, by default it for all practical intents and purposes is (hermetic).
This blog post is describing the separation of what used to be one compilation unit of “your build script” into “your build script that generates a declarative build configuration” and “the standard library builder that consumes said configuration”.
All of the build powers outlined before still hold.
As someone literally tinkering with hermetic builds on Zig’s build system à la Nix or Bazel, I would say it is at least as powerful, as a primitive, as either. I would even go further to say that it is more powerful, because you’re also getting a bootstrapped C compiler, linker, etc in the same binary.
Jan200101 | 9 hours ago
this breaks one of my projects which relied on deeper build system integration :(
xq | 8 hours ago
which one is it, and what exactly breaks?
Jan200101 | 5 hours ago
pico-zdk, it uses a custom build runner to get paths to the produced build artifacts since othewise you just gotta guess.
The new maker code already has everything needed to return this information but its not included in the build graph output nor is it possible to write your own maker, despite what Andrew had said on his stream :/
sluongng | 11 hours ago
This feels very primitive compare to https://github.com/hermeticbuild/rules_zig, the Bazel build rules for Zig.
rvrb | 3 hours ago
I’m confused. Zig’s build system APIs are quite powerful, and this blog post covers approximately none of that. How are you jumping to a take like this from a blog post discussing one specific implementation detail?
edit: I see from your profile you’re a solutions engineer at a company selling Bazel; your income is literally dependent on seeing a nail (build systems) and using your hammer (Bazel). I’ll assume your comment is in good faith, but you should know that the way you wrote it, I wouldn’t blame anyone for assuming otherwise.
Zig’s build system is pretty fundamentally just a content addressed build graph. It has a lot of APIs for Zig-specific stuff, but you can build any C project too. It is heavily cached, supports incremental rebuilds, and while it’s possible to break the ‘hermetic seal’ if you want, by default it for all practical intents and purposes is (hermetic).
This blog post is describing the separation of what used to be one compilation unit of “your build script” into “your build script that generates a declarative build configuration” and “the standard library builder that consumes said configuration”.
All of the build powers outlined before still hold.
As someone literally tinkering with hermetic builds on Zig’s build system à la Nix or Bazel, I would say it is at least as powerful, as a primitive, as either. I would even go further to say that it is more powerful, because you’re also getting a bootstrapped C compiler, linker, etc in the same binary.
Rovanion | 6 hours ago
As someone who has very little insight into either, could you expand a bit on what you mean by that?
[OP] rcalixte | 15 hours ago
New devlog entry from May 26, 2026 about the build system revamp merged in a recent pull request.
sluongng | 11 hours ago
Meta: are you auto generating these submissions based on Zig's devlog entries?
winter | 53 minutes ago
I doubt it, that comment is just because Lobsters requires you to write a comment if something looks like a dupe based off the URL.