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

作者：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（即时编译）的便利！

我最初这样做的动机与公开构建服务器协议有关，目的是为了解决在 maker/configurer 进程分离对 --build-runner 覆盖标志做出破坏性更改后，所导致的 ZLS（Zig 语言服务器）受阻问题。

最初，进程树结构如下：

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 版本前的主要阻碍：

• 构建服务器协议
• Zig 语言服务器使用构建服务器

我七月份有两个会议要参加，需要准备我的演讲，所以现实地说，我认为要到八月初才有时间完成这些工作。当然，欢迎贡献。

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