基于工件的构建系统

本页介绍了基于工件的构建系统及其创建理念。Bazel 是一种基于工件的构建系统。虽然基于任务的构建系统比构建脚本好得多，但它们让工程师可以定义自己的任务，从而赋予工程师过多的权力。

基于工件的构建系统具有少量由系统定义的任务，工程师可以以有限的方式配置这些任务。工程师仍然会告知系统要构建什么 ，但构建系统会确定如何 构建。与基于任务的构建系统一样，基于工件的构建系统（例如 Bazel）仍然具有构建文件，但这些构建文件的内容却大相径庭。Bazel 中的构建文件不是图灵完备脚本语言中描述如何生成输出的一组命令，而是一个声明性清单，描述了一组要构建的工件、它们的依赖项以及一些会影响构建方式的选项。当工程师在命令行中运行 bazel 时，他们会指定一组要构建的目标（即什么 ），而 Bazel 负责配置、运行和调度编译步骤（即如何 ）。由于构建系统现在可以完全控制何时运行哪些工具，因此它可以做出更强的保证，从而使其效率更高，同时仍能保证正确性。

从功能角度来看

基于工件的构建系统与函数式编程之间很容易进行类比。传统的命令式编程语言（例如 Java、C 和 Python）指定要依次执行的语句列表，就像基于任务的构建系统让程序员定义一系列要执行的步骤一样。相比之下，函数式编程语言（例如 Haskell 和 ML）的结构更像一系列数学方程式。在函数式语言中，程序员描述要执行的计算，但将何时以及如何执行该计算的详细信息留给编译器。

这与在基于工件的构建系统中声明清单并让系统确定如何执行构建的想法相符。许多问题无法使用函数式编程轻松表达，但使用函数式编程表达的问题却能从中受益匪浅：该语言通常能够轻松地并行化此类程序，并对其正确性做出强有力的保证，这在命令式语言中是不可能的。使用函数式编程表达的最简单的问题是那些仅涉及使用一系列规则或函数将一个数据转换为另一个数据的问题。而这正是构建系统的作用：整个系统实际上是一个数学函数，它将源文件（以及编译器等工具）作为输入，并将二进制文件作为输出。因此，基于函数式编程的原则构建构建系统效果良好也就不足为奇了。

了解基于工件的构建系统

Google 的构建系统 Blaze 是第一个基于工件的构建系统。Bazel 是 Blaze 的开源版本。

以下是 Bazel 中构建文件（通常命名为 BUILD）的示例：

java_binary(
    name = "MyBinary",
    srcs = ["MyBinary.java"],
    deps = [
        ":mylib",
    ],
)
java_library(
    name = "mylib",
    srcs = ["MyLibrary.java", "MyHelper.java"],
    visibility = ["//java/com/example/myproduct:__subpackages__"],
    deps = [
        "//java/com/example/common",
        "//java/com/example/myproduct/otherlib",
    ],
)

在 Bazel 中，BUILD 文件定义了目标，这里的两种目标类型是 java_binary 和 java_library。每个目标都对应于系统可以创建的工件：二进制目标生成可以直接执行的二进制文件，而库目标生成可供二进制文件或其他库使用的库。每个目标都有：

• name：在命令行中以及被其他目标引用时，目标的名称
• srcs：要编译的源文件，用于为目标创建工件
• deps：必须在此目标之前构建并链接到此目标的其他目标

依赖项可以位于同一软件包中（例如 MyBinary's 对 :mylib 的依赖项），也可以位于同一源层次结构中的不同软件包中 （例如 mylib's 对 //java/com/example/common 的依赖项）。

与基于任务的构建系统一样，您可以使用 Bazel 的命令行工具执行构建。如需构建 MyBinary 目标，请运行 bazel build :MyBinary。首次在干净的代码库中输入该命令后，Bazel 会执行以下操作：

1. 解析工作区中的每个 BUILD 文件，以创建工件之间的依赖关系图。
2. 使用该图确定 MyBinary 的传递依赖项；也就是说，MyBinary 依赖的每个目标以及这些目标依赖的每个目标，依此类推。
3. 按顺序构建每个依赖项。Bazel 首先构建没有其他依赖项的每个目标，并跟踪每个目标仍需要构建哪些依赖项。一旦构建了目标的所有依赖项，Bazel 就会开始构建该目标。此过程将持续进行，直到构建了 MyBinary 的每个传递依赖项。
4. 构建 MyBinary 以生成最终可执行二进制文件，该文件会链接到在第 3 步中构建的所有依赖项。

