Andrew Kelley rewires Zig build: new configurer-maker split aims for 90% faster runs

Why it matters

Build systems are where developers feel latency every day. By separating configuration from execution and caching the optimized executor, Zig cuts iteration time and opens the door to richer build features without penalizing startup.

Andrew Kelley, creator of Zig and founder of the Zig Software Foundation, says a major build-system rework has landed on main, splitting zig build into a small debug-compiled "configurer" and a release-optimized "maker" for faster execution, in a devlog post.

Zig is backed by the Zig Software Foundation and sustained by donations and sponsors, with development now hosted on Codeberg. This change fits the project's bias for predictable tooling: less hidden work, more cacheable steps.

What changed

Previously, your project's build.zig and the build runner were compiled together into a single debug binary that both computed and executed the build graph. Now, Zig compiles build.zig into a small "configurer" that constructs the graph and writes a serialized configuration file. While that runs, zig build compiles a separate "maker" in release mode. The maker is cached globally and reused once per Zig version. When both are ready, the maker executes the graph using the serialized config.

Kelley links to the underlying implementation in PR "separate the maker process from the configurer process" (35428). He frames the redesign around three speed wins: only recompile user build.zig when it changes, skip re-running configuration when inputs are unchanged, and execute the build graph with an optimized binary. It also sets up newer features like --watch, --fuzz, and --webui to grow without making every zig build slower.

How much faster

In the devlog, Kelley shows a local benchmark of zig build -h dropping from roughly 150 ms to about 14 ms on his machine, with large cuts in CPU cycles and instructions, roughly a 90% reduction in wall time. Results will vary by project and system, but the direction is clear: less repeated work and an optimized executor.

Impact on tooling and users

Beyond speed, third-party tools such as the Zig language server (ZLS) can read the serialized configuration instead of maintaining a private build runner, which should simplify integrations.

From an API perspective, Kelley says the change is "mostly non-breaking". One likely adjustment: scripts that previously forwarded CLI args like this:

if (b.args) |args| {
    run_cmd.addArgs(args);
}

should now use:

run_cmd.addPassthruArgs();

This trades away the ability for build.zig to observe passthrough args in exchange for not needing to rebuild the script when those args change.

What is shipping when

Kelley describes the post as an early preview of release notes and invites developers to try the main-branch changes now. He adds that Zig 0.17.0 is planned "within a couple weeks," with room for follow-up fixes in 0.17.1 if needed. You can follow along on the devlog, check the source on Codeberg, and start from the Zig homepage at ziglang.org.