Bazel 术语表

<ph type="x-smartling-placeholder"></ph> 报告问题 查看来源 敬上 每晚 · 7.3。 · 7.2。 · 7.1。 · 7.0。 · 6.5

操作

要在构建期间运行的命令,例如,对 工件作为输入,并生成其他工件作为输出。 包括命令行参数、操作键、环境等元数据 变量和声明的输入/输出工件。

另请参阅规则文档

操作缓存

一个磁盘缓存,用来存储已执行的操作到 输出的内容。缓存键称为“操作键”。答 核心组件。缓存存储在 输出基本目录,因此在 Bazel 服务器重启后仍然有效。

操作图

内存中的操作工件 这些操作会读取和生成该图可能包含 源文件(例如文件系统中)和生成的 BUILD 文件中未提及的中间/最终工件。生产日期 在分析阶段使用,并在执行 阶段

操作图表查询 (aquery)

可以对构建操作进行查询的查询工具。 通过这种方式,您可以分析构建规则如何转化为 实际工作。

快捷操作按键

操作的缓存键。根据操作元数据计算得出 可能包括要在操作中执行的命令、编译器标记、库 或系统标头,具体取决于操作。让 Bazel 能够缓存或 确定性地让各个操作失效。

分析阶段

构建的第二阶段。处理目标图表 BUILD 文件中指定的对象生成内存中操作 图表的图表。 执行阶段。在这个阶段, 评估的实现情况。

制品

源文件或生成的文件。也可以是文件目录,也称为 树状工件

一个工件可以作为多个操作的输入,但只能由 最多一项操作

文件目标对应的工件可以通过 标签。

方面

一种机制,供规则在其内容中创建额外操作 依赖项例如,如果目标 A 依赖于目标 B,则可以在 A 从依赖项边缘向上遍历到 B,并在 B 中运行额外操作 生成并收集其他输出文件。这些额外操作包括 在需要相同方面的目标之间缓存和重复使用。使用 aspect() Starlark Build API 函数。例如,可用于生成 元数据,并创建用于执行 lint 请求的操作。

另请参阅切面文档

纵横比

一种合成机制,据此机制可将切面应用于结果 相较于其他方面例如,一个切面可以生成供 可以将 IDE 应用于根据从 API 生成 .java 文件的切面, proto。

若要在切面 B 之上应用切面 A,需要应用该切面的提供程序B 在其 provides 属性中通告 必须与 A 在其 required_aspect_providers 中声明的内容一致 属性。

属性

规则的参数,用于表示每个目标的 build 信息。 示例包括 srcsdepscopts,它们分别声明了 目标的源文件、依赖项和自定义编译器选项。通过 属性是否适用于给定目标取决于其规则类型。

.bazelrc

Bazel 的配置文件,用于更改 startup 标志命令标志,以及定义常用的 一组选项,随后可在 Bazel 命令行中使用 --config 标志。Bazel 可以组合多个 bazelrc 文件中的设置 (系统级、每个工作区、每个用户或从自定义位置) bazelrc 文件还可以从其他 bazelrc 文件中导入设置。

Blaze

Google 内部版本的 Bazel。主要的构建系统 mono-repository。

BUILD 文件

BUILD 文件是主配置文件,用于告知 Bazel 哪些软件 要构建的输出,它们的依赖项是什么,以及如何构建它们。Bazel 将 BUILD 文件作为输入,并使用该文件创建依赖关系图 确定需要完成哪些操作才能构建 软件输出。BUILD 文件标记了一个目录及所有未包含的子目录 包含 BUILD 文件(作为软件包),并且可以包含 根据规则创建的目标。该文件还可以命名为 BUILD.bazel

BUILD.bazel 文件

请参阅 BUILD 文件。在同一实例中,优先级高于 BUILD 文件 目录。

.bzl 文件

用于定义规则、和常量的文件,以 Starlark。然后,这些内容可以导入到 BUILD 文件使用 load() 函数。

构建图表

Bazel 为执行构建而构建和遍历的依赖关系图。 包括目标等节点,已配置 目标操作工件。答 如果所有包含一组工件工件 所请求目标依赖的验证结果为最新。

