All Package Management Functionality Moved from Compiler to Build System

所有包管理功能已从编译器迁移至构建系统

June 30, 2026 | Author: Andrew Kelley 2026年6月30日 | 作者：Andrew Kelley

Now that there is a separate process for users’ build.zig scripts and the build system itself, it makes sense for that to be the place that package management logic lives. 既然现在用户的 build.zig 脚本与构建系统本身已经有了独立的进程，那么将包管理逻辑放在那里就显得顺理成章了。

I moved these subcommands to the maker process: 我将以下子命令迁移到了 maker 进程中：

zig build
zig fetch
zig init
zig libc

This means that large parts of what used to be included in the compiler executable are now shipped in source form instead, including: 这意味着过去包含在编译器可执行文件中的大部分内容，现在改为以源代码形式发布，包括：

package fetching logic (包获取逻辑)
HTTP client and networking (HTTP 客户端与网络功能)
TLS (Transport Layer Security) and associated crypto (TLS 及相关加密功能)
Git protocol (Git 协议)
xz, gzip, zstd, flate, zip (压缩算法支持)
parsing, validation, and otherwise dealing with build.zig.zon files (解析、验证及处理 build.zig.zon 文件)

Consequently, this functionality can now be patched without rebuilding the compiler, making it easier for users and contributors to tinker. 因此，这些功能现在无需重新编译编译器即可进行修补，这使得用户和贡献者更容易进行调试和修改。

Furthermore, it means that package management in zig now has safety checks enabled when doing networking, since the maker executable is compiled in ReleaseSafe mode. Plus, all the crypto used for networking and file hashing can now take advantage of special CPU instructions available on the host, even the ones that are too rare to normally depend on when distributing software. We can have AOT cake and eat JIT, too! 此外，这意味着 Zig 的包管理在进行网络操作时现在启用了安全检查，因为 maker 可执行文件是以 ReleaseSafe 模式编译的。另外，所有用于网络和文件哈希的加密算法现在都可以利用宿主机上的特殊 CPU 指令，即使是那些在分发软件时通常不敢依赖的罕见指令。我们既能享受 AOT 的优势，也能兼顾 JIT 的灵活性！

My original motivation for doing this was in relation to exposing a build server protocol in order to unblock ZLS after maker/configurer process separation made breaking changes to the —build-runner override flag. 我最初做这件事的动机与公开构建服务器协议有关，目的是在 maker/configurer 进程分离导致 --build-runner 覆盖标志出现破坏性变更后，解除 ZLS 的阻塞。

Originally, the process tree looked like this: 最初，进程树结构如下： zig build (the zig compiler + package manager) └─ builder (the user's build.zig logic + build system implementation)

The process separation changeset made it look like this instead: 进程分离的变更集使其变成了这样： zig build (the zig compiler + package manager) ├─ configurer (the user's build.zig logic) └─ maker (build system)

At this point, consider a long-running zig build --watch process, watching files and rebuilding on source code changes. If any changes to build.zig are detected, or any files observed during execution of that logic, it means configurer needs to be rerun, meaning that maker process must exit to give zig build a chance to repeat the package management logic. 此时，考虑一个长时间运行的 zig build --watch 进程，它会监视文件并在源代码更改时重新构建。如果检测到 build.zig 的任何更改，或者在执行该逻辑期间观察到任何文件变动，这意味着 configurer 需要重新运行，即 maker 进程必须退出，以便让 zig build 有机会重复执行包管理逻辑。

Now, after the changes described in this devlog entry, it looks like this: 现在，在执行了本开发日志中描述的更改后，结构如下： zig build (the zig compiler) └─ maker (build system + package manager) └─ configurer (the user's build.zig logic)

Thus, when configuration needs to be rerun, maker process can continue to live because it is the parent process rather than a sibling. In terms of the upcoming build server, it means avoiding an awkward situation where the server has to exit and the client has to reconnect, rather than simply informing the client of a configuration change. 因此，当需要重新运行配置时，maker 进程可以继续存活，因为它现在是父进程而不是兄弟进程。就即将推出的构建服务器而言，这意味着避免了服务器必须退出、客户端必须重新连接的尴尬局面，取而代之的是只需通知客户端配置已更改。

This is almost entirely a non-breaking change, but there are some observable differences: 这几乎是一个完全非破坏性的变更，但仍有一些可观察到的差异：

Zig executable binary size: shrinks 4% from 14.1 to 13.5 MiB (no LLVM, ReleaseSmall) (Zig 可执行文件体积：缩小了 4%，从 14.1 MiB 降至 13.5 MiB，不含 LLVM，ReleaseSmall 模式)
--maker-opt flag is replaced by ZIG_DEBUG_MAKER environment variable (--maker-opt 标志被 ZIG_DEBUG_MAKER 环境变量取代)
--zig-lib-dir flag is replaced by ZIG_LIB_DIR environment variable (--zig-lib-dir 标志被 ZIG_LIB_DIR 环境变量取代)

The follow-up issues to this changeset are the main blockers until we tag Zig 0.17.0: 在发布 Zig 0.17.0 之前，该变更集的后续问题是主要的阻塞点：

build server protocol MVP (needed to unblock ZLS) (构建服务器协议 MVP，用于解除 ZLS 阻塞)
introduce the concept of adding path dependencies of the build script itself (引入添加构建脚本自身路径依赖的概念)
make zig build --watch detect modifications to the build script and rerun itself (使 zig build --watch 能够检测构建脚本的修改并自动重新运行)
different cwd causes build script cache miss (不同的当前工作目录导致构建脚本缓存失效)

I have two conferences coming up in July and I need to work on my talks, so being realistic, I don’t think I will have time to wrap these up until early August. Contributions welcome, of course. 七月份我有两个会议要参加，我需要准备演讲稿，所以现实地说，我认为在八月初之前我没有时间完成这些工作。当然，欢迎大家贡献代码。

Big thanks to Techatrix from the ZLS team for reaching out and working with me on the build server protocol! They are seeking sponsorship, by the way. 非常感谢 ZLS 团队的 Techatrix 主动联系并与我共同开发构建服务器协议！顺便提一下，他们正在寻求赞助。