Zig 0.17 evaluates build.zig in a separate process from the one that runs the build

Before 0.17, build.zig ran inside the build system's own process, so editing the script meant rebuilding the build system ^[6]. Every invocation after an edit started from scratch: recompile the build runner, re-evaluate the script, then execute the graph ^[7]. According to the dev.to post that walks through the release, that cost is a rounding error for small projects and compounds for large projects with complex build scripts ^[8]. The post does not include timings.

An edit in 0.17 still costs something. build.zig is Zig source that runs at configure time ^[9]. The configurer is the process that evaluates it ^[1], so a changed script still goes through the configurer ^[18]. What an edit no longer touches is the maker, which is built once and left unmodified when build.zig changes ^[10]. The maker is also built with optimizations enabled. The post says that matters more now that --watch and --fuzz modes exist ^[11].

For the large-project claim to transfer to a given tree, two things have to be true. The maker rebuild has to have been a real share of what an edit cost before. And the script has to keep the configure cache clean between runs.

The second condition is the harder one. The configurer can be skipped on identical inputs, but only while the cache stays pure ^[13]. Some CLI flags bypass configuration entirely ^[12]. A poisoned cache means the configure logic had side effects or did something the cache could not track ^[14]. The post's example is a build.zig that checks whether scdoc is installed to decide whether to build man pages. The result depends on host state the cache cannot see, so the cache is poisoned ^[14]. That is a lot of cache to lose over a man page. Side effects at make time are expected: a Run step that prints output does not poison anything ^[15].

Porting a large script means finding each configure-time probe and moving it to one of two forms. Four declaration functions cover file contents, file metadata (size, inode, mtime), directory contents and directory metadata, through calls such as std.Build.dependOnFileContents and std.Build.dependOnDirectoryContents ^[16]. For tool lookups, findProgram still exists for cases that need the answer at configure time. The new findProgramLazy returns a LazyPath that defers the search to make time ^[17].

I think the serialization boundary is the best engineering in the release. The configurer writes a compact binary serialization of the build graph, and the maker reads it ^[2]. Third-party tools can consume the same format, and it is the foundation of the new Build Server Protocol ^[5]. One artifact gives the cache something to key on and gives tools something to read. Passing --listen=- starts the server on stdin/stdout. IDEs can then inspect the graph statically, get notified when steps start and complete, and request specific steps ^[3]. The post calls the protocol early. Today it exposes available steps, options and dependencies, and module names plus a multiplexed compiler server protocol for type information and refactoring are planned ^[4].