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