从根本上讲，这里发生的事情似乎与使用基于任务的构建系统时发生的事情并没有太大的不同。事实上，最终结果是相同的二进制文件，而生成该二进制文件的过程涉及分析一系列步骤以找到它们之间的依赖关系，然后按顺序运行这些步骤。但两者之间存在关键差异。第一个差异出现在第 3 步中：由于 Bazel 知道每个目标仅生成 Java 库，因此它知道它只需要运行 Java 编译器，而不是任意用户定义的脚本，因此它知道可以安全地并行运行这些步骤。 与在多核机器上一次构建一个目标相比，这可以使性能提高一个数量级，并且只有在基于制品的方案让构建系统负责自己的执行策略时才有可能实现，这样它才能对并行性做出更强的保证。

不过，好处不仅限于并行性。当开发者第二次键入 bazel build :MyBinary 而不进行任何更改时，这种 方法带来的下一个好处就会显现出来：Bazel 会在不到 一秒的时间内退出，并显示一条消息，指出目标是最新的。之所以能实现这一点，是因为我们之前讨论过的函数式编程范式：Bazel 知道每个目标仅是运行 Java 编译器的结果，并且它知道 Java 编译器的输出仅取决于其输入，因此只要输入没有更改，输出就可以重复使用。 此分析适用于每个级别；如果 MyBinary.java 发生更改，Bazel 知道 要重建 MyBinary，但重复使用 mylib。如果 //java/com/example/common 的源文件发生更改，Bazel 知道要重建该库、mylib 和 MyBinary，但重复使用 //java/com/example/myproduct/otherlib。 由于 Bazel 了解它在每个步骤中运行的工具的属性，因此它能够每次仅重建最少的工件集，同时保证不会生成过时的构建。

从制品而不是任务的角度重新构建构建流程，这种做法看似细微，但却非常强大。通过降低向程序员公开的灵活性，构建系统可以更了解构建的每个步骤中正在执行的操作。它可以利用这些知识通过并行化构建过程并重复使用其输出来提高构建效率。但这实际上只是第一步，并行性和重复使用的这些构建块构成了分布式且高度可扩缩的构建系统的基础。

其他巧妙的 Bazel 技巧

基于工件的构建系统从根本上解决了基于任务的构建系统固有的并行性和重复使用问题。但我们之前提到的一些问题尚未解决。Bazel 有巧妙的方法来解决这些问题，我们应该在继续之前讨论这些方法。

将工具作为依赖项

我们之前遇到的一个问题是，构建依赖于安装在我们机器上的工具，并且由于工具版本或位置不同，跨系统重现构建可能很困难。当您的项目使用的语言需要根据构建或编译的平台（例如 Windows 与 Linux）使用不同的工具时，问题会变得更加困难，并且每个平台都需要一组略有不同的工具来完成相同的工作。

Bazel 通过将工具视为每个目标的依赖项来解决此问题的第一部分。工作区中的每个 java_library 都隐式依赖于 Java 编译器，该编译器默认为一个众所周知的编译器。每当 Bazel 构建 java_library 时，它都会检查以确保指定的编译器在已知位置可用。与其他任何依赖项一样，如果 Java 编译器发生更改，则依赖于它的每个工件都会被重建。

Bazel 通过设置 构建配置 来解决问题的第二部分（平台独立性）。 目标不是直接依赖于其工具，而是依赖于配置类型：

• 主机配置：构建在构建期间运行的工具
• 目标配置：构建您最终请求的二进制文件

扩展构建系统

Bazel 开箱即用，提供了多种常用编程语言的目标，但工程师总是希望做更多的事情 - 基于任务的系统的好处之一是它们在支持任何类型的构建流程方面的灵活性，最好不要在基于制品的构建系统中放弃这种灵活性。幸运的是，Bazel 允许通过 添加自定义规则来扩展其支持的目标类型。