构建设置

Starlark 定义的一段配置过渡可设置构建设置以更改子图的 配置。如果以命令行标志的形式向用户显示: 也称为构建标志

干净 build

不使用早期构建结果的构建。速度通常较慢 而非增量构建,但通常被视为 正确。Bazel 可保证干净构建和增量构建 始终正确。

客户端-服务器模式

bazel 命令行客户端会自动在 在本地机器上执行 Bazel 命令。服务器始终 但会在一段时间不活动(或者明确通过 bazel 关停)。将 Bazel 拆分为服务器和客户端有助于分摊 JVM 启动时间,并且支持更快的增量构建 因为在执行各种命令时,操作图都会保留在内存中。

命令

在命令行上用于调用不同的 Bazel 函数,例如 bazel buildbazel testbazel runbazel query

命令标志

特定于某个命令的一组标志。已指定命令标志 命令 (bazel build <command flags>) 之后。标志可以应用于 一条或多条命令例如,--configure 是专用于 bazel sync 命令,但 --keep_going 适用于 syncbuildtest及更多。标志通常用于配置 因此,对标志值进行更改可能会导致 Bazel 使内存中失效 图表,然后重新开始分析阶段

配置

规则定义之外影响规则生成方式的信息 操作。每个构建都至少有一个配置指定 目标平台、操作环境变量和命令行 build 标志转场效果可能会带来 例如针对主机工具或交叉编译的配置。

另请参阅配置

配置删减

只将配置和 目标。例如,如果您使用 C++ 构建 Java 二进制文件 //:j, 依赖项 //:c,将 --javacopt 的值添加到 //:c 的配置,因为更改 --javacopt 会不必要地破坏 C++ 构建可缓存性

配置的查询 (cquery)

一个查询工具,用于对配置的 目标(在分析阶段后 完成)。这意味着 select()构建标志(例如 --platforms)会准确反映在结果中。

另请参阅cquery 文档

配置的目标

使用 配置分析阶段会生成 方法是将构建选项与需要构建的目标结合起来。 例如,如果 //:foo 在同一项目为两个不同的架构进行构建, 它有两个已配置的目标:<//:foo, x86><//:foo, arm>

正确性

如果构建的输出如实反映其状态,则表示构建正确。 传递性输入。为了实现正确的构建,Bazel 封闭、可重现且使构建 分析行动执行 是确定性的。

依赖项

两个目标之间的有向边。目标 //:foo 具有目标 对目标 //:bar 的依赖关系(如果 //:foo 的属性值包含 对 //:bar 的引用。如果发生以下情况,则 //:foo 具有 //:bar操作依赖项//:foo”中的操作依赖于//:bar 中执行该操作。

在某些情况下,它也可能指外部依赖项;请参阅 模块

取消设置

一种数据结构,用于收集传递依赖项的相关数据。优化 合并训练时可以节省时间和空间, 非常庞大的依赖项(数十万个文件)。实施对象 出于空间效率原因,递归引用其他设置。规则 实现不得“扁平化”从而避免客户流失 该规则位于构建图的顶层。展平大量偏移, 大量内存消耗在 Bazel 的内部,也称为嵌套集。 实施。

另请参阅设置文档

磁盘缓存

用于远程缓存功能的本地磁盘 blob 存储区。可用于 与实际的远程 blob 存储区结合使用。

一个只读目录,包含 Bazel 原本会从 使用代码库规则管理互联网使构建能够完全离线运行。

动态执行

