本页将介绍基于工件的构建系统及其创建背后的理念。Bazel 是一个基于工件的构建系统。虽然基于任务的构建系统比构建脚本更为先进，但它们让各个工程师定义自己的任务，从而赋予他们过多的能力。
基于工件的构建系统包含由系统定义的少量任务，工程师能够以有限的方式配置这些任务。工程师仍然会告诉系统要构建什么，但构建系统会决定如何构建。与基于任务的构建系统一样，基于工件的构建系统（如 Bazel）仍然具有构建文件，但这些构建文件的内容却截然不同。Bazel 中的 buildfile 并不是描述如何生成输出的图灵完整脚本语言中的命令集命令，而是一个声明性清单，用于描述要构建的一组工件、它们的依赖项，以及一组会影响构建方式的有限选项。当工程师在命令行上运行 bazel 时，他们会指定要构建一组目标（“内容”），Bazel 负责配置、运行和安排编译步骤（具体方法）。由于构建系统现在能够完全控制何时运行哪些工具，因此可以更有力地保证其效率，同时仍能保证正确性。
功能视角
很容易对基于工件的构建系统和功能编程进行类比。传统的命令式编程语言（例如 Java、C 和 Python）会指定要依次执行的语句列表，这与基于任务的构建系统允许程序员定义一系列执行步骤的方式相同。相比之下，函数式编程语言（例如 Haskell 和 ML）的结构更像是一系列数学方程式。在函数语言中，程序员会描述要执行的计算，但会将有关计算的执行时间和确切方式的详细信息留给编译器。
这对应于在基于工件的构建系统中声明清单，然后让系统确定如何执行构建的想法。许多问题无法通过函数式编程轻松表达，但能从中受益很多的问题：语言通常能够轻而易举地并行处理此类程序，并有力地保证其正确性，而这在命令式语言中是不可能实现的。使用函数式编程表达的问题中，最容易涉及到使用一系列规则或函数将一段数据转换为另一条数据的问题。这正是构建系统的意义：整个系统实际上是一个数学函数，将源文件（以及编译器等工具）作为输入并生成二进制文件作为输出。因此，基于函数式编程原则建立构建系统也就不足为奇。
了解基于工件的构建系统
Google 的构建系统 Blaze 是第一个基于工件的构建系统。Bazel 是 Blaze 的开源版本
build 文件（通常命名为 BUILD）在 Bazel 中如下所示：
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 对 :mylib 的依赖项），也可以位于同一源层次结构中的其他软件包中（例如 mylib 对 //java/com/example/common 的依赖项）。
与基于任务的构建系统一样，您可以使用 Bazel 的命令行工具执行构建。如需构建 MyBinary 目标，请运行 bazel build :MyBinary。在干净的代码库中首次输入该命令后，Bazel 会执行以下操作：
- 解析工作区中的每个
BUILD文件，以创建工件之间的依赖关系图。 - 使用该图确定
MyBinary的传递依赖项；即MyBinary所依赖的每个目标，以及这些目标以递归方式依赖的每个目标。 - 按顺序构建其中的每个依赖项。Bazel 首先会构建没有其他依赖项的每个目标，这些目标会跟踪仍需为每个目标构建哪些依赖项。构建好目标的所有依赖项后，Bazel 会立即开始构建该目标。此过程会一直持续到
MyBinary的每个传递依赖项都构建完毕。 - 构建
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 通过设置 build 配置解决了第二个问题，即平台独立性。它们依赖于配置类型，而不是直接依赖于其工具：
- 主机配置：在构建期间运行的构建工具
- 目标配置：构建您最终请求的二进制文件
扩展构建系统
Bazel 本身支持多种常用编程语言的目标，但工程师始终希望实现更多目标。基于任务的系统的优势在于，它们在支持任何类型的构建流程方面具有灵活性，最好不要在基于工件的构建系统中放弃这些目标。幸运的是，Bazel 允许通过添加自定义规则扩展其支持的目标类型。
为了在 Bazel 中定义规则，规则作者会声明规则所需的输入（以 BUILD 文件中传递的属性的形式）以及规则生成的一组固定输出。作者还定义了该规则将生成的操作每个操作都会声明其输入和输出、运行特定的可执行文件或将特定字符串写入文件，并且可以通过其输入和输出连接到其他操作。这意味着，操作是构建系统中最底层的可组合单元，只要操作仅使用其声明的输入和输出，并且 Bazel 负责安排操作并酌情缓存其结果，即可执行所需的任何操作。
该系统并非万无一失，因为没有办法阻止操作开发者在其操作中引入不确定性流程等操作。但这在实践中并不常见，并且将滥用的可能性一直降低到操作层面，会大大减少出错的机会。支持许多常用语言和工具的规则已在网上广泛提供，并且大多数项目永远不需要定义自己的规则。即使对于那些支持规则定义，规则定义也只需要在存储库中的一个中心位置进行定义，这意味着大多数工程师都可以使用这些规则，而无需担心其实现问题。
隔离环境
操作听起来可能与其他系统中的任务一样遇到同样的问题。是否依然可以编写既写入同一文件但最终相互冲突的操作？实际上，Bazel 使用沙盒实现了这些冲突。在受支持的系统中，每个操作都通过文件系统沙盒与其他操作隔离开来。实际上，每个操作只能看到文件系统的受限视图，其中包含其声明的输入和产生的任何输出。Linux 上的 LXC 等系统强制执行此限制条件，Docker 采用相同的技术。这意味着操作不可能相互冲突，因为它们无法读取未声明的任何文件，并且当操作完成时，它们写入但未声明的所有文件都将被丢弃。Bazel 还使用沙盒来限制操作通过网络进行通信。
使外部依赖项具有确定性
仍然存在一个问题：构建系统通常需要从外部来源下载依赖项（无论是工具还是库），而不是直接构建它们。您可以在示例中通过 @com_google_common_guava_guava//jar 依赖项查看详情，该依赖项可从 Maven 下载 JAR 文件。
依赖当前工作区之外的文件存在风险。这些文件可能会随时发生变化，这可能需要构建系统不断检查它们是否为最新文件。如果远程文件发生更改，而工作区源代码中没有相应的更改，也可能会导致构建不可重现 - 构建可能在某一天成功，而在下一次构建时可能因某个未注意到的依赖项更改而失败，而没有明显的原因。最后，当某个外部依赖项归第三方所有时，可能会带来巨大的安全风险：如果攻击者能够渗透到该第三方服务器，那么他们可以将依赖项文件替换为他们自己的设计，从而能够完全控制您的构建环境及其输出。
根本问题在于，我们希望构建系统能够识别这些文件，而无需将其签入源代码控制系统。更新依赖项应是一项自觉的选择，但该选择应在集中位置进行，而不是由单个工程师管理或由系统自动管理。这是因为，即使对于“Live at Head”模型，我们仍然希望 build 具有确定性，这意味着，如果您签出上周的提交内容，则应该能够按原样（而非现在）查看您的依赖项。
Bazel 和其他一些构建系统可以通过需要一个工作区级清单文件来解决此问题，清单文件列出工作区中的每个外部依赖项的加密哈希。哈希值是一种简洁的文件唯一表示方式，无需将整个文件签入源代码控制系统。每当从工作区引用新的外部依赖项时，该依赖项的哈希都会手动或自动添加到清单中。当 Bazel 运行构建时，它会对照清单中定义的预期哈希检查其缓存依赖项的实际哈希，并仅在哈希不同时重新下载文件。
如果我们下载的工件的哈希与清单中声明的哈希不同，除非更新清单中的哈希，否则构建将失败。此操作可以自动完成，但必须先批准该更改并签入到源代码控制中，然后 build 才会接受新的依赖项。这意味着始终有关于依赖项的更新时间的记录，并且外部依赖项在工作区源代码中没有相应更改的情况下无法更改。这也意味着，在签出较旧版本的源代码时，build 一定会使用签入该版本时所使用的依赖项（否则，如果这些依赖项不再可用，build 将会失败）。
当然，如果远程服务器变得不可用或开始提供损坏的数据，这仍然可能是一个问题。如果您没有该依赖项的其他副本，则可能会导致您的所有构建都开始失败。为避免此问题，我们建议对于任何重要的项目，都将其所有依赖项镜像到您信任和控制的服务器或服务上。否则，对于构建系统的可用性，即使签入的哈希保证其安全性，您也会始终在第三方的当下做出取舍。