如需在 Bazel 中定义规则，规则作者需要声明规则所需的输入（以在 BUILD 文件中传递的属性的形式）以及规则生成的固定输出集。作者还会定义将由该规则生成的操作。每个操作都会声明其输入和输出，运行特定的可执行文件或将特定的字符串写入文件，并且可以通过其输入和输出连接到其他操作。这意味着操作是构建系统中最低级别的可组合单元 - 操作可以执行任何操作，只要它仅使用其声明的输入和输出即可，而 Bazel 会负责调度操作并根据需要缓存其结果。

该系统并非万无一失，因为无法阻止操作开发者执行诸如在其操作中引入不确定性过程之类的操作。但在实践中，这种情况并不常见，并且将滥用的可能性一直推到操作级别，大大减少了出错的机会。支持许多常用语言和工具的规则在网上广泛提供，大多数项目永远不需要定义自己的规则。即使对于那些需要定义规则的项目，规则定义也只需要在代码库中的一个中心位置定义，这意味着大多数工程师都可以使用这些规则，而无需担心其实现。

隔离环境

操作听起来可能与其他系统中的任务遇到相同的问题 - 是否仍然可以编写既写入同一文件又最终相互冲突的操作？实际上，Bazel 通过使用沙盒使这些 冲突成为不可能。 在受支持的系统上，每个操作都通过文件系统沙盒与其他操作隔离。实际上，每个操作只能看到文件系统的受限视图，其中包括它已声明的输入和它已生成的任何输出。这是由 Linux 上的 LXC 等系统强制执行的，LXC 与 Docker 背后的技术相同。这意味着操作不可能相互冲突，因为它们无法读取任何未声明的文件，并且它们写入但未声明的任何文件将在操作完成时被丢弃。Bazel 还使用沙盒来限制操作通过网络进行通信。

使外部依赖项具有确定性

还有一个问题：构建系统通常需要从外部来源下载依赖项（无论是工具还是库），而不是直接构建它们。这可以在示例中通过 @com_google_common_guava_guava//jar 依赖项看出，该依赖项从 Maven 下载 JAR 文件。

依赖于当前工作区之外的文件是危险的。这些文件可能会随时更改，这可能会要求构建系统不断检查它们是否是最新的。如果远程文件发生更改，而工作区源代码中没有相应的更改，也可能导致构建无法重现 - 由于未注意到的依赖项更改，构建可能在某一天正常运行，而在第二天却失败，而没有明显的原因。最后，当外部依赖项由第三方拥有时，它可能会带来巨大的安全风险：如果攻击者能够渗透到该第三方服务器，他们可以将依赖项文件替换为他们自己设计的文件，从而可能完全控制您的构建环境及其输出。

根本问题是我们希望构建系统了解这些文件，而无需将它们签入源代码控制系统。更新依赖项应该是一个有意识的选择，但该选择应该在中心位置做出一次，而不是由单个工程师管理或由系统自动管理。这是因为即使使用“Live at Head”模型，我们仍然希望构建具有确定性，这意味着如果您签出上周的提交，您应该看到当时的依赖项，而不是现在的依赖项。

Bazel 和其他一些构建系统通过要求工作区范围内的清单文件来解决此问题，该文件列出了工作区中每个外部依赖项的加密哈希（值）。 哈希是一种简洁的方式，用于唯一表示文件，而无需将整个文件签入源代码控制系统。每当从工作区引用新的外部依赖项时，该依赖项的哈希都会手动或自动添加到清单中。当 Bazel 运行构建时，它会检查其缓存依赖项的实际哈希与清单中定义的预期哈希，并且仅当哈希不同时才重新下载文件。

如果我们下载的工件的哈希与清单中声明的哈希不同，则构建将失败，除非更新清单中的哈希。这可以自动完成，但必须先批准该更改并将其签入源代码控制系统，然后构建才会接受新的依赖项。这意味着始终有依赖项更新时间的记录，并且外部依赖项不能在没有相应的工作区源代码更改的情况下更改。 这也意味着，在签出旧版本的源代码时，构建保证使用与签入该版本时使用的依赖项相同的依赖项（否则，如果这些依赖项不再可用，则构建将失败）。

当然，如果远程服务器变得不可用或开始提供损坏的数据，仍然可能存在问题 - 如果您没有该依赖项的其他副本，这可能会导致您的所有构建开始失败。为避免此问题，我们建议您对于任何重要的项目，都将其所有依赖项镜像到您信任和控制的服务器或服务上。否则，即使签入的哈希保证了构建系统的安全性，您也始终会受到第三方的影响。