Bazel 术语库

操作

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

另请参阅规则文档

操作缓存

磁盘缓存,用于存储已执行操作的映射与其创建的输出的映射。 缓存键被称为操作键。 Bazel 的增量模型的核心组件。缓存存储在输出基目录中,因此在 Bazel 服务器重启后仍然有效。

操作图表

操作的内存区域图,以及这些操作读取和生成的工件。该图可能包括以源代码文件形式存在的工件(例如,在文件系统中)以及未包含在 BUILD 文件中的生成的中间/最终工件。在分析阶段中生成,并在执行阶段中使用。

操作图查询 (aquery)

一种查询工具,可查询构建操作。 这样,就能够分析构建规则如何转化为实际工作。

操作键

操作的缓存键。根据操作元数据计算,可能包括要针对操作、编译器标志、库位置或系统头文件执行的命令,具体取决于操作。使 Bazel 能够确定性地缓存或使个别操作失效。

分析阶段

构建过程的第二阶段。处理 BUILD 文件中指定的目标图,以生成内存中用于确定操作顺序的操作图需要在执行阶段中运行的操作。这是评估规则实现的阶段。

工件

源文件或生成的文件。也可以是文件目录,称为“树工件”。树工件是 Bazel 的黑盒:Bazel 不会将树工件中的文件视为单独的工件,因此无法直接引用它们作为操作输入 / 输出。工件可以是多项操作的输入,但最多只能由一项操作生成。

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

另请参阅Facets 文档

宽高比

一种宽高比合成机制,可以将宽高比应用于其他方面。对于检查对象 B 的 A,必须从 B 中声明所需的 providers(使用 required_aspect_providers 属性),而 B 必须声明提供程序(使用 provides 属性)返回。例如,IDE 可以使用此方法来使用各方面(如 java_proto_library 方面)生成的信息生成文件。

.yamlrc

Bazel 的配置文件,用于更改启动标志命令标志的默认值,以及定义随后可一起设置的常见选项组使用 --config 标志的 Bazel 命令行。Bazel 可以合并多个 Bazelrc 文件(系统范围、每个工作区、每位用户或自定义位置)中的设置,并且 bazelrc 文件也可以从其他 bazelrc 文件中导入设置中披露政府所要求信息的数量和类型。

Blaze

Google 内部版本的 Bazel。Google 的单代码库主要构建系统。

构建文件

BUILD 文件是主配置文件,用于告知 Bazel 要构建哪些软件输出、它们的依赖项以及如何构建它们。Bazel 将 BUILD 文件作为输入,并使用该文件创建依赖关系图并派生构建中间和最终软件输出必须完成的操作。BUILD 文件将一个目录以及不包含 BUILD 文件的任何子目录标记为软件包,并且可以包含目标规则创建。该文件的名称还可以为 BUILD.bazel

BUILD.Bazel 文件

请参阅 BUILD 文件。优先于同一目录中的 BUILD 文件。

.bzl 文件

一个文件,用于定义使用 Starlark 编写的规则、和常量。然后可以使用 load() 函数将其导入 BUILD 文件

build 图

Bazel 会构建并遍历以执行构建的依赖关系图。包括目标配置的目标操作工件等节点。当一组目标目标文件所依赖的所有工件都被验证为最新时,构建会被视为完成。

编译设置

Starlark 定义的一段配置Transitions 可以通过设置构建设置来更改子图的配置。如果作为命令行标志向用户公开,也称为构建标志。

干净构建

不使用早期构建结果的构建。这通常比增量构建慢,但通常被认为更正确。Bazel 可以确保干净构建和增量构建始终正确无误。

客户端-服务器模型

bazel 命令行客户端会自动在本地机器上启动后台服务器,以执行 Bazel 命令。服务器会在所有命令之间持续运行,但在一段时间不活动(或明确通过 Bazel 关停)后会自动停止。将 Bazel 拆分为服务器和客户端有助于分析 JVM 启动时间并支持更快速地进行增量构建,因为操作图会跨命令保留在内存中。

命令

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

命令标志

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

配置

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

另请参阅配置

配置调整

仅包含目标实际需要的配置部分的过程。例如,如果您构建 Java 二进制文件//:j支持 C++//:c ,那么添加--javacopt//:c因为会发生变化--javacopt不必要地破坏 C++ 构建可缓存性。

配置的查询 (cquery)

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

另请参阅cquery 文档

