Build System Reworked

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.

As someone who has very little insight into either, could you expand a bit on what you mean by that?

Meta: are you auto generating these submissions based on Zig's devlog entries?