构建、测试与发布：Zig Build Graph 的另一面

Ghostty 的构建文件本身就是架构文档。build.zig 不只是编译 src/main.zig，而是根据 target、runtime、优化模式和 feature 生成 executable、libghostty、libghostty-vt、XCFramework、WASM、文档、翻译、资源和发行包。

编译时配置

src/build/Config.zig、build_config.zig 和 src/build_config.zig 把以下维度变成可追踪的 build config：

• target OS/CPU/ABI；
• Debug / ReleaseSafe / ReleaseFast / ReleaseSmall；
• app runtime：none / GTK；
• 是否生成 macOS app、lib、lib-vt、WASM；
• Metal/OpenGL/WebGL、compression、unicode tables、shell integration 等 feature。

main_ghostty.zig 用 build_config.artifact 和 build_config.app_runtime 在编译时决定 return type 和启动行为，尽量让不适用的分支被编译器裁掉，而不是运行时携带一堆空实现。

产物分层

zig build
├── ghostty helper / GTK executable
├── libghostty (static/shared)
├── libghostty-vt
├── libghostty-vt.wasm
├── generated C headers / webdata
├── macOS XCFramework / Xcode integration
├── docs / man / completions
└── distribution resources

src/build/GhosttyExe.zig、GhosttyLib.zig、GhosttyLibVt.zig、GhosttyXCFramework.zig、GhosttyDocs.zig 等各自封装构建步骤。这样，库构建不必通过复制 GUI 工程来实现，文档和资源也能在 build graph 中有明确依赖。

测试组织

src/main_ghostty.zig 的 test block 会引用 pty、font、apprt、renderer、termio、input、terminal、compression、unicode、synthetic、benchmark 和 crash 等模块，使 zig build test 能把库级测试装配起来。

开发指南建议：

zig build
zig build test
zig build test -Dtest-filter=<name>
zig build -Demit-lib-vt
zig build -Demit-lib-vt -Dtarget=wasm32-freestanding -Doptimize=ReleaseSmall

最实用的验证方式不是每次跑全套，而是按改动边界选择 -Dtest-filter、test-lib-vt、font test、parser test 或 benchmark。终端 parser 和 page compression 还可以用 synthetic 输入和 differential test 做边界覆盖。

基准和 synthetic 数据

src/benchmark/ 覆盖 TerminalParser、TerminalStream、ScreenClone、PageCompression、ScrollbackCompression、GraphemeBreak、CodepointWidth、Kitty graphics 等；src/synthetic/ 可以生成 ASCII、UTF-8、OSC、Kitty 等具有控制性质的输入。

这种组合很重要：benchmark 告诉你热路径有多快，synthetic 让你能重复生成“长输出、坏 UTF-8、极端序列、图片协议”的压力场景，而不是只依赖真实应用的偶然行为。

资源和代码生成

构建目录中有 webgen、mdgen、UnicodeTables、HelpStrings、I18n、FrameData、Metallib 等 step。它们把配置字段、action、command、Unicode 表、shader、翻译和帮助文本变成编译期资源。新增配置或 action 时，除了运行逻辑，还要检查是否需要更新生成器和发行资源。

发行与 crash report

README 描述了 built-in crash reporter：崩溃报告保存在本机 state 目录，不自动上传；+crash-report 负责列出报告。src/crash/ 负责目录、Sentry envelope 和线程 metadata。这个设计把“收集”和“上传”拆开，用户可以审阅或自行发送，降低隐私风险。

构建系统反映出的设计哲学

• 核心库优先，GUI 是 runtime 的一个产物；
• 平台资源和平台 API 在 build graph 中显式出现；
• 可执行程序、库、WASM、文档和发行包有不同的依赖闭包；
• 测试、基准、synthetic 和 fuzz 共享同一套终端核心，而不是复制测试实现；
• Debug 允许更强诊断，Release 模式专注性能/体积，入口会明确提醒 Debug 构建很慢。