GitHub 上有个组织叫 All Your Codebase,做的事很具体:给一批知名的 C/C++ 开源项目补上一个 build.zig 文件,让这些项目可以用 Zig 的构建系统编译、管理依赖、跨平台交叉编译。这些项目本身没有一个官方采用 Zig,build.zig 目前都挂在第三方仓库里,是社区自发的打包,不是项目状态的变化。
这件事值得多看两眼,是因为 Zig 这次的野心不小。它不只想做一个新的构建脚本语言,而是想把编译器、构建系统、包管理和跨平台发布一起收进同一套工具链。如果这套打包思路跑得通,受影响的不只是几个项目,而是一批 C/C++ 维护者接下来要不要换构建方式的选择。
发生了什么,谁会先碰到这件事
具体做法很简单:给现成项目加两个文件——build.zig 描述怎么编译,build.zig.zon 描述依赖哪些外部代码。不用改上游一行源码,也不需要上游同意。
谁会先碰到这件事:
- 项目原本的维护者.多了一个第三方构建选项,但没有义务响应或接入
- 手工维护跨平台 CI 的团队.如果自己在用的项目已经被打包,可以先拿来试跑,省掉一部分脚本
- 关注 Zig 生态的开发者.这是 Zig 少有的一次向 C/C++ 存量项目正面扩张,不是路线图上的口号
这套打包想替掉的,不是某一个工具,是四类老工具链:
交叉编译方便是真的,但不是所有项目都能零成本迁移。有些老构建脚本把输出路径写死在当前目录,要改成接受参数才能配合 Zig 的构建缓存,该打的补丁一样跑不掉。
Zig 想替掉整条工具链,现实里差多少
上面四条主张单独看都不新鲜,CMake、Conan、vcpkg 各自解决过其中一部分。Zig 的不同在于,想一次性把四件事都收进一个二进制。主张和现实之间,差的是这些:
| 环节 | Zig 的主张 | 现实里的限制 |
|---|---|---|
| 构建脚本 | build.zig 一个文件搞定编译逻辑 | 老脚本的路径、环境变量假设需要重写才兼容 |
| 编译器 | 内置 clang,不用装系统编译器 | 版本绑定 Zig 自身发布节奏,Zig 还没到 1.0 |
| 依赖管理 | build.zig.zon 拉取声明的依赖 | 大多数 C/C++ 依赖还没有 Zig 包描述,覆盖面有限 |
| 跨平台发布 | 一条命令交叉编译多个目标 | 具体平台仍可能要补丁,不是全平台自动过 |
目前能验证的只是"能不能编译",覆盖面和长期维护成本,还是未知数。
两条打包路径,和收编的门槛
All Your Codebase 打包一个项目,通常走两条路。
| 路径 | 具体做法 | 维护成本 | 适合谁 |
|---|---|---|---|
| 外挂 build.zig | 只加 build.zig 和 build.zig.zon,依赖上游发布的原始 tarball | 较低,但依赖上游发布结构保持稳定 | 想先试跑、不想动上游代码的人 |
| Fork 改造 | fork 整个项目,清掉旧脚本、直接打补丁 | 较高,要长期跟着上游更新走 | 真想把项目构建方式迁到 Zig 的人 |
收编规则写得很直白。如果上游维护者愿意接手 build.zig,这个组织承诺归档自己的仓库,把用户指过去。前提是上游整合后的版本,不能比他们现有打包版本多依赖任何系统库。达不到这条线,下游仓库就继续维护。
到目前为止,这批项目都还停留在"被打包"阶段,公开的收编案例还没有看到。
打包容易,过户难。统一工具链的念头不新,每一代新构建系统都想吃掉 Make 和 CMake,但基础设施的惯性从来没那么容易松动。
早年 Debian、Homebrew 的打包志愿者干的也是类似的事:先在外面把依赖和构建流程理顺,再等上游或社区认可。区别在于,那时候动的是"怎么装",这次动的是"怎么编译",牵扯的构建习惯和历史脚本更深。两者只像三分,不能划等号。
维护成本也不该被忽略。贡献者要跟着 Zig 最新版本走,配 CI,上游一发新版就要跟着改构建脚本。Zig 编译器本身还没到 1.0,版本变动本身就是成本,这是长期活,不是一次性脚本。
如果你维护的是 C/C++ 项目,不用急着接入,先看自己关心的项目有没有被打包,再等真正的收编案例出现。如果你只是想用 Zig 简化交叉编译 CI,可以先在非核心项目上试,但要接受多绑定一个还没到 1.0 的工具链版本这层风险。
接下来最该盯的信号,不是又打包了多少个项目,是有没有一个项目被上游正式收编,而且没有增加新的系统依赖。这才是从"能编译"到"被认可"的分水岭。
【锐评】名分未定,过户未成,现在下结论还早。