编写规则的挑战

报告问题 查看来源 每晚 · 7.4。 ，了解所有最新动态。 7.3 · 7.2 · 7.1 · 7.0 · 6.5

本页将简要介绍面临的具体问题和挑战 编写有效的 Bazel 规则

摘要要求

  • 假设：力求实现正确性、吞吐量、易用性和延迟时间
  • 假设：大型代码库
  • 假设：类似于 build 的说明语言
  • 历史记录：加载、分析和执行之间的硬分离已过时，但仍会影响 API
  • 固有可解释性：远程执行和缓存很难
  • 内在：使用更改信息以实现正确且快速的增量 build 需要采用不寻常的编码模式
  • 固有可解释性：避免二次时间和内存消耗并非易事

假设

以下是关于构建系统的一些假设 正确性、易用性、吞吐量和大型存储库。通过 以下部分介绍了这些假设，并提供了相关指南， 制定有效的规则。

力求实现正确性、吞吐量、易用性和延迟时间

我们假设构建系统首先必须确保正确运行 与增量构建相比较对于指定的源代码树， 无论输出树是什么样子，同一 build 应始终相同 类似。对于第一种情形，这意味着 Bazel 需要了解 该输入会进入指定构建步骤，以便在任何情况下可以重新运行该步骤 变化。Bazel 可以获得的信息准确性是有限制的，因为它会泄露一些信息（例如构建日期/时间），并会忽略某些类型的更改（例如文件属性的更改）。沙盒 通过防止读取未声明的输入文件来帮助确保正确性。除了系统固有限制之外，还有一些已知的正确性问题，其中大多数与文件集或 C++ 规则相关，这两个问题都很难解决。我们会长期努力解决这些问题。

构建系统的第二个目标是实现高吞吐量；我们会不断突破当前机器分配范围内可为远程执行服务执行的操作的边界。如果远程执行 服务过载，没有人可以完成工作。

易用性是下一个问题。在具有相同（或类似）远程执行服务占用空间的多种正确方法中，我们会选择更易于使用的一种。

延迟时间表示从开始构建到实现预期目标所需的时间 比如来自通过或失败测试的测试日志， 显示 BUILD 文件存在拼写错误的消息。

请注意，这些目标通常会重叠；延迟时间与远程执行服务的吞吐量密切相关，而易用性与正确性密切相关。

大型代码库

构建系统需要在大型代码库的规模下运行，而大型代码库 意味着它不适合安装在单个硬盘上， 在几乎所有开发者机器上进行全面结账。一个中等规模的 build 需要读取和解析数万个 BUILD 文件，并评估数十万个正则表达式。虽然理论上可以在一台机器上读取所有 BUILD 文件，但我们尚未能在合理的时间和内存用量内做到这一点。因此，BUILD 文件 可以独立加载和解析

类似于 BUILD 的说明语言

在此上下文中，我们假设配置语言 大致类似于库和二进制文件规则声明中的 BUILD 文件 及其相互依赖性。BUILD 文件可以独立读取和解析，我们尽可能避免查看源文件（除了检查是否存在之外）。

历史古迹

Bazel 版本之间存在差异，这些差异会造成一些问题，以下各部分概述了其中的一些问题。

加载、分析和执行之间硬性分离已过时，但仍会影响 API

从技术层面来说，只要在将操作发送到远程执行之前，规则知道操作的输入和输出文件即可。不过， 原始 Bazel 代码库对加载软件包进行了严格分离， 使用配置（实际上就是命令行标志）分析规则，以及 然后才能运行任何操作尽管 Bazel 的核心不再需要此区分，但此区分目前仍是 Rules API 的一部分（详见下文）。

这意味着，Rules API 需要规则的声明式说明 接口（它具有什么属性、属性类型）。在某些例外情况下，该 API 允许在加载阶段运行自定义代码，以计算输出文件的隐式名称和属性的隐式值。例如，名为“foo”的 java_library 规则会隐式生成名为“libfoo.jar”的输出，该输出可从 build 图中的其他规则引用。

此外，分析规则时无法读取任何源文件或检查 操作的输出；而是需要生成部分定向的两部分 显示仅根据规则确定的构建步骤和输出文件名的图表 及其依赖项。

固有可解释性

有些固有属性会使编写规则变得非常困难，以下部分介绍了一些最常见的属性。

远程执行和缓存很难

远程执行和缓存可缩短大型代码库中的构建时间，具体方法是 与在单个集群上运行构建相比 虚拟机。然而，它需要的规模令人难以置信：Google 的 远程执行服务旨在为每个网站处理大量请求， 其次，该协议会谨慎地避免不必要的往返 在服务端进行不必要的工作

目前，协议要求构建系统知道 提前执行特定操作；然后，构建系统会计算 指纹，并向调度程序请求缓存命中。如果找到缓存命中，调度程序会回复输出文件的摘要；文件本身稍后会通过摘要进行寻址。但是，这会对 Bazel 规则，因此需要提前声明所有输入文件。

