本页简要介绍了编写高效 Bazel 规则的具体问题和挑战。
总结要求
- 假设：以正确性、吞吐量、易用性和延迟时间为目标
- 假设：大规模代码库
- 假设：BUILD 类描述语言
- 历史记录：加载、分析和执行之间的硬分离已过时，但仍会影响 API
- 内在：远程执行和缓存很难
- 内在：使用更改信息进行正确且快速的增量 build 需要不寻常的编码模式
- 内在：避免二次时间和内存消耗很难
假设
以下是关于 build 系统的一些假设，例如对正确性、易用性、吞吐量和大规模代码库的需求。以下部分将介绍这些假设，并提供相关指南，以确保规则以有效的方式编写。
追求正确性、吞吐量、易用性和低延迟
我们假设，构建系统首先需要确保增量构建的正确性。对于给定的源代码树，无论输出树是什么样子，同一 build 的输出都应始终相同。从初步近似的角度来看，这意味着 Bazel 需要知道给定构建步骤中的每个输入，以便在任何输入发生更改时重新运行该步骤。Bazel 的正确性存在限制，因为它会泄露一些信息（例如 build 的日期 / 时间），并忽略某些类型的更改（例如文件属性的更改）。沙盒通过防止读取未声明的输入文件来帮助确保正确性。除了系统的内在限制之外，还存在一些已知的正确性问题，其中大多数与 Fileset 或 C++ 规则相关，而这两者都是难题。我们正在长期努力解决这些问题。
构建系统的第二个目标是实现高吞吐量；我们一直在不断突破远程执行服务当前机器分配的限制。如果远程执行服务过载，则没有人能完成工作。
接下来是易用性。在多种具有相同（或相似）远程执行服务占用空间的正确方法中，我们选择更易于使用的方法。
延迟时间是指从开始 build 到获得预期结果所用的时间，无论是通过或失败测试的测试日志，还是 BUILD 文件存在拼写错误时的错误消息。
请注意，这些目标通常会重叠；延迟是远程执行服务吞吐量的一个函数，而正确性与易用性相关。
大规模代码库
构建系统需要在大规模代码库中运行，而大规模意味着代码库无法存储在单个硬盘上，因此几乎所有开发者机器都无法进行完整签出。中型 build 需要读取和解析数万个 BUILD 文件，并评估数十万个 glob。虽然理论上可以在一台机器上读取所有 BUILD 文件，但我们尚未能在合理的时间和内存范围内做到这一点。因此，BUILD 文件必须能够独立加载和解析。
类似于 BUILD 的说明语言
在此背景下，我们假设有一种配置语言，它在声明库和二进制规则及其相互依赖关系方面与 BUILD 文件大致相似。BUILD 文件可以独立读取和解析，并且我们会尽可能避免查看源文件（存在性检查除外）。
历史古迹
不同 Bazel 版本之间存在一些差异，这会带来一些挑战，以下各部分概述了其中一些差异。
加载、分析和执行之间的硬性分离已过时，但仍会影响 API
从技术上讲，规则只需在操作发送到远程执行之前知道操作的输入和输出文件即可。不过，原始 Bazel 代码库严格区分了加载软件包、使用配置（基本上是命令行标志）分析规则，以及仅在之后运行任何操作。即使 Bazel 的核心不再需要这种区分（详见下文），但这种区分仍然是当前规则 API 的一部分。
这意味着规则 API 需要对规则接口（具有哪些属性、属性的类型）进行声明式描述。不过，在某些例外情况下，API 允许在加载阶段运行自定义代码，以计算输出文件的隐式名称和属性的隐式值。例如，名为“foo”的 java_library 规则会隐式生成名为“libfoo.jar”的输出，该输出可从 build 图中的其他规则进行引用。
此外，规则的分析无法读取任何源文件或检查操作的输出；相反，它需要生成一个部分有向二分图，其中包含仅根据规则本身及其依赖项确定的 build 步骤和输出文件名。
固有可解释性
有些内在属性使得规则编写具有挑战性，以下部分介绍了其中一些最常见的属性。
远程执行和缓存很难
与在单台机器上运行 build 相比，远程执行和缓存可将大型代码库中的 build 时间缩短大约两个数量级。不过，它需要执行的规模非常庞大：Google 的远程执行服务旨在每秒处理大量请求，并且该协议会仔细避免不必要的往返以及服务侧的不必要工作。
目前，该协议要求构建系统提前了解给定操作的所有输入；然后，构建系统会计算唯一的操作指纹，并向调度程序请求缓存命中。如果找到缓存命中，调度程序会回复输出文件的摘要；文件本身稍后会通过摘要寻址。不过，这会限制 Bazel 规则，因为这些规则需要提前声明所有输入文件。
使用更改信息进行正确且快速的增量 build 需要采用不寻常的编码模式
上文中，我们认为，为了确保正确性，Bazel 需要知道构建步骤中涉及的所有输入文件，以便检测该构建步骤是否仍然是最新的。软件包加载和规则分析也是如此，我们设计了 Skyframe 来处理这些情况。Skyframe 是一个图库和评估框架，它会获取目标节点（例如“使用这些选项构建 //foo”），并将其分解为组成部分，然后对这些部分进行评估并组合，从而得出结果。在此过程中，Skyframe 会读取软件包、分析规则并执行操作。
在每个节点上，Skyframe 都会准确跟踪任何给定节点用于计算自身输出的节点，从目标节点一直到输入文件（也是 Skyframe 节点）。在内存中明确表示此图，可让构建系统准确识别哪些节点会受到输入文件（包括输入文件的创建或删除）的给定更改的影响，从而以最少的工作量将输出树恢复到预期状态。
在此过程中，每个节点都会执行依赖项发现流程。每个节点都可以声明依赖项，然后使用这些依赖项的内容来声明更多依赖项。从原则上讲，这与每个节点的线程模型非常契合。不过，中型 build 包含数十万个 Skyframe 节点，这在当前 Java 技术下很难实现（出于历史原因，我们目前只能使用 Java，因此无法使用轻量级线程和延续）。
相反，Bazel 使用的是固定大小的线程池。不过，这意味着如果某个节点声明了尚不可用的依赖项，我们可能必须中止该评估，并在依赖项可用时重新开始评估（可能在另一个线程中）。这反过来意味着节点不应过度执行此操作；如果节点串行声明 N 个依赖项，则可能会重启 N 次，从而花费 O(N^2) 时间。相反，我们力求预先批量声明依赖项，这有时需要重组代码，甚至将一个节点拆分为多个节点，以限制重启次数。
请注意，此技术目前在规则 API 中尚不可用；相反，规则 API 仍使用加载、分析和执行阶段的旧版概念进行定义。不过，一个基本限制是，对其他节点的所有访问都必须通过框架进行，以便框架可以跟踪相应的依赖项。无论构建系统采用哪种语言实现，或者规则采用哪种语言编写（不必相同），规则作者都不得使用绕过 Skyframe 的标准库或模式。对于 Java，这意味着要避免使用 java.io.File 以及任何形式的反射，还要避免使用任何执行上述操作的库。支持对这些低级接口进行依赖项注入的库仍需要针对 Skyframe 正确设置。
这强烈建议避免让规则作者一开始就接触完整的语言运行时。意外使用此类 API 的风险实在太大了 - 过去，即使规则是由 Bazel 团队或其他领域专家编写的，但仍有多个 Bazel bug 是由使用不安全 API 的规则引起的。
避免二次时间和内存消耗很难
更糟糕的是，除了 Skyframe 施加的要求、使用 Java 的历史限制以及规则 API 的过时之外，意外引入二次时间或内存消耗是基于库和二进制规则的任何构建系统中的一个根本性问题。有两种非常常见的模式会导致二次内存消耗（进而导致二次时间消耗）。
库规则链 - 考虑这样一种情况：库规则链 A 依赖于 B，B 依赖于 C，依此类推。然后，我们希望计算这些规则的传递闭包的某些属性，例如 Java 运行时类路径或每个库的 C++ 链接器命令。从表面上看，我们可能会采用标准列表实现；但是，这已经引入了二次内存消耗：第一个库在 classpath 上包含一个条目，第二个库包含两个条目，第三个库包含三个条目，依此类推，总共有 1+2+3+...+N = O(N^2) 个条目。
依赖于同一库规则的二进制规则 - 考虑这样一种情况：一组二进制文件依赖于同一库规则，例如，您有多个测试规则用于测试同一库代码。假设在 N 条规则中，一半是二进制规则，另一半是库规则。现在，假设每个二进制文件都会复制一些通过库规则的传递闭包计算出的属性，例如 Java 运行时类路径或 C++ 链接器命令行。例如，它可以展开 C++ 链接操作的命令行字符串表示形式。N/2 个 N/2 元素的副本需要 O(N^2) 内存。
自定义集合类，以避免二次复杂度
Bazel 受到这两种情况的严重影响，因此我们引入了一组自定义集合类，通过避免在每个步骤中进行复制来有效地压缩内存中的信息。几乎所有这些数据结构都具有集合语义，因此我们将其称为 depset（在内部实现中也称为 NestedSet）。在过去几年中，为减少 Bazel 的内存消耗而进行的大部分更改都是将之前使用的任何内容替换为 depsets。
遗憾的是，使用 depset 并不能自动解决所有问题；特别是，即使只是在每个规则中迭代 depset，也会重新引入二次时间消耗。在内部，NestedSets 还提供了一些辅助方法，以方便与常规集合类进行互操作；遗憾的是，如果不小心将 NestedSet 传递给其中一种方法，会导致复制行为，并重新引入二次内存消耗。