本部分定义了许多函数或 build 规则通用的各种术语和概念。
目录
- Bourne shell 词元化
- 标签扩展
- 大多数 build 规则定义的典型属性
- 所有 build 规则通用的属性
- 所有测试规则 (*_test) 共有的属性
- 所有二进制规则 (*_binary) 共有的属性
- 可配置的属性
- 隐式输出目标
Bourne shell 词元化
某些规则的特定字符串属性会根据 Bourne shell 的分词规则拆分为多个字词:未加引号的空格用于分隔不同的字词,而单引号、双引号和反斜杠字符用于防止分词。
本文档中明确指出哪些属性需要进行这种标记化处理。
受“Make”变量扩展和 Bourne shell 令牌化影响的属性通常用于将任意选项传递给编译器和其他工具。此类属性的示例包括 cc_library.copts
和 java_library.javacopts
。
通过这些替换,单个字符串变量可以扩展为特定于配置的选项字词列表。
标签扩展
极少数规则的某些字符串属性会进行标签扩展:如果这些字符串包含有效的标签作为子字符串(例如 //mypkg:target
),并且该标签是当前规则的已声明前提条件,则会扩展为 目标
//mypkg:target
所表示文件的路径名。
属性示例包括 genrule.cmd
和 cc_binary.linkopts
。在每种情况下,详细信息可能会有很大差异,例如:是否展开相对标签;如何处理展开为多个文件的标签等。有关具体信息,请参阅规则属性文档。
大多数 build 规则定义的典型属性
本部分介绍了许多构建规则(但并非所有规则)定义的属性。
属性 | 说明 |
---|---|
data |
标签列表;默认值为 此规则在运行时所需的文件。可能会列出文件或规则目标。通常允许任何目标。
如果新规则处理的输入可能会在运行时使用其他输入,则应定义 |
deps |
标签列表;默认值为
相应目标的依赖项。通常应仅列出规则目标。(不过,有些规则允许直接在 特定于语言的规则通常会将列出的目标限制为具有特定提供商的目标。
目标依赖于使用
通常, |
licenses |
字符串列表;不可配置;默认值为 要用于此特定目标的许可类型字符串列表。 这是 Bazel 不再使用的已弃用的许可 API 的一部分。请勿使用此功能。 |
srcs |
标签列表;默认值为
此规则处理或包含的文件。通常直接列出文件,但也可以列出规则目标(例如 特定于语言的规则通常要求所列文件具有特定的文件扩展名。 |
所有 build 规则通用的属性
本部分介绍隐式添加到所有 build 规则的属性。
属性 | 说明 |
---|---|
aspect_hints |
标签列表;默认值为 一个任意标签列表,该列表会公开给 aspect(尤其是由此规则的反向依赖项调用的 aspect),但不会公开给此规则自身的实现。如需详细了解特定方面提示会产生什么效果,请参阅特定于语言的规则集的相关文档。 您可以将方面提示视为比标记更丰富的替代方案:标记仅传达布尔值状态(标记在 在实践中,宽高比提示用于实现不同语言特定规则集之间的互操作性。例如,假设您有一个 如需查看具体示例,请参阅 最佳做法:
|
compatible_with |
此目标可构建的环境列表,除了默认支持的环境之外。 这是 Bazel 约束系统的一部分,可让用户声明哪些目标可以相互依赖,哪些目标不能相互依赖。例如,外部可部署的二进制文件不应依赖于包含公司机密代码的库。如需了解详情,请参阅 ConstraintSemantics。 |
deprecation |
字符串;不可配置;默认值为 与此目标相关联的说明性警告消息。 通常,此属性用于通知用户目标已过时、已被其他规则取代、是软件包私有的,或者可能因某种原因而被视为有害。最好添加一些参考信息(例如网页、bug 编号或迁移 CL 示例),以便用户轻松了解需要进行哪些更改才能避免显示该消息。如果有一个新的目标可以作为替代目标,那么最好将旧目标的所有用户都迁移到新目标。
此属性对构建方式没有影响,但可能会影响构建工具的诊断输出。当其他软件包中的目标依赖于具有 软件包内部依赖项不受此警告的限制,因此,例如,构建已弃用规则的测试不会遇到警告。 如果某个已弃用的目标依赖于另一个已弃用的目标,则不会发出警告消息。 当用户不再使用该目标时,可以将其移除。 |
exec_compatible_with |
此目标的默认执行组的执行平台中必须存在的 |
exec_group_compatible_with |
字符串到标签列表的字典;不可配置;默认值为
一个字典,其中包含执行组名称到必须在给定执行组的执行平台中存在的 |
exec_properties |
字符串字典;默认值为 一个字符串字典,将添加到为此目标选择的平台的 如果某个键同时出现在平台级和目标级属性中,则系统会从目标级属性中获取相应的值。 键可以添加执行组名称作为前缀,后跟 |
features |
功能字符串列表;默认值为 功能是可在目标上启用或停用的字符串标记。功能的含义取决于规则本身。 此 |
package_metadata |
标签列表;不可配置;默认值为软件包的 与此目标相关联的标签列表,其中包含相关元数据。 通常,标签是返回常量值提供程序的简单规则。规则和方面可以使用这些标签对 build 图执行一些额外的分析。
规范用例是 rules_license。对于该用例, |
restricted_to |
相应目标可构建的环境列表,而非默认支持的环境。
这是 Bazel 限制系统的一部分。如需了解详情,请参阅 |
tags |
字符串列表;不可配置;默认值为
标记可用于任何规则。测试和
如果 Bazel 在任何测试或
测试中的标记通常用于注释测试在调试和发布过程中的角色。通常,标记最适合用于缺少任何运行时注释功能的 C++ 和 Python 测试。通过使用标记和大小元素,可以根据代码库提交政策灵活地组装测试套件。
如果 Bazel 在测试规则的
|
target_compatible_with |
标签列表;默认值为
必须存在于目标平台中的 以传递方式依赖于不兼容目标的目标本身也被视为不兼容。在构建和测试时,这些文件也会被跳过。 空列表(默认值)表示目标与所有平台兼容。
除 Workspace 规则之外的所有规则都支持此属性。
对于某些规则,此属性不会产生任何影响。例如,为
如需详细了解如何跳过不兼容的目标平台,请参阅平台页面。 |
testonly |
布尔值;不可配置;默认值为
如果为
同样,非
测试( 此属性旨在表示,目标不应包含在发布到生产环境的二进制文件中。 由于 testonly 是在 build 时(而非运行时)强制执行的,并且会通过依赖树以病毒式方式传播,因此应谨慎应用。例如,对单元测试有用的桩和伪对象可能对涉及将发布到生产环境的相同二进制文件的集成测试也有用,因此可能不应标记为 testonly。相反,即使链接到也危险的规则(可能是因为它们无条件地替换了正常行为)应明确标记为 testonly。 |
toolchains |
一组目标,允许此目标访问这些目标的 Make 变量。这些目标可以是提供
请注意,这与规则实现用于平台相关配置的工具链解析概念不同。您无法使用此属性来确定目标将使用哪个特定的 |
visibility |
对于直接在 BUILD 文件中声明的目标或从 BUILD 文件调用的旧版宏,默认值为软件包的 |
所有测试规则(*_test)通用的属性
本部分介绍了所有测试规则通用的属性。
属性 | 说明 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
args |
字符串列表;受 $(location) 和“Make variable” 替换以及 Bourne shell 令牌化的影响;默认值为 当使用
这些实参在 |
||||||||||||||||||||
env |
字符串字典;值受 $(location) 和 “Make variable” 替换的影响;默认值为
指定在
此属性仅适用于原生规则,例如 |
||||||||||||||||||||
env_inherit |
字符串列表;默认值为 指定在通过
此属性仅适用于原生规则,例如 |
||||||||||||||||||||
size |
字符串 指定测试目标的“轻重程度”:运行测试需要多少时间/资源。 单元测试被视为“小型”测试,集成测试被视为“中型”测试,端到端测试被视为“大型”或“巨型”测试。Bazel 会使用该大小来确定默认超时时间,您可以使用 测试规模对应于以下默认超时时间和假设的本地资源使用峰值:
在生成测试时,环境变量 |
||||||||||||||||||||
timeout |
字符串 测试预计运行多长时间后返回。
虽然测试的大小属性控制着资源估计,但测试的超时时间可以单独设置。如果未明确指定,则超时时间取决于测试的大小。可以使用
对于上述时间以外的时间,可以使用
在生成测试时,环境变量 |
||||||||||||||||||||
flaky |
布尔值;不可配置;默认值为 将测试标记为 flaky。 如果设置了此标志,则执行测试最多三次,只有在每次都失败时才将其标记为失败。默认情况下,此属性设置为 False,并且测试仅执行一次。请注意,一般不建议使用此属性 - 当断言成立时,测试应可靠地通过。 |
||||||||||||||||||||
shard_count |
小于或等于 50 的非负整数;默认值为 指定用于运行测试的并行分片数量。 如果设置,此值将替换用于确定运行测试的并行分片数量的所有启发式方法。请注意,对于某些测试规则,可能需要此参数才能启用分片。另请参阅 如果启用了测试分片,则在生成测试时,环境变量 分片要求测试运行程序支持测试分片协议。如果未指定,则很可能会在每个分片中运行每个测试,而这并不是您想要的结果。 如需详细了解分片,请参阅测试百科全书中的测试分片。 |
||||||||||||||||||||
local |
布尔值;不可配置;默认值为 强制在本地运行测试,而不进行沙盒处理。 将此属性设置为 True 等同于提供“local”作为标记 ( |
所有二元规则(*_binary)通用的属性
本部分介绍了所有二进制规则通用的属性。
属性 | 说明 |
---|---|
args |
字符串列表;受 $(location) 和“Make variable”替换以及 Bourne shell 令牌化的影响;不可配置;默认值为
当目标通过
注意:在 Bazel 之外运行目标时(例如,通过在 |
env |
字符串字典;值受 $(location) 和“创建变量”替换的影响;默认值为 指定由
此属性仅适用于原生规则,例如
注意:在 Bazel 之外运行目标时(例如,通过手动执行 |
output_licenses |
字符串列表;默认值为 相应二进制文件生成的输出文件的许可。 这是 Bazel 不再使用的已弃用的许可 API 的一部分。请勿使用此功能。 |
可配置的属性
大多数属性都是“可配置”的,这意味着当以不同方式构建目标时,它们的值可能会发生变化。具体而言,可配置的属性可能会因传递给 Bazel 命令行标志的不同而异,也可能会因下游依赖项请求的目标不同而异。例如,这可用于自定义多个平台或编译模式的目标。
以下示例针对不同的目标架构声明了不同的来源。运行 bazel build :multiplatform_lib --cpu x86
将使用 x86_impl.cc
构建目标,而替换为 --cpu arm
将导致它改用 arm_impl.cc
。
cc_library( name = "multiplatform_lib", srcs = select({ ":x86_mode": ["x86_impl.cc"], ":arm_mode": ["arm_impl.cc"] }) ) config_setting( name = "x86_mode", values = { "cpu": "x86" } ) config_setting( name = "arm_mode", values = { "cpu": "arm" } )
select()
函数会根据目标配置满足的 config_setting
或 constraint_value
条件,从可配置属性的不同替代值中进行选择。
Bazel 会在处理宏之后、处理规则之前(从技术上讲,是在
加载阶段和分析阶段之间)评估可配置的属性。在评估 select()
之前进行的任何处理都不知道 select()
会选择哪个分支。例如,宏无法根据所选分支更改其行为,而 bazel query
只能对目标的可配置依赖项做出保守的猜测。如需详细了解如何将 select()
与规则和宏搭配使用,请参阅
此常见问题解答。
文档中标记为 nonconfigurable
的属性无法使用此功能。通常,属性是不可配置的,因为 Bazel 需要在内部知道其值,然后才能确定如何解析 select()
。
如需详细了解,请参阅 可配置的 build 属性。
隐式输出目标
C++ 中的隐式输出已被弃用。请尽可能避免在其他语言中使用该功能。我们尚未确定弃用路径,但它们最终也会被弃用。
在 BUILD 文件中定义 build 规则时,您是在软件包中明确声明一个新的命名规则目标。许多 build 规则函数还隐式包含一个或多个输出文件目标,这些目标的具体内容和含义取决于规则。
例如,当您明确声明 java_binary(name='foo', ...)
规则时,您还隐式声明输出文件目标 foo_deploy.jar
是同一软件包的成员。
(此特定目标是适合部署的自包含 Java 归档。)
隐式输出目标是全局目标图的一级成员。与其他目标一样,它们也是按需构建的,要么是在顶级 build 命令中指定时构建,要么是在它们是其他 build 目标的必要前提条件时构建。它们可在 BUILD 文件中作为依赖项引用,并可在 bazel query
等分析工具的输出中观察到。
对于每种 build 规则,相应规则的文档都包含一个特殊部分,详细说明了声明该类规则所带来的任何隐式输出的名称和内容。
构建系统使用的两个命名空间之间存在一个重要但略微细微的区别:标签用于标识目标(可以是规则或文件),而文件目标可以分为源(或输入)文件目标和派生(或输出)文件目标。这些是您可以在 BUILD 文件中提及、从命令行构建或使用 bazel query
进行检查的内容;这是目标命名空间。每个文件目标都对应于磁盘上的一个实际文件(“文件系统命名空间”);每个规则目标可能对应于磁盘上的零个、一个或多个实际文件。
磁盘上可能存在没有相应目标的文件;例如,在 C++ 编译期间生成的 .o
对象文件无法从 BUILD 文件内或命令行中引用。这样一来,构建工具可能会隐藏其工作方式的某些实现细节。如需了解详情,请参阅 BUILD 概念参考。