使用更改信息来正确快速地进行增量构建需要采用不同寻常的编码模式

在上文中，我们认为，要判断真伪，Bazel 需要知道 文件，以检测该构建步骤是否 保持最新状态软件包加载和规则分析也是如此，我们设计了 Skyframe 来处理这类问题。Skyframe 是一个图表库和评估框架，它接受 目标节点（例如“build //foo with these options”），并将其分解为 并对其进行评估和组合，得出 结果。在此过程中，Skyframe 会读取软件包、分析规则并执行操作。

在每个节点上，Skyframe 会准确跟踪任何给定节点用于计算 这一过程从目标节点一直到输入文件（ 也是 Skyframe 节点）。在内存中明确表示此图 可以让构建系统准确识别 更改输入文件（包括创建或删除输入文件）、 将输出树恢复到预期状态所需的最少工作量。

在此过程中，每个节点都会执行依赖项发现流程。每个节点都可以声明依赖项，然后使用这些依赖项的内容声明更多依赖项。从原则上讲，这与“每个节点一个线程”模型非常契合。不过，中型 build 包含数百个 成千上万个 Skyframe 节点并不容易， （由于历史原因，我们目前与 Java 密切相关， 没有轻量级线程和连续）。

但 Bazel 使用的是固定大小的线程池。不过，这意味着，如果某个节点声明的依赖项尚不可用，那么当该依赖项可用时，我们可能需要中止该评估并重新启动它（可能在另一个线程中）。这也意味着节点不应过度执行此操作；一 连续声明 N 个依赖项的节点有可能会重启 N 次， 花费 O(N^2) 时间。相反，我们旨在预先批量声明依赖项，这有时需要重新整理代码，甚至将一个节点拆分为多个节点，以限制重启次数。

请注意，Rules API 目前不支持此技术；改为 但规则 API 仍然使用传统的加载、分析、 和执行阶段。不过，有一个基本限制是，对其他节点的所有访问都必须通过该框架，以便它能够跟踪相应的依赖项。无论构建系统是采用哪种语言实现的，或者规则是采用哪种语言编写的（这两种语言不必相同），规则作者都不得使用绕过 Skyframe 的标准库或模式。对于 Java，这意味着避免使用 java.io.File 以及任何形式的反射，以及任何执行上述操作的库。支持依赖项的库 您仍然需要正确设置这些低级别接口的注入， Skyframe。

因此，强烈建议从一开始就避免向规则作者公开完整的语言运行时。意外使用此类 API 的危险性太大了 - 过去的多个 Bazel bug 都是由使用不安全 API 的规则造成的，即使这些规则是由 Bazel 团队或其他领域专家编写的。

避免时间和内存消耗呈二次方增长很难

更糟糕的是，除了 Skyframe 施加的要求之外， 使用 Java 的历史限制以及规则 API 的过时 意外引入二次时间或内存消耗是 问题。有两种非常常见的模式会导致二次内存消耗（因此也会导致二次时间消耗）。

  1. 库规则链 - 假设库规则链 A 依赖于 B，B 依赖于 C，依此类推。然后，我们希望根据这些规则的传递闭包计算某些属性，例如 Java 运行时类路径或每个库的 C++ 链接器命令。粗略地说，我们可以采用标准列表实现；不过，这已经引入了二次方内存用量：第一个库在类路径中包含一个条目，第二个库包含两个条目，第三个库包含三个条目，依此类推，总计为 1+2+3+...+N = O(N^2) 个条目。

  2. 依赖于相同库规则的二进制规则 - 假设一组二进制文件依赖于同一个库 例如，如果您有多个测试规则测试同一个 库代码中。假设在 N 条规则中，有一半的规则是二进制规则，另一半是库规则。现在假设每个二进制文件都会复制某个属性，该属性是根据库规则的传递闭包计算得出的，例如 Java 运行时类路径或 C++ 链接器命令行。例如， 可以扩展 C++ 链接操作的命令行字符串表示法。不适用 N/2 个元素的副本为 O(N^2) 内存。

自定义集合类，以避免二次复杂度

这两种情况都会严重影响 Bazel，因此我们针对 自定义集合类，可有效地压缩内存中的信息， 避免在每一步复制代码。这些数据结构中的几乎所有 所以我们称之为 depset （在内部实现中也称为 NestedSet）。大部分 过去几年中旨在减少 Bazel 内存消耗量的变化 更改为使用 depsets，而不是之前所用的任何内容。

遗憾的是，使用 depset 并不能自动解决所有问题；特别是，即使只是在每个规则中迭代 depset，也会重新引入二次方时间消耗。在内部，NestedSets 也有一些辅助方法 方便与常规集合类的互操作性；很抱歉 不小心将 NestedSet 传递给其中一种方法会导致复制 行为，并重新引入二次内存消耗。