配置的目标

使用配置评估目标的结果。分析阶段通过将构建的选项与需要构建的目标相结合来实现这一点。例如,如果 //:foo 在同一个 build 中为两个不同的架构构建,则有两个配置的目标:<//:foo, x86><//:foo, arm>

正确性

如果 build 的输出如实反映其传递输入的状态,则表示 build 正确无误。为实现正确的构建,Bazel 会努力保持封闭、可重现,并且进行构建分析操作执行具有确定性。

依赖项

两个目标之间的有向边缘。如果目标 //:foo 的属性值包含对 //:bar 的引用,则目标 //:foo 具有目标 //:bar目标依赖项//:foo包含操作依赖项//:bar如果//:foo取决于输入工件由以下用户的操作创建//:bar中披露政府所要求信息的数量和类型。

除 De

用于收集传递依赖项数据的数据结构。经过优化,合并合并的设备非常耗时,且空间效率高,因为通常具有非常大的预设(数十万个文件)。为了空间效率的原因,以递归方式引用其他预设。除非规则位于构建图的顶层,否则规则实现不应通过将其转换为列表来“展平”偏移。平化大量预设值会导致巨大的内存消耗。在 Bazel 的内部实现中也称为嵌套集

另请参阅Depset 文档

磁盘缓存

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

迪斯蒂尔

一个只读目录,其中包含 Bazel 否则使用代码库规则从互联网中提取的文件。使构建完全离线运行。

动态执行

一种执行策略,基于各种启发法选择本地执行和远程执行,并使用更快成功方法的执行结果。某些操作在本地执行(例如,执行链接时)速度更快,另一些则在远程执行(例如,高度并行化编译)更快。动态执行策略可以提供最佳的增量和干净构建时间。

执行阶段

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

执行根

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

文件

请参阅工件

封闭

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

增量构建

增量构建会重用早期构建的结果,以缩短构建时间和资源用量。依赖项检查和缓存旨在为此类构建生成正确的结果。增量构建与干净构建相反。

标签

目标的标识符。完全限定的标签(如 //path/to/package:target)由 // 组成,用于将工作区根目录 path/to/package 标记为包含 BUILD file(用于声明目标)和 :target(作为上述 BUILD 文件中声明的目标的名称)。也可以添加 @my_repository//<..> 前缀,以表明该目标是在名为 my_repository 的 [外部代码库] 中声明的。

加载阶段

构建的第一个阶段,其中 Bazel 会解析 WORKSPACEBUILD.bzl 文件以创建软件包glob() 等特定函数在此阶段进行评估。与构建的第二阶段(分析阶段)交错,以构建目标图

在单个 Starlark 函数下编写多个 rule 目标声明的机制。允许在 BUILD 文件中重复使用通用规则声明模式。在加载阶段,扩展为基础规则目标声明。

另请参阅宏文档

助记符

规则作者选择的简短易懂的字符串,用于快速了解规则中的操作。 助记符可用作生成策略选择的标识符。一些助记符示例包括:来自 Java 规则的 Javac、来自 C++ 规则的 CppCompile,以及来自 Android 规则的 AndroidManifestMerger

原生规则

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

输出基准

特定于工作区的目录,用于存储 Bazel 输出文件。用于将输出与工作区的源代码树分开。位于输出用户根目录中。

输出组

预计在 Bazel 完成目标构建时构建的一组文件。规则将其常规输出放入“默认输出组”(如.jarCANNOT TRANSLATEjava_library.a.so针对以下金额收取cc_library目标)。默认输出组是在命令行中请求目标时构建工件的输出组。规则可以定义更多已命名的输出组,这些组可以在 BUILD 文件filegroup 规则)或命令行(--output_groups 标志)中明确指定。

输出用户根

存储 Bazel 输出的用户专属目录。该目录名称衍生自用户的系统用户名。如果多个用户同时在系统上构建相同的项目,则防止输出文件发生冲突。 包含与各个工作区的构建输出相对应的子目录(也称为输出输出)。

软件包

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

软件包组

表示一组软件包的目标。通常用于可见性属性值。

平台

构建涉及的“机器类型”。这包括运行 Bazel 的机器(“主机”平台)、在“执行”平台上运行的机器构建工具,以及针对这些目标构建的机器目标(“目标平台”)。

提供商

