【Zig 日报】所有包管理功能已从编译器移至构建系统

[jiacai2050]

Author: Andrew Kelley

既然用户的 build.zig 脚本与构建系统本身已经有了独立的进程，那么将包管理逻辑放在那里就顺理成章了。

我将以下子命令移到了 maker 进程中：

• zig build
• zig fetch
• zig init
• zig libc

这意味着过去包含在编译器可执行文件中的大部分内容，现在改以源码形式发布，包括：

• 包获取逻辑
• HTTP 客户端与网络功能
• TLS（传输层安全）及相关加密算法
• Git 协议
• xz、gzip、zstd、flate、zip
• 解析、验证以及处理 build.zig.zon 文件

因此，现在无需重新编译编译器即可对这些功能打补丁，这使得用户和贡献者进行修改和折腾变得更容易。

此外，这意味着 Zig 中的包管理现在在进行网络操作时启用了安全检查，因为 maker 可执行文件是以 ReleaseSafe 模式编译的。而且，用于网络和文件哈希的所有加密算法现在都可以利用宿主机上可用的特殊 CPU 指令，甚至是那些在分发软件时因为太罕见而通常无法依赖的指令。我们既可以享受 AOT（预先编译）的美味，又能兼得 JIT（即时编译）的灵活性！

我最初这样做的动机，是为了公开一个构建服务器协议（Build Server Protocol），以便在 maker/configurer 进程分离导致 --build-runner 覆盖标志发生破坏性变更后，为主流语言服务器（ZLS）扫清障碍。

最初，进程树看起来是这样的：

zig build  (zig 编译器 + 包管理)
└─ builder (用户的 build.zig 逻辑 + 构建系统实现)

进程分离的变更集使其变成了这样：

zig build     (zig 编译器 + 包管理)
├─ configurer (用户的 build.zig 逻辑)
└─ maker      (构建系统)

此时，考虑一个长时间运行的 zig build --watch 进程，它监视文件并在源码变更时重新构建。如果检测到对 build.zig 的任何更改，或者在执行该逻辑期间观察到任何文件变更，这意味着需要重新运行 configurer，也就是意味着 maker 进程必须退出，以为 zig build 提供重复包管理逻辑的机会。

现在，在经历了这篇开发日志中描述的更改后，它变成了这样：

zig build        (zig 编译器)
└─ maker         (构建系统 + 包管理)
   └─ configurer (用户的 build.zig 逻辑)

因此，当需要重新运行配置时，maker 进程可以继续存活，因为它是父进程而不是同级进程。对于即将推出的构建服务器而言，这意味着避免了一种尴尬的情况——服务器不得不退出、客户端不得不重新连接，取而代之的是只需简单地通知客户端配置发生了更改。

这几乎完全是一个非破坏性的变更，但有一些可观察到的不同之处：

• Zig 可执行二进制文件大小：缩小了 4%，从 14.1 MiB 降至 13.5 MiB（无 LLVM，使用 ReleaseSmall 模式）
• --maker-opt 标志被 ZIG_DEBUG_MAKER 环境变量取代
• --zig-lib-dir 标志被 ZIG_LIB_DIR 环境变量取代

此变更集的后续问题是我们标记发布 Zig 0.17.0 版本的主要阻塞点：

• 构建服务器协议 MVP（用于为 ZLS 解除阻塞）
• 引入为构建脚本本身添加路径依赖的概念
• 使 zig build --watch 能够检测对构建脚本的修改并自行重新运行
• 不同的当前工作目录（cwd）导致构建脚本缓存失效

我在七月份有两个会议要参加，需要准备演讲，所以现实地讲，我认为在八月上旬之前我没有时间完成这些工作。当然，欢迎各界贡献代码。

非常感谢来自 ZLS 团队的 Techatrix 主动联系我，并与我合作开发构建服务器协议！顺便说一句，他们正在寻求赞助。

https://ziglang.org/devlog/2026/#2026-06-30

加入我们

Zig 中文社区是一个开放的组织，我们致力于推广 Zig 在中文群体中的使用，有多种方式可以参与进来：

1. 供稿，分享自己使用 Zig 的心得
2. 改进 ZigCC 组织下的开源项目
3. 加入微信群、Telegram 群组