开源静态类型跨平台构建系统发布

背景

构建系统是软件开发中不可或缺的基础设施，但长期以来，它们的发展并未跟上软件工程的进步。尽管模块化、结构化编程、面向对象编程和静态类型检查等技术在应用层已普及，构建系统却大多仍停留在动态脚本语言主导的阶段。像 CMake、QMake、Meson 和 GN 等主流构建系统各有优劣：CMake 功能完善但语言古老、系统庞大；Meson 虽有创新但仍是动态类型语言；GN 专为 Chromium 设计，功能强大但复杂度高。更关键的是，这些系统自身往往依赖庞大的运行时或编译器（如 Python、C++ 标准库），构建它们本身可能成为负担。作者多年研究构建系统，最终基于 Lua 虚拟机开发了 BUSY（BUild SYstem），一个轻量、跨平台、可静态类型检查且易于自举的构建系统。

核心内容

BUSY 是一个面向 GCC、Clang 和 MSVC 工具链的跨平台构建系统，系统需求极低，易于自举（bootstrappable）。它的核心特点包括：

• 静态类型的构建规格语言：与 CMake、QMake、Meson、GN 等不同，BUSY 的规格语言是静态类型的，支持 let 和 var 声明变量，字段只能在定义处或通过特定语法修改，避免了动态类型语言常见的运行时错误。
• 极简依赖：只需一个 C89 编译器即可构建 BUSY 本身（基于 Lua 虚拟机，但用 C89 编写，而非 Lua）。Lua 自身是极少数能用 gcc *.c 直接编译的代码库之一，生成的文件只有几百 KB。
• 直接集成：BUSY 可以无缝嵌入项目的源码树，无需对宿主机有额外要求。
• 支持多种语法风格：提供两种语法版本（类似 C 的花括号风格和类似 Pascal 的 begin...end 风格），满足不同偏好。

示例项目：NAppGUI

NAppGUI 是一个用 C89（部分 C++98 和 Objective-C）编写的大型跨平台 GUI 库。其 BUSY 构建文件展示了关键特性：

• 顶级 BUSY 文件通过 submod src 引入子模块，用 let 声明 shared_lib 和 static_lib 目标，用 all! Group 聚合它们。
• src 目录下的 BUSY 文件定义 main_config Config，设置包含目录和宏定义；然后通过 submod core、submod draw2d 继续分解。
• draw2d/BUSY 文件定义 sources SourceSet，引用上层 main_config（configs += ^main_config），并根据 target_os 条件（如 linux、win32）添加不同的依赖。
• 支持 Pascal 风格语法：例如 let sources * : SourceSet begin .sources := [...] if target_os == \linux then ... end`。

其他案例：Oberon+ 编译器与 LeanQt

一个更复杂的示例是 Oberon+ 编译器和 IDE，展示了 BUSY 对 Qt moc 和 rcc 工具的特殊支持。详情见相关仓库。

与其他构建系统的对比

作者将 BUSY 与 CMake、Meson、GN、QMake 进行了详细对比：

| 系统 | 优势 | 缺点 | |------|------|------| | CMake | 功能健全，现代 CMake 开始聚焦目标和属性（类似 GN） | 脚本语言陈旧、庞大复杂，单一开发者难以完全理解；本质仍是动态字符串语言 | | Meson | 非图灵完备语言，通过引用抽象对象屏蔽文件系统路径 | 语言古怪（类似 Python），仍是动态类型 | | GN | 专为 Chromium 设计，强大灵活 | 极其复杂，依赖 Ninja（另一个 C++ 代码库），动态类型导致静态分析困难 | | QMake | 作者使用二十年，跨平台 | 依赖 Qt，大型项目灵活性不足 | | BUSY | 静态类型、轻量、易自举、直接嵌入 | 较新，生态尚需发展 |

作者指出，Chromium 拥有近 4000 万行代码，曾多次更换构建系统，最终选用 GN，但 GN 的复杂性使得理解构建过程本身就成了挑战。而动态类型语言的固有缺陷（如难以静态分析）同样困扰着构建系统，这正是 BUSY 引入静态类型的原因。

自举与 Lua 集成

BUSY 通过 build.lua 脚本启动，该脚本是底层 C 实现的 Lua 函数的封装。用户可以用 Lua 脚本扩展或修改构建系统。BUSY 默认自动检测工具链，也支持手动配置。它与 LeanCreator IDE（支持多核构建）深度集成。

关键要点

• 静态类型规格语言：支持 let（不可变）和 var（可变）声明，字段修改需显式使用 . 前缀或 += 等方式，避免动态类型运行错误。
• 极低自举成本：只需 C89 编译器，用 gcc *.c 即可构建 BUSY 本身，生成数百 KB 的单二进制文件。
• 跨平台支持：面向 GCC、Clang、MSVC，无需额外运行时（如 Python、Qt）。
• 模块化与子模块：通过 submod 在文件间分割构建逻辑，支持 Config、SourceSet、Library、Group 等抽象对象。
• 条件编译：支持 if ... else if ... else（包括 error 语句）和符号引用（如 `linux）。
• 与 Lua 深度集成：构建脚本可通过 Lua 扩展，但核心函数由 C 实现，性能可靠。
• 可嵌入源码树：BUSY 本身可以放在项目根目录，无需单独安装。
• 两种语法风格：C 风格和 Pascal 风格，适应不同开发者习惯。
• 支持 Qt 工具链：特殊处理 moc 和 rcc。
• 配套 IDE LeanCreator：与 BUSY 完全集成，支持多核构建。

意义与影响

BUSY 的出现在构建系统领域具有几方面的潜在影响：

1. 推动构建系统语言的静态化：长期以来，构建系统开发者往往容忍动态类型的缺点，而 BUSY 证明静态类型可以应用于构建规格语言，从而提供更早的错误检测、更好的代码分析和更强的模块化能力。这与软件工程中从动态语言向静态语言（如 TypeScript、Dart）的演进趋势一致。

2. 降低构建系统的自举门槛：通过依赖 C89 和 Lua，BUSY 的可移植性和易于构建的特性，使得即使是资源受限的环境（如嵌入式系统或老旧平台）也能轻松使用。这对于那些对构建系统本身就有庞大依赖的项目是一个重要改进。

3. 挑战现有构建系统巨头：CMake、GN、Meson 等已形成庞大生态，但它们的复杂性和依赖问题一直饱受诟病。BUSY 以其简洁的设计吸引了希望摆脱“构建系统的构建系统”负担的开发者。如果 BUSY 得到社区认可，可能成为轻量级项目的替代选择。

4. 启发构建系统设计的理性思考：作者对过去五十年构建系统与技术发展的反思（动态类型为何长期占主导），促使更多开发者重新评价构建系统应有的设计哲学：它应当是一种工程工具，而非另一个需要额外学习的庞大语言或系统。

当然，BUSY 作为较新的项目，仍需验证其在大型项目中的可扩展性、社区支持以及第三方库的适配。但其设计思路确实为构建系统领域注入了一股清新之风。