从规则目标传递到其他规则目标的一组信息。通常包含如下信息:编译器选项、传递源文件、传递输出文件和 build 元数据。经常与 depsets 结合使用。

另请参阅提供商文档

查询(概念)

分析构建图以理解目标属性和依赖项结构的过程。Bazel 支持三种查询变体:querycqueryaquery

query(命令)

查询工具,用于对构建的加载后阶段 目标图执行操作。此操作相对较快,但无法分析select()构建标记工件,或构建操作中披露政府所要求信息的数量和类型。

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

代码库缓存

由 Bazel 下载用于构建的文件的可共享内容可寻址缓存,该缓存可在工作区之间共享。在初始下载后启用离线构建。通常用于缓存通过代码库规则(如 http_archive)和代码库规则 API(如 repository_ctx.download)下载的文件。只有为下载指定了 SHA-256 校验和时,系统才会缓存文件。

可再现性

构建或测试的属性,一组构建或测试的输入将始终生成同一组输出,无论时间、方法或环境如何。请注意,这并不一定意味着输出正确无误,或者所需的输出。

规则

一种函数实现,可注册要在输入工件上执行的一系列操作,以生成一组输出工件。规则可以从“特性”中读取值作为输入(例如,依赖项,仅测试,名称)。规则目标还会以提供程序(例如 DefaultInfo 提供程序)的形式生成和传递可能对其他规则目标有用的信息。

另请参阅规则文档

Runfile

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

另请参阅Runfiles 文档

沙盒

一种在受限的临时执行根内隔离正在运行的操作的技术,可帮助确保它不会读取未声明的输入或写入未声明的输出中披露政府所要求信息的数量和类型。沙盒功能极大地增强了封闭性,但这种性能通常会影响性能,并且需要操作系统的支持。性能费用取决于平台。 在 Linux 上,这一点并不重要,但在 macOS 上,就会导致沙盒无法使用。

天空框架

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

冲压

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

施塔尔克

用于编写规则的扩展程序语言。一个有限的 Python(语法和语法)子集,旨在用于配置和提高性能。使用 .bzl 文件扩展名。BUILD 文件使用更严格的 Starlark 版本(例如,无 def 函数定义),以前称为 Skylark。

另请参阅Starlark 语言文档

启动标志

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

目标

可构建的单元。可以是规则目标、文件目标或软件包组。规则目标根据 BUILD 文件中的规则声明进行实例化。根据规则的实现情况,规则目标也可以是可测试或可运行的。BUILD 文件中使用的每个文件都是文件目标。目标可以通过特性依赖于其他目标(最常见的情况,不一定是 deps)。 配置的目标是一对目标和构建配置

目标图

目标及其依赖项的内存中图表。在加载阶段生成,并用作分析阶段的输入。

目标模式

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

测试

规则目标基于测试规则进行实例化,因此包含测试可执行文件。可执行文件完成时返回 0 表示测试成功。Bazel 与测试之间的具体合约(例如测试环境变量、测试结果收集方法)在 Test Encyclopedia 中指定。

工具链

用于为语言构建输出的一组工具。通常,工具链包含编译器、链接器、解释器或/和 linter。工具链也可能因平台而异,也就是说,Unix 编译器工具链的组件可能会因 Windows 变体而异,即使工具链采用同一语言也是如此。为平台选择正确的工具链称为工具链解析。

顶级目标

如果在 Bazel 命令行中请求构建目标,则目标是顶级。例如,如果 //:foo 依赖于 //:bar,并且调用了 bazel build //:foo,则对于此构建,//:foo 是顶级,而 //:bar 不是{101 顶级,但这两个目标都需要构建。顶级目标和非顶级目标之间的一个重要区别是:命令标志在 Bazel 命令行中设置(或通过.yamlrc )设置了配置对于顶级目标,但可能会由过渡

转换

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

另请参阅用户定义的转换

树形工件

请参阅工件

可见状态

定义其他目标能否依赖于某个目标。 默认情况下,目标公开范围是不公开的。也就是说,目标只能依赖于同一软件包中的其他目标。可以对特定软件包公开,也可以完全公开。

另请参阅公开范围文档

工作区

一个目录,其中包含 WORKSPACE 文件以及要构建的软件的源代码。以 // 开头的标签是相对于工作区目录的。

WORKSPACE 文件

将目录定义为工作区。 该文件可以为空,但通常包含外部代码库声明,以便从网络或本地文件系统中提取其他依赖项。