Zig 语言圣经

Appearance

0.13.0 ​

2024/6/7，0.13.0 发布，历时不足 2 个月，有 73 位贡献者，一共进行了 415 次提交！

本次发布周期相对其他版本较短，主要是对工具链进行升级，如升级至 LLVM 18。

WARNING

有关于各平台和架构的支持情况，本次更新并未进行更改，故在此处不再提及！

构建系统 ​

Step.Run：child 继承 stderr 时获得全局锁 ​

设置 stdio 为 inherit 的文档：

运行步骤被认为具有副作用，因此当它出现在构建图中时总是会执行。

这也意味着这个步骤将获得全局锁，以防止其他步骤在此期间运行。

如果子进程崩溃或返回非零退出代码，步骤将失败。

过去缺少该锁的实现，目前已实现，确保 stdout/stderr 只会被一个进程占用。

默认情况下将 Windows DLL 安装到 <prefix>/bin/ ​

Windows 不支持 RPATH，默认情况下仅在少量预定路径中搜索 DLL，其中之一是应用程序加载的目录。

目前，如果您构建一个可执行文件和一个 DLL，链接它们并使用默认配置来安装它们，exe 将进入 bin/ ，DLL 将进入 lib/ ，这导致在不手动将 lib/ 添加到 PATH 环境变量中的前提下，exe 无法在运行时找到 DLL。

默认情况下将可执行文件和 DLL 安装到 bin/ 确保可执行文件能够找到它链接到的 DLL。DLL 导入库仍然安装到 lib/ 。

目前该行为与 CMake 相同

示例

zig
exe.root_module.linkLibrary(sdl3_lib);
b.installArtifact(exe);
b.installArtifact(sdl3_lib);

构建结果:

sh
zig-out/
├───bin/
│   ├───example.exe
│   ├───example.pdb
│   ├───SDL3.dll
│   └───SDL3.pdb
├───include/
│   └───SDL3/
│       ├───SDL.h
│       └───<omitted>
└───lib/
   └───SDL3.lib

Step.ObjCopy：不接受多个 section ​

现在 zig objcopy 不接受保留多个 section，如果您将多个 -j .section 参数传递给 zig objcopy，它只会尊重最后传递的一个。

编译器 ​

将 YES_COLOR 环境变量替换为 CLICOLOR_FORCE ​

检测 NO_COLOR 环境变量并在其设置时禁用颜色输出是大多数 CLI 工具所遵循的标准做法。

当涉及到即使不写入终端时也强制输出颜色的任务时，存在两个标准：CLICOLOR_FORCE 和 FORCE_COLOR。这两个标准都没有像 NO_COLOR 那样普遍存在，但它们都有一定的优先级，并且受到一部分 CLI 工具的尊重。

在 e45d24c 之前，Zig 使用 ZIG_DEBUG_COLOR 环境变量强制颜色输出，但该提交将其更改为 YES_COLOR 。

YES_COLOR 似乎目前在软件中几乎没有先例（在 GitHub 上搜索 /(?-i)\bYES_COLOR\b/ 返回了 142 个文件）。

与其在混合中加入第三个标准并使用户更难在 CLI 工具中管理彩色输出，不如使用 CLICOLOR_FORCE 或 FORCE_COLOR 之一进行标记更有意义。

选择 CLICOLOR_FORCE 而不是 FORCE_COLOR 的原因如下：

  • https://bixense.com/clicolors/ 尝试标准化 CLICOLOR_FORCE，创建于 2015 年。FORCE_COLOR 对应的 https://force-color.org/ 创建于 2023 年。
  • CLICOLOR_FORCE 似乎是由 ls 于 2000 年在 FreeBSD 4.1.1 中引入的。FORCE_COLOR 似乎是由 chalk JavaScript 库于 2015 年引入的。
  • CLICOLOR_FORCE 受 CMake 和 Ninja 支持。
  • 虽然搜索 /(?-i)\bCLICOLOR_FORCE\b/ 返回 28.9k 文件并且搜索 /(?-i)\bFORCE_COLOR\b/ 返回 39k 文件，但前者似乎在用 C/C++ 编写的软件中更常见，而后者似乎更常见于 Node.js 和 Python 相关生态系统。

CLICOLOR_FORCE 也会添加到 zig env 的输出中。

LLVM Backend 后端 ​

添加了 loongarch64 支持。它仍然无法构建 hello world，因为 LLVM 尚未为该目标实现 fp_to_fp16。

zig-cache 重命名为 .zig-cache ​

这与更多工具配合得很好。例如，文本编辑器通常会从“在文件中查找”功能中排除该目录。

Bug 修复 ​

在此发布周期内解决的 43 个错误报告的完整列表。

在这个发布周期中引入并解决了许多错误，为了简洁起见，这些发行说明中省略了大多数错误修复。

当前版本包含的 Bugs ​

Zig 目前存在一些 已知的 bugs，甚至包含一些 编译错误！

Zig 目前仍不成熟，即使是使用 0.13.0 也可能需要参与 zig 开发才能使之顺利在某些项目开发上正常工作！

当 Zig 达到 1.0.0 时，一级支持 将获得一个额外的错误策略作为要求。

工具链 ​

LLVM 18 ​

升级 LLVM 至 18.1.7，这是本次 0.13.0 发版的主要目的！

musl 1.2.5 ​

Zig 附带了 musl 的源代码。当选择 musl C ABI 时，Zig 会从源为所选目标构建静态 musl。

Zig 还支持定位动态链接的 musl，这对于使用它作为系统 libc 的 Linux 发行版非常有用，例如 Alpine Linux。

从 v1.2.4 升级至 v1.2.5。

glibc 2.39 ​

交叉编译时现在可以使用 glibc 版本 2.39。

路线图 ​

0.14.0 发布周期的主题将是编译速度。

将在 0.14.0 发布周期中努力实现一些即将到来的里程碑：

  • 使 x86 后端成为调试模式的默认后端。
  • COFF 的链接器支持。消除对 LLD 的依赖。
  • 启用增量编译以实现快速重建。
  • 将并发引入语义分析，进一步提高编译速度。

目前的思路是，优先考虑更快的编译将提高编译器本身的开发速度，从而在接下来的发布周期中修复更多的错误并完成更多的功能。

加快编译速度也可能会对语言本身做出一些调整。