根据在本地执行和远程执行之间选择的执行策略, 各种启发词语,并使用较快成功执行任务的执行结果, 方法。某些操作在本地执行得更快(例如, 而有些则可提升远程速度(例如,高度可并行 编译)。动态执行策略可以提供 增量和整洁构建时间。

执行阶段

构建的第三阶段。在操作中执行操作 图表创建于分析阶段。 这些操作会调用可执行文件(编译器、脚本)来读取和写入 工件生成策略用于控制这些操作的执行方式 执行方式:本地、远程、动态、沙盒化、docker 等。

执行根

工作区输出库中的一个目录 执行本地操作的目录 非沙盒化 build。目录内容大多是符号链接 来自工作区的输入工件。执行根 包含指向外部代码库的符号链接(作为其他输入)和 bazel-out 用于存储输出内容。在加载阶段准备 方法是创建代表传递变量的目录的符号链接林 关闭构建所依赖的软件包可通过在命令行中使用 bazel info execution_root 进行访问。

文件

请参阅Artifact

Hermeticity

如果 build 的 build 和测试没有外部影响,则该 build 就是封闭的 这可帮助确保结果具有确定性 正确。例如,封闭构建通常会禁止使用网络 对操作的访问权限、限制对声明的输入的访问权限、使用固定时间戳和 时区,限制对环境变量的访问,并将固定的种子用于 随机数生成器

增量构建

增量构建会重复使用之前构建的结果来缩短构建时间 资源用量。依赖项检查和缓存旨在 结果。增量 build 与干净 build 相反 build。

标签

目标的标识符。通常采用以下形式: @repo//path/to/package:target,其中 repo 是 包含目标的代码库path/to/package 是路径 BUILD 文件所在的目录 target(此目录也称为软件包),以及 target 是目标本身的名称。根据具体情况 语法可以省略。

另请参阅标签

加载阶段

构建的第一个阶段,Bazel 会执行 BUILD 文件 创建软件包和某些功能,例如 在此阶段评估 glob()。该系列节目的第二阶段 也就是分析阶段,以建立目标 图表

一种将多个规则目标声明组合在一起的机制, 一个 Starlark 函数。允许重复使用常用规则声明 多个 BUILD 文件中的格式。扩展至基础规则目标 在加载阶段进行声明。

另请参阅宏文档

助记符

规则制定者选择的人类可读的简短字符串,用于快速理解 规则中的操作所执行的操作。助记符可以用作 spawn strategy 选项的标识符。操作助记符的一些示例 Java 规则中的 Javac、C++ 规则中的 CppCompile,以及 AndroidManifestMerger

模块

可以有多个版本的 Bazel 项目,每个版本可以有 对其他模块的依赖项这类似于其他 依赖项管理系统,如 Maven 工件、npm 软件包、 转到 module 或 Cargo crate。模块构成了 Bazel 外部 依赖项管理系统

每个模块均由一个 repo 支持,该 MODULE.bazel 文件位于其 根。此文件包含有关模块本身的元数据(例如模块名称和模块) 其直接依赖项以及各种其他数据,包括工具链 注册和模块扩展输入。

模块元数据托管在 Bazel 注册表中。

另请参阅Bazel 模块

模块扩展

可以运行以生成代码库(通过读取 来自整个模块依赖关系图的输入并调用 repo 规则。模块扩展具有与 repo 类似的功能 允许它们访问互联网、执行文件 I/O 等。

另请参阅模块扩展

原生规则

内置在 Bazel 中并在 Java 中实现的规则。此类规则 在 .bzl 文件中显示为原生模块(针对 (例如 native.cc_librarynative.java_library)。用户定义的规则 (非原生)是使用 Starlark 创建的。

基本输出

用于存储 Bazel 输出文件的工作区专用目录。已使用 将输出与工作区的源代码树(主 repo)。位于输出用户根目录中。

输出组

Bazel 完成构建 目标。规则会将其常规输出放入“默认输出组”中 (例如,cc_libraryjava_library.a.so.jar 文件 目标)。默认输出群组是指 工件是在命令行中请求目标时构建的。 规则可以定义更多已命名的输出组,这些组可在 BUILD 文件filegroup 规则)或命令行 (--output_groups 标记)。

输出用户根目录

特定于用户的目录,用于存储 Bazel 的输出。目录名称为 用户的系统用户名。如果出现以下情况,可防止输出文件冲突 多个用户同时在系统上构建同一项目。 包含与各个工作区的构建输出相对应的子目录, 也称为“输出碱基”。

软件包

BUILD 文件定义的一组目标。答 软件包名称是 BUILD 文件相对于代码库的路径 根。软件包可以包含子软件包或包含 BUILD 的子目录 文件,从而形成软件包层次结构。

软件包组

表示一组软件包的目标。经常用于visibility 属性值。

平台

“机器类型”都参与了构建活动这包括运行 Bazel 的机器 (“主机”平台)、机器构建工具在(“exec”平台)上执行, 而机器的目标则是专为(“目标平台”)而构建的。

提供商

一种架构,用于描述要在两者之间传递的信息单元 规则目标以及依赖关系。通常情况下, 包含编译器选项、传递源文件或输出文件等信息 和构建元数据经常与 depsets 结合使用, 高效存储累积的传递数据。内置提供程序示例 为 DefaultInfo

另请参阅提供程序文档

查询(概念)

分析 build 图以理解的过程 target 属性和依赖项结构。Bazel 支持 查询变体:querycqueryaquery

query(命令)

对 build 的加载后事件运行的查询工具 阶段 目标图表。这个速度相对较快 但无法分析 select()build 标志工件或构建操作

另请参阅查询方法查询参考

代码库

一个目录树,其根目录下有一个边界标记文件,该文件包含源代码 支持在 Bazel 构建中使用的各种文件通常缩写为“repo”

代码库边界标记文件可以是 MODULE.bazel(表示此代码库 代表 Bazel 模块)、REPO.bazel;在旧版上下文中,则 WORKSPACEWORKSPACE.bazel。任何 Repo 边界标记文件都将表示 repo;一个目录中可以共存多个此类文件。

主代码库是运行当前 Bazel 命令的代码库。

外部代码库通过在 MODULE.bazel 中指定模块来定义 文件,或在模块中调用 repo 规则 扩展程序。系统可以按需提取它们 “神奇”磁盘上的位置

每个代码库都有一个唯一的常量规范名称,并且可能不同的 明显名称。

另请参阅外部依赖项概览

代码库缓存

Bazel 为构建下载的文件的共享内容可寻址缓存; 可跨工作区共享。在 初始下载。通常用于缓存通过存储库下载的文件 规则(例如http_archive)和仓库规则 API(例如 repository_ctx.download。仅当文件的 SHA-256 校验和为 指定的下载资源。

仓库规则

代码库定义的架构,用于告知 Bazel 如何具体化(或者 “获取”)一个代码库。通常简称为“repo rule”。 Bazel 会在内部调用 Repo 规则,以定义 模块,也可以由模块扩展调用。 Repo 规则可以访问互联网或执行文件 I/O;最常用的代码库 http_archive,则从 。

另请参阅代码库规则文档

可再现性

build 或测试的属性,用于构建或测试的一组输入将 无论何时、如何、无论如何,每次都会生成相同的输出集。 或环境请注意,这并不一定意味着 正确或所需的输出。

规则

用于在 BUILD 文件中定义规则目标的架构,例如 cc_library。从 BUILD 文件作者的角度来看,规则包含 一组属性和黑盒逻辑。该逻辑会 规则目标如何生成输出工件并将信息传递给 其他规则目标。从 .bzl 位作者的角度来看,规则是 扩展 Bazel 以支持新编程语言和 环境

对规则进行实例化,以生成 加载阶段。在分析阶段规则中 目标以 提供程序,并注册操作以说明如何 生成其输出工件。这些操作在执行 阶段

另请参阅规则文档

规则目标

作为规则实例的目标。与文件目标相对 和软件包组。请勿与规则混淆。

Runfile

可执行目标的运行时依赖项。最常见的情况是, executable 是指测试规则的可执行输出,runfile 是指运行时 测试的数据依赖项。在调用可执行文件之前(在 bazel 测试),Bazel 会准备运行文件树以及测试可执行文件 根据其源目录结构进行构建。

另请参阅Runfiles 文档

沙盒

一种用于隔离受限和受限内运行操作的技术 临时执行根,帮助确保它 读取未声明的输入或写入未声明的输出。沙盒功能大大改进了 封闭性,但通常会降低性能,并且需要 操作系统支持。性能成本取决于平台。 在 Linux 上,这不重要,但在 macOS 上可能会导致沙盒无法使用。

SkyFrame

Skyframe 是 Bazel 的核心并行、功能和增量评估框架。

冲压

将额外信息嵌入到 Bazel 构建的功能 工件。例如,这可用于控制源代码、 以及发布 build 的其他工作区或环境相关信息。 通过 --workspace_status_command 标志和规则启用, 支持邮票属性。

星鸟星

用于编写规则的扩展语言。答 Python 的语法和语法上的受限子集,旨在 以及获得更好的性能。使用 .bzl 文件扩展名。BUILD 个文件使用 Starlark 的受限版本(例如没有 def 函数定义),之前 叫做 Skylark

另请参阅Starlark 语言文档

启动标志

bazel命令之间指定的一组标志。 例如 bazel --host_jvm_debug build。这些标志用于修改 配置,因此对 Bazel 服务器的任何修改 启动标志会导致服务器重启。启动标志不特定于任何一项 命令。

目标

一个在 BUILD 文件中定义的对象,由 标签。目标表示工作区的可构建单元, 从最终用户的角度出发

通过实例化规则来声明的目标称为规则 目标值。这些容器可能可以运行(如 cc_binary)或可测试(例如 cc_test)。规则目标通常取决于 其他目标的属性(例如 deps);这些内容 依赖关系构成了目标图的基础。

除了规则目标之外,还有文件目标和软件包组 目标。文件目标与引用的工件相对应 放置在 BUILD 文件中。一种特殊情况是,任何软件包的 BUILD 文件都是 始终被视为该软件包中的源文件目标。

目标是在加载阶段发现的。在 分析阶段,则目标会与构建 形成已配置的 目标。

目标图表

目标及其依赖关系的内存图。制作期间 加载阶段并用作分析的输入内容 阶段

目标模式

一种在命令行中指定一组目标的方法。经常 使用的格式为 :all(所有规则目标)、:*(所有规则 + 文件目标)、 ...(当前软件包和所有子软件包以递归方式)。可以使用 组合使用(例如,//...:* 表示所有 从工作区的根目录以递归方式打包这些软件包。

测试

规则 targets 从测试规则实例化而来,因此包含一个 测试可执行文件。可执行文件完成后的返回代码为零 表示测试成功。Bazel 和测试(例如 test 环境变量、测试结果收集方法)在 Test 百科全书

工具链

一组用于为语言构建输出的工具。工具链通常包括 编译器、链接器、解释器和/和 linter。工具链也会因 换言之,Unix 编译器工具链的组件可能会因 Windows 变体,即使工具链适用于相同的语言,也是如此。正在选择 适合平台的正确工具链称为工具链解析。

顶级目标

如果通过 Bazel 命令请求构建目标,则该目标就是顶级的 行。例如,如果 //:foo 依赖于 //:bar,而 bazel build //:foo 依赖于 那么对于此 build,//:foo 是顶级,//:bar 不是顶级 但这两个目标都需要构建。重要区别 顶级目标和非顶级目标之间的不同之处在于,命令 标志(或通过 .bazelrc)将针对顶级域名设置配置 目标,但可能会因非顶级广告系列的过渡而发生变化 目标。

转换

配置状态从一个值到另一个值的映射。 使 build 图中的目标具有不同的 即使它们是基于同一规则实例化的,也是如此。答 过渡的常见用途是拆分过渡,其中某些部分 目标图复刻了不同的配置, 例如,您可以使用原生二进制文件构建 Android APK 在单个 build 中使用拆分转换针对 ARM 和 x86 进行编译。

另请参阅用户定义的转换

树制品

表示文件集合的工件。由于这些 文件本身并非软件制品,因此对它们执行操作必须 而是将树制品注册为其输入或输出。

公开范围

阻止构建系统中不需要的依赖项的两种机制之一: 目标可见性,用于控制是否可以依赖某个目标 被其他目标所取代以及用于控制 BUILDload 可见性。 或 .bzl 文件可以加载指定的 .bzl 文件。如果没有背景信息, “可见性”是指目标可见性。

另请参阅“公开范围”文档

工作区

所有 Bazel 命令共享的环境从同一个主主目录运行 代码库

请注意,过去“仓库”的概念和“workspace”曾经 混淆;术语“工作区”通常用于指代 有时甚至被用作“仓库”的同义词。此类使用情况 为清晰起见,应避免使用