Buck2、Pantsbuild 和 Bazel 的区别

[htoooth]

它们的诞生是为了解决传统构建工具在超大规模、多语言、多团队协作的软件工程实践中遇到的瓶颈和失效问题。

这个故事的核心可以追溯到 Google、Meta (Facebook)、Twitter 等公司所面临的独特挑战，以及它们为了应对这些挑战而开创的一种代码库管理风格——“单一代码库”（Monorepo）。

让我们从问题的根源开始，一步步来看这个演进过程。

---

第一阶段：传统构建工具的时代 (The Old World)

在几十年的软件开发历史中，我们有很多经典的构建工具：

• Make: 元老级的工具，非常灵活，但依赖于文件时间戳，容易出错，难以管理复杂的依赖关系，且不具备可复现性。
• Ant/Maven/Gradle (Java生态): 极大地改进了 Java 项目的依赖管理和生命周期管理。Maven 的“约定优于配置”理念非常成功。
• pip/npm/Cargo (各语言生态): 各个语言生态系统都发展出了自己的包管理器和构建工具，它们在各自的领域内做得很好。
• Shell 脚本: 终极的“胶水”工具，灵活但脆弱、不可移植且难以维护。

这些工具在它们所设计的场景下（通常是单个项目、单一语言）表现出色。然而，当软件项目的规模和复杂度达到一个临界点时，这些工具的弊端开始集中爆发。

---

第二阶段：问题的爆发点 (The Tipping Point)

随着 Google 等公司将所有代码都放入一个巨大的代码库（Monorepo）中，传统工具的局限性变得无法忍受。在一个拥有数万名工程师、数亿行代码、涵盖 C++、Java、Python、Go 等多种语言的 Monorepo 中，出现了以下致命问题：

1. 灾难性的构建和测试时间 (Glacial Build Times)

想象一下，你只修改了一行代码，但为了确保没有破坏任何东西，构建系统需要花几十分钟甚至几小时来运行。这是因为传统工具无法精确地知道“这一行代码的修改到底影响了哪些部分”。它们要么过于保守，重新构建大量无关代码；要么过于乐观，遗漏了需要重新构建的目标，导致错误。

2. “在我机器上能跑”的噩梦 (The Reproducibility Nightmare)

传统构建过程往往是非封闭的 (Non-hermetic)。这意味着构建可以访问你机器上的任何工具、库或环境变量。

• 工程师 A 的机器上装了 gcc 9.0，工程师 B 的机器上是 gcc 10.0。
• 工程师 A 的 PATH 环境变量里有一个特定版本的 Python，而 CI/CD 服务器上是另一个版本。

这导致了构建结果的不可预测性。同一个提交 (commit) 在不同环境下可能产生不同的二进制文件，甚至一个能跑一个不能。这对于大规模协作和可靠发布是致命的。

3. 依赖地狱 (Dependency Hell)

在 Monorepo 中，所有项目共享同一个依赖关系图。如果项目 A 依赖 libfoo v1.0，而项目 B 依赖 libfoo v2.0，就会产生冲突。在成千上万个内部库和第三方库中管理这些版本变得异常复杂。传统工具对此束手无策。

4. 多语言的“巴别塔”困境 (The Multi-Language Maze)

一个功能可能需要后端（Java/Go）、前端（JavaScript/TypeScript）和移动端（Kotlin/Swift）的协作。使用 Maven 构建 Java，用 Webpack 构建 JS，用 Xcodebuild 构建 iOS，这些系统之间无法对话。你无法轻易地定义一个跨语言的依赖关系，比如“这个 Java 服务依赖于那个 C++ 库生成的协议缓冲区（Protocol Buffers）代码”。

---

第三阶段：新一代构建工具的诞生 (The New Philosophy)

为了解决上述所有问题，Google 内部开发了 Blaze，后来开源为 Bazel。同样，Facebook 开发了 Buck (现在是 Buck2)，Twitter 开发了 Pants (现在是 Pantsbuild)。它们虽然实现不同，但共享一套核心哲学，这套哲学正是为了解决 Monorepo 的痛点而设计的：

1. 核心原则：精确、可复现、可扩展

• 精确的依赖关系图 (Fine-Grained Dependency Graph):

  • 解决方案: 强制开发者在 BUILD 文件中显式声明每个构建单元（target）的所有直接依赖。
  • 效果: 工具能构建一个完整的、精确的依赖关系图。当文件 A 改变时，工具能精确地知道只需要重新构建依赖于 A 的目标，而其他一切都无需触碰。这就是增量构建 (Incremental Builds) 的基础，极大地缩短了构建时间。

• 封闭式构建 / 沙盒化 (Hermetic Builds / Sandboxing):

  • 解决方案: 构建过程在受控的沙盒环境中执行。沙盒中只包含显式声明的源代码、依赖项和工具链。构建脚本无法访问网络或文件系统中的任意文件。
  • 效果: 彻底解决了“在我机器上能跑”的问题。只要源代码和依赖声明不变，无论在谁的机器上或在CI服务器上，构建结果都是逐字节一致 (byte-for-byte identical) 的。这就是可复现构建 (Reproducible Builds)。

• 内容寻址缓存 (Content-Addressable Caching):

  • 解决方案: 不再依赖文件时间戳。工具对一个构建目标的所有输入（源代码、依赖项、编译器选项等）计算一个哈希值（hash）。这个哈希值作为缓存的键（key）。
  • 效果:
    1. 本地缓存: 如果你没有修改任何输入，再次构建时会立即从本地缓存中获取结果。
    2. 远程缓存 (Remote Cache): 这是革命性的。整个团队可以共享一个缓存服务器。如果你的同事刚刚构建了你正要构建的目标，你的构建工具会直接从服务器下载结果，甚至不需要在本地执行编译！这对于大型团队的协作效率是巨大的提升。

• 统一的多语言支持 (Unified Multi-Language Support):

  • 解决方案: 提供一个统一的、与语言无关的平台。通过“规则”（Rules）来扩展对新语言的支持。例如，有 java_library、py_binary、cc_test 等规则。
  • 效果: 你可以在同一个 BUILD 文件中定义不同语言的目标，并建立它们之间的依赖关系，例如让一个 py_binary 依赖于一个 java_library 的输出。这完美解决了多语言协作的难题。

• 大规模并行与分布式构建 (Massive Parallelism & Distributed Builds):

  • 解决方案: 基于精确的依赖图，工具可以识别出哪些构建或测试任务之间没有依赖关系，从而在本地机器的多核CPU上并行执行它们。更进一步，可以将这些独立的任务分发到数据中心的数千台机器上并行执行（分布式构建）。
  • 效果: 将原本需要数小时的完整构建时间缩短到几分钟。

结论

Buck2、Pantsbuild 和 Bazel 不是对传统工具的简单改进，而是一场范式转移 (Paradigm Shift)。

它们是软件工程规模化发展到一定阶段后的必然产物，是为了应对 Monorepo 带来的速度、正确性和协作三大挑战而设计的精密仪器。它们通过强制的显式依赖、封闭的构建环境和强大的缓存机制，将构建过程从一种“手艺活”变成了一种可靠、可预测、可扩展的自动化工程。

[htoooth]

这些现代构建工具的核心设计和长期价值。

总的来说，Bazel 在可扩展性、支持新工具和新语言方面的综合实力最强，生态系统最为成熟。然而，Pantsbuild 在“易于扩展”方面做得更好，而 Buck2 提供了理论上最纯粹的扩展模型但成熟度最低。

这三者都使用 Starlark（一种类似 Python 的配置语言）来定义构建规则，因此它们在底层语言上是统一的。但它们的理念、API 和生态系统决定了扩展的体验和能力。

下面是详细的对比分析：

---

可扩展性对比

方面	Bazel	Pantsbuild	Buck2
核心理念	规则 (Rules) 是核心。 提供一套强大的 API，让你像用乐高积木一样从零开始构建对任何语言或工具的支持。	插件 (Plugins) 和目标 (Goals) 是核心。 专注于简化将新工具集成到现有工作流（如 lint, test, fmt）的过程。	规则与引擎分离。 提供了理论上最清晰的模型，规则完全是用户空间代码，与 Rust 编写的核心引擎解耦。
易用性	陡峭。需要深入理解 Bazel 的内部概念，如 Providers, Aspects, Toolchains。	非常友好。为常见任务（如集成 Linter）提供了高层级的 API，通常只需要写少量代码。	较难。API 相对底层且文档尚不完善，需要用户自己处理更多细节。
生态系统	极其庞大。 拥有海量的官方和社区维护的 rules_* 仓库，几乎涵盖所有主流语言和许多工具。	正在快速增长。 内置了对许多主流语言（Python, Go, Java, Scala, Shell）的强大支持，社区也在贡献新的插件。	相对有限。 主要由 Meta 内部驱动，社区生态系统刚刚起步。
灵活性与能力	最高。 允许你对构建图进行最细粒度的控制，可以实现任何复杂的构建逻辑。	高，但有侧重。 在集成到其“目标(Goal)”框架内时非常强大和简单。对于完全自定义的、非标准的工作流，可能不如 Bazel 灵活。	理论上非常高。 其纯粹的模型潜力巨大，但目前受限于 API 的成熟度和文档。

---

分场景详解

Bazel：工业级的“万能工具箱”

Bazel 的可扩展性是其设计的基石。它将一切都视为“规则”。

• 如何工作： 你需要编写 .bzl 文件，在其中使用 Starlark 语言定义新的规则。例如，要支持一门新的语言 MyLang，你需要：

  1. 定义一个 mylang_toolchain 规则来指定编译器/解释器的位置。
  2. 定义一个 mylang_library 规则来描述如何编译一组 .mylang 源文件。
  3. 定义一个 mylang_binary 规则来描述如何将编译产物链接成一个可执行文件。
  4. 定义一个 mylang_test 规则来描述如何运行测试。
     在这些规则中，你需要精确地告诉 Bazel 每个动作（action）的输入、输出、命令行参数，并通过 Providers 在规则之间传递信息（比如编译产物的路径、头文件等）。

• 优势 (优势):

  • 无与伦比的能力： 几乎没有 Bazel 无法描述的构建逻辑。无论是为嵌入式系统交叉编译，还是处理复杂的代码生成步骤，Bazel 都有相应的机制来处理。
  • 成熟的生态： 你想支持 Go？使用 rules_go。想支持 Rust？使用 rules_rust。想打包 Docker 镜像？使用 rules_docker。绝大多数情况下，你需要的扩展已经有人写好了。

• 劣势 (劣势):

  • 极其复杂： 编写一条好的、健壮的 Bazel 规则是一项严肃的工程任务。你需要成为半个 Bazel 专家，理解其内部的运行机制，这对于新手来说是一个巨大的障碍。

结论：当你需要与一个非主流的工具链集成，或者需要实现非常复杂的、自定义的构建逻辑时，Bazel 是最佳选择。它的上限是最高的。

Pantsbuild：为开发者体验优化的“插件化平台”

Pantsbuild 的哲学是，开发者通常不是想从零发明一个构建系统，而只是想把他们喜欢的工具（如 black 格式化工具, pytest 测试框架）集成进来。

• 如何工作： Pants 将常见的开发任务抽象为“目标 (Goals)”，例如 lint, fmt (格式化), test, package。它的扩展模型鼓励你为这些目标编写插件。例如，要支持一个新的 Linter MyLinter：

  1. 在一个 pants.toml 文件中注册你的插件。
  2. 编写一个 register.py 文件，定义 MyLinter 所需的工具链（从哪里下载）。
  3. 定义一个请求 MyLinterRequest 和一个处理函数，这个函数使用 Pants 的 API 来运行 linter 并返回结果。
  4. Pants 的引擎会自动帮你处理依赖注入、沙盒化、缓存等繁重工作。

• 优势 (优势):

  • 简单直观： 为常见任务编写插件的门槛远低于在 Bazel 中编写规则。API 设计得非常人性化。
  • 自动化程度高： Pants 的引擎为你处理了大量模板化的工作，你只需要关注工具本身的核心逻辑。

• 劣势 (劣势):

  • “被引导的灵活性”： 它在“将工具集成到 Pants 工作流”这件事上做得非常好。但如果你想做一些完全跳出这个框架的事情，可能会感觉束手束脚，不如 Bazel 那样自由。

结论：当你的主要需求是快速、轻松地将各种 Linter、格式化工具、代码生成器、测试框架集成到项目中，并希望获得最佳的开发者体验时，Pantsbuild 是无与伦比的选择。

Buck2：理论上最纯粹的“未来之星”

Buck2 吸取了 Buck1 和 Bazel 的经验教训，试图在理论层面做得更“正确”。

• 如何工作： 与 Bazel 类似，你也是通过编写 .bzl 文件来定义规则。但它的模型区分得更清晰：规则的实现（rule.impl）是一个纯粹的函数，它接收上下文（包含了依赖的分析结果）并返回 Providers。这种函数式的方法使得规则的逻辑非常清晰。

• 优势 (优势):

  • 设计清晰： 将规则的定义和实现严格分离，理论上使得规则更容易理解和测试。
  • 高性能基础： 底层是用 Rust 编写的高性能引擎，为复杂的规则执行提供了坚实的基础。

• 劣势 (劣势):

  • 生态和文档不成熟： 这是它目前最大的短板。相比 Bazel，几乎没有现成的社区规则可用。文档和示例也比较缺乏，你基本上需要自己摸索，或者阅读 Buck2 自身的规则源码来学习。
  • API 仍在演进： 作为一个较新的工具，其 Starlark API 可能会有更多的变化。

结论：如果你是一个构建系统的专家，对构建理论有深入的理解，并且愿意为一个新平台的未来进行投资，Buck2 提供了一个非常有吸引力的、设计优雅的平台。但对于大多数团队来说，目前选择它意味着要承担更多的“开荒”工作。

最终建议

• 选择 Bazel，如果你需要：

  • 一个经过超大规模实战检验的、极其强大的系统。
  • 最广泛的社区支持和现成的规则库。
  • 处理非常复杂或非标准的构建需求。
  • 你的团队愿意投入时间来学习和掌握它。

• 选择 Pantsbuild，如果你需要：

  • 快速上手和集成，最大化开发者生产力。
  • 将重点放在轻松添加和管理代码质量工具（Linter, Formatter 等）上。
  • 一个“开箱即用”体验更好，配置更少的解决方案。

• 选择 Buck2，如果你需要：

  • 押注于未来的性能和最现代的架构。
  • 你的团队有深厚的构建系统专业知识，并且不介意成为早期使用者。
  • 性能是你压倒一切的首要考虑因素。