规则

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。
报告问题 查看源代码

规则定义了一系列 actions,Bazel 会对输入执行以生成一组输出,这些输出在规则的 实现函数返回的 providers 中引用。例如,C++ 二进制文件规则可能会:

  1. 接受一组 .cpp 源文件(输入)。
  2. 对源文件(操作)运行 g++
  3. 返回包含可执行输出和其他文件的 DefaultInfo 提供程序,使其在运行时可用。
  4. 返回 CcInfo 提供程序,其中包含从目标及其依赖项收集的特定于 C++ 的信息。

从 Bazel 的角度来看,g++ 和标准 C++ 库也是此规则的输入。作为规则编写器,您不仅必须考虑用户提供的规则输入,还必须考虑执行操作所需的所有工具和库。

在创建或修改任何规则之前,请确保您熟悉 Bazel 的构建阶段。了解构建(加载、分析和执行)的三个阶段非常重要。了解也有助于您了解规则和宏之间的区别。要开始使用,请先查看规则教程。然后,参考此页面。

Bazel 本身内置了一些规则。这些原生规则(例如 cc_libraryjava_binary)为某些语言提供了一些核心支持。通过定义自己的规则,您可以为 Bazel 原生不支持的语言和工具添加类似的支持。

Bazel 提供了一个使用 Starlark 语言编写规则的可扩展模型。这些规则写入 .bzl 文件,可以直接从 BUILD 文件加载。

在定义自己的规则时,您可以决定其支持的属性及其生成输出的方式。

规则的 implementation 函数定义其在分析阶段的确切行为。此函数不会运行任何外部命令。而是会注册将在执行阶段后续需要用于构建规则输出的操作

创建规则

.bzl 文件中,使用 rule 函数定义新规则,并将结果存储在全局变量中。调用 rule 会指定属性实现函数

example_library = rule(
    implementation = _example_library_impl,
    attrs = {
        "deps": attr.label_list(),
        ...
    },
)

这定义了一个名为 example_library规则种类

rule 的调用还必须指定规则是创建可执行文件输出(使用 executable=True),还是明确指定测试可执行文件(使用 test=True)。对于后者,规则是测试规则,并且规则的名称必须以 _test 结尾。

目标实例化

可以在 BUILD 文件中加载和调用规则:

load('//some/pkg:rules.bzl', 'example_library')

example_library(
    name = "example_target",
    deps = [":another_target"],
    ...
)

对构建规则的每次调用都不会返回任何值,但副作用是定义目标。这称为“实例化”规则。这会指定新目标的名称以及目标属性的值。

还可以从 Starlark 函数调用规则并将其加载到 .bzl 文件中。调用规则的 Starlark 函数称为 Starlark 宏。最终必须从 BUILD 文件中调用 Starlark 宏,并且只能在加载阶段(在计算 BUILD 文件以实例化目标时调用)期间调用。

特性

特性是一种规则参数。特性可以为目标的实现提供特定值,也可以引用其他目标,从而创建依赖关系图。

如需定义规则专用属性(例如 srcsdeps),请将映射从属性名称传递给架构(使用 attr 模块创建)到 ruleattrs 参数。常见特性(如 namevisibility)会隐式添加到所有规则中。其他属性会隐式添加到可执行和测试规则中。隐式添加到规则的属性无法包含在传递给 attrs 的字典中。

依赖项属性

处理源代码的规则通常定义以下属性来处理各种类型的依赖项

  • srcs 用于指定由目标的操作处理的源文件。通常,特性架构会指定规则要处理的源文件类型。对于包含头文件的文件语言,规则通常会为由目标及其使用方处理的标头指定单独的 hdrs 属性。
  • deps 指定目标的代码依赖项。特性架构应指定这些依赖项必须提供哪些提供程序。(例如,cc_library 提供 CcInfo。)
  • data 用于指定要在运行时提供给任何依赖于目标的可执行文件。这应该允许指定任意文件。
example_library = rule(
    implementation = _example_library_impl,
    attrs = {
        "srcs": attr.label_list(allow_files = [".example"]),
        "hdrs": attr.label_list(allow_files = [".header"]),
        "deps": attr.label_list(providers = [ExampleInfo]),
        "data": attr.label_list(allow_files = True),
        ...
    },
)

以下是依赖项属性示例。任何指定输入标签(使用 attr.label_listattr.labelattr.label_keyed_string_dict 定义)的属性都会指定目标与在定义目标时,其属性(即相应的 Label 对象)中列出的目标之间的特定类型的依赖项。系统会根据定义的目标解析这些标签的代码库(可能还包含路径)。

example_library(
    name = "my_target",
    deps = [":other_target"],
)

example_library(
    name = "other_target",
    ...
)

在此示例中,other_targetmy_target 的依赖项,因此首先分析 other_target。如果目标的依赖关系图中存在循环,则会发生错误。

私有属性和隐式依赖项

具有默认值的依赖项属性会创建隐式依赖项。该属性是隐式的,因为它是目标图的一部分,用户未在 BUILD 文件中指定。隐式依赖项有助于对规则和工具(构建时依赖项,例如编译器)之间的关系进行硬编码,因为在大多数情况下,用户并不需要指定规则使用的工具。在规则的实现函数内,系统会将其视为与其他依赖项一样。

如果您想提供隐式依赖项而不允许用户替换该值,可以将属性设为一个以下划线 (_) 开头的名称,使其成为私有属性。专用属性必须具有默认值。通常,仅对隐式依赖项使用私有属性是有意义的。

example_library = rule(
    implementation = _example_library_impl,
    attrs = {
        ...
        "_compiler": attr.label(
            default = Label("//tools:example_compiler"),
            allow_single_file = True,
            executable = True,
            cfg = "exec",
        ),
    },
)

在此示例中,每个类型为 example_library 的目标都有对编译器 //tools:example_compiler 的隐式依赖项。这允许 example_library 的实现函数生成调用编译器的操作,即使用户未将其标签作为输入传递也是如此。由于 _compiler 是私有属性,因此在此规则类型的所有目标中,ctx.attr._compiler 将始终指向 //tools:example_compiler。或者,您可以将特性命名为 compiler,不带下划线并保留默认值。这可让用户在必要时替换其他编译器,但不需要知道编译器的标签。

隐式依赖项通常用于与规则实现位于同一代码库中的工具。如果该工具来自执行平台或其他代码库,则规则应通过工具链获取该工具。

输出属性

输出属性(例如 attr.outputattr.output_list)用于声明目标生成的输出文件。它们与依赖项属性有以下两个不同:

  • 它们定义输出文件目标,而不是引用在其他位置定义的目标。
  • 输出文件目标依赖于实例化的规则目标,而不是相反。

通常,仅在规则需要用用户定义的名称(无法基于目标名称)创建输出时使用输出属性。如果规则有一个输出属性,它通常命名为 outouts

输出特性是创建预声明输出的首选方式,可以明确依赖于输出或在命令行中请求

实现函数

每条规则都需要一个 implementation 函数。这些函数会在分析阶段严格执行,并将加载阶段生成的目标图转换为要在执行阶段执行的操作图表。因此,实现函数实际上无法读取或写入文件。

规则实现函数通常是不公开的(以前导下划线命名)。通常,它们的命名方式与其规则相同,但后缀为 _impl

实现函数只接受一个参数:一个规则上下文,通常命名为 ctx。它们会返回 providers 列表。

目标

依赖项在分析时表示为 Target 对象。这些对象包含执行目标的实现函数时生成的 providers

ctx.attr 包含与每个依赖项属性的名称相对应的字段,其中包含表示通过该属性的每个直接依赖项的 Target 对象。对于 label_list 属性,这是 Targets 列表。对于 label 属性,这是单个 TargetNone

目标的实现函数会返回提供程序对象的列表:

return [ExampleInfo(headers = depset(...))]

可以使用索引表示法 ([]) 访问这些类型,并将提供程序的类型作为键。它们可以是 Starlark 中定义的自定义提供程序,或者可作为 Starlark 全局变量使用的原生提供程序的提供程序

例如,如果规则通过 hdrs 属性获取头文件并将其提供给目标及其消费者的编译操作,则可以按如下方式收集这些文件:

def _example_library_impl(ctx):
    ...
    transitive_headers = [hdr[ExampleInfo].headers for hdr in ctx.attr.hdrs]

对于从目标的实现函数返回 struct(而非提供程序对象列表)的旧样式,请执行以下操作:

return struct(example_info = struct(headers = depset(...)))

可以从 Target 对象的相应字段检索提供程序:

transitive_headers = [hdr.example_info.headers for hdr in ctx.attr.hdrs]

强烈建议不要使用此样式,应停止使用它

文件

文件由 File 对象表示。由于 Bazel 不会在分析阶段执行文件 I/O,因此无法使用这些对象直接读取或写入文件内容。而是被传递给操作发出函数(请参阅 ctx.actions)来构建操作图的各个部分。

File 可以是源文件或生成的文件。每个生成的文件都必须是一项操作的输出。源文件不能作为任何操作的输出。

对于每个依赖项属性,ctx.files 的相应字段包含通过该属性的所有依赖项的默认输出列表:

def _example_library_impl(ctx):
    ...
    headers = depset(ctx.files.hdrs, transitive=transitive_headers)
    srcs = ctx.files.srcs
    ...

ctx.file 包含规范设置为 allow_single_file=True 的依赖项属性的单个 FileNonectx.executable 的行为与 ctx.file 相同,但仅包含其规范设置为 executable=True 的依赖项属性的字段。

声明输出

在分析阶段,规则的实现函数可以创建输出。由于所有标签在加载阶段都必须是已知的,因此这些额外的输出没有标签。您可以使用 ctx.actions.declare_filectx.actions.declare_directory 为输出创建 File 对象。通常,输出的名称基于目标的名称 ctx.label.name

def _example_library_impl(ctx):
  ...
  output_file = ctx.actions.declare_file(ctx.label.name + ".output")
  ...

对于预声明的输出,例如为输出属性创建的输出,可以从 ctx.outputs 的相应字段中检索 File 对象。

操作

操作描述了如何根据一组输入生成一组输出,例如“在 hello.c 上运行 gcc 并获取 hello.o”。创建操作后,Bazel 不会立即运行该命令。它会在依赖项图表中注册它,因为一项操作可能依赖于另一项操作的输出。例如,在 C 中,必须在编译器之后调用链接器。

用于创建操作的通用函数在 ctx.actions 中定义:

ctx.actions.args 可用于高效地累积操作参数。它会在执行之前避免扁平化偏移:

def _example_library_impl(ctx):
    ...

    transitive_headers = [dep[ExampleInfo].headers for dep in ctx.attr.deps]
    headers = depset(ctx.files.hdrs, transitive=transitive_headers)
    srcs = ctx.files.srcs
    inputs = depset(srcs, transitive=[headers])
    output_file = ctx.actions.declare_file(ctx.label.name + ".output")

    args = ctx.actions.args()
    args.add_joined("-h", headers, join_with=",")
    args.add_joined("-s", srcs, join_with=",")
    args.add("-o", output_file)

    ctx.actions.run(
        mnemonic = "ExampleCompile",
        executable = ctx.executable._compiler,
        arguments = [args],
        inputs = inputs,
        outputs = [output_file],
    )
    ...

操作接受输入文件列表或分隔符,并生成(非空)输出文件列表。在分析阶段,输入集和输出文件集必须是已知的。它可能依赖于属性的值(包括依赖项中的提供程序),但不能依赖于执行的结果。例如,如果您的操作运行了解压缩命令,则必须先指定希望膨胀哪些文件(在运行解压缩之前)。在内部创建可变数量的文件的操作可以将这些文件封装在单个文件中(例如 zip、tar 或其他归档文件格式)。

操作必须列出其所有输入。列出未使用的输入是可以接受的,但效率并不高。

操作必须创建其所有输出。它们可能会写入其他文件,但输出中的任何内容都不会可供使用方使用。所有声明的输出都必须通过某种操作来写入。

操作与纯函数类似:它们应仅依赖于提供的输入,并避免访问计算机信息、用户名、时钟、网络或 I/O 设备(读取输入和写入输出除外)。这非常重要,因为系统会缓存并重复使用输出。

依赖项由 Bazel 解析,Bazel 会决定执行哪些操作。如果依赖关系图中存在循环,则会发生错误。创建操作并不能保证它会执行,具体取决于构建是否需要输出。

提供程序

提供程序是规则向依赖于它的其他规则公开的信息片段。这些数据可包含输出文件、库、要在工具的命令行中传递的参数,或目标使用方应了解的其他任何信息。

由于规则的实现函数只能从实例化的目标的即时依赖项中读取提供程序,因此规则需要转发目标依赖项中需要由目标使用方知晓的任何信息,通常是将其累积到 depset 中。

目标的提供程序由实现函数返回的 Provider 对象列表指定。

旧版实现也可以用旧版样式编写,其中实现函数会返回 struct,而不是提供程序对象列表。强烈建议不要使用此样式,应停止使用它

默认输出

目标的默认输出是指在命令行中请求构建目标时默认请求的输出。例如,java_library 目标 //pkg:foofoo.jar 作为默认输出,因此将通过 bazel build //pkg:foo 命令进行构建。

默认输出由 DefaultInfofiles 参数指定:

def _example_library_impl(ctx):
    ...
    return [
        DefaultInfo(files = depset([output_file]), ...),
        ...
    ]

如果规则实现未返回 DefaultInfo 或未指定 files 参数,DefaultInfo.files 会默认为所有预声明的输出(通常是指输出属性创建的输出)。

用于执行操作的规则应提供默认输出,即使预计不会直接使用这些输出。系统会剪除请求输出图表以外的操作。如果输出仅供目标的使用方使用,则在单独构建目标时,系统将不会执行这些操作。这会加大调试难度,因为只重新构建失败的目标不会重现失败情况。

Runfile

Runfile 是目标在运行时使用的一组文件(而不是构建时)。在执行阶段,Bazel 会创建一个目录树,其中包含指向运行文件的符号链接。这会为二进制文件暂存环境,以便它可以在运行时访问 Runfile。

您可以在创建规则期间手动添加 Runfile。runfiles 对象可以通过规则方法 ctx.runfiles 中的 runfiles 方法创建,并传递给 DefaultInfo 上的 runfiles 参数。可执行规则的可执行输出会隐式添加到运行文件中。

某些规则指定了属性(通常名为 data),其输出会添加到目标的运行文件中。Runfile 还应从 data 以及任何可能为最终执行提供代码的属性合并,通常是 srcs(它可能包含带关联 datafilegroup 目标)和 deps

def _example_library_impl(ctx):
    ...
    runfiles = ctx.runfiles(files = ctx.files.data)
    transitive_runfiles = []
    for runfiles_attr in (
        ctx.attr.srcs,
        ctx.attr.hdrs,
        ctx.attr.deps,
        ctx.attr.data,
    ):
        for target in runfiles_attr:
            transitive_runfiles.append(target[DefaultInfo].default_runfiles)
    runfiles = runfiles.merge_all(transitive_runfiles)
    return [
        DefaultInfo(..., runfiles = runfiles),
        ...
    ]

自定义提供程序

您可以使用 provider 函数定义提供程序,以传达特定于规则的信息:

ExampleInfo = provider(
    "Info needed to compile/link Example code.",
    fields={
        "headers": "depset of header Files from transitive dependencies.",
        "files_to_link": "depset of Files from compilation.",
    })

然后,规则实现函数可以构造并返回提供程序实例:

def _example_library_impl(ctx):
  ...
  return [
      ...
      ExampleInfo(
          headers = headers,
          files_to_link = depset(
              [output_file],
              transitive = [
                  dep[ExampleInfo].files_to_link for dep in ctx.attr.deps
              ],
          ),
      )
  ]
自定义提供程序初始化

可以使用自定义预处理和验证逻辑来保护提供程序的实例化。这可用于确保所有提供程序实例都遵循特定不变,或为用户提供更简洁的 API 来获取实例。

为此,将 init 回调传递给 provider 函数。如果给出了此回调,provider() 的返回值类型会变为以下两个值的元组:未使用 init 时普通的返回值的提供程序符号,以及“原始构造函数”。

在这种情况下,系统会调用提供程序符号,而不是直接返回新实例,而是将参数转发到 init 回调。回调的返回值必须是将字段名称(字符串)映射到值的字典;此字段用于初始化新实例的字段。请注意,回调可以包含任何签名,如果参数与签名不匹配,则系统会报告错误,就像直接调用回调一样。

相比之下,原始构造函数会绕过 init 回调。

以下示例使用 init 预处理并验证其参数:

# //pkg:exampleinfo.bzl

_core_headers = [...]  # private constant representing standard library files

# It's possible to define an init accepting positional arguments, but
# keyword-only arguments are preferred.
def _exampleinfo_init(*, files_to_link, headers = None, allow_empty_files_to_link = False):
    if not files_to_link and not allow_empty_files_to_link:
        fail("files_to_link may not be empty")
    all_headers = depset(_core_headers, transitive = headers)
    return {'files_to_link': files_to_link, 'headers': all_headers}

ExampleInfo, _new_exampleinfo = provider(
    ...
    init = _exampleinfo_init)

export ExampleInfo

然后,规则实现可能会将提供程序实例化,如下所示:

    ExampleInfo(
        files_to_link=my_files_to_link,  # may not be empty
        headers = my_headers,  # will automatically include the core headers
    )

原始构造函数可用于定义不经过 init 逻辑的备用公共工厂函数。例如,在 exampleinfo.bzl 中,我们可以定义:

def make_barebones_exampleinfo(headers):
    """Returns an ExampleInfo with no files_to_link and only the specified headers."""
    return _new_exampleinfo(files_to_link = depset(), headers = all_headers)

通常,原始构造函数会绑定到名称以下划线 (_new_exampleinfo) 开头的变量,这样用户代码就无法加载该变量,也无法生成任意提供程序实例。

init 的另一个用途是完全阻止用户调用提供程序符号,并强制用户改为使用工厂函数:

def _exampleinfo_init_banned(*args, **kwargs):
    fail("Do not call ExampleInfo(). Use make_exampleinfo() instead.")

ExampleInfo, _new_exampleinfo = provider(
    ...
    init = _exampleinfo_init_banned)

def make_exampleinfo(...):
    ...
    return _new_exampleinfo(...)

可执行规则和测试规则

可执行规则定义了可通过 bazel run 命令调用的目标。测试规则是一种特殊的可执行规则,其目标也可以通过 bazel test 命令调用。通过在调用 rule 时将相应的 executabletest 参数设置为 True 来创建可执行和测试规则:

example_binary = rule(
   implementation = _example_binary_impl,
   executable = True,
   ...
)

example_test = rule(
   implementation = _example_binary_impl,
   test = True,
   ...
)

测试规则的名称必须以 _test 结尾。(按照惯例,测试目标名称通常也以 _test 结尾,但这并不是必需的。)非测试规则不得使用此后缀。

这两种规则必须生成将由 runtest 命令调用的可执行输出文件(不一定会预先声明)。如需告知 Bazel 将哪个规则的输出用作此可执行文件,请将其作为返回的 DefaultInfo 提供程序的 executable 参数传递。系统会将 executable 添加到规则的默认输出中(因此,您无需将其同时传递给 executablefiles)。它还隐式添加到 runfiles

def _example_binary_impl(ctx):
    executable = ctx.actions.declare_file(ctx.label.name)
    ...
    return [
        DefaultInfo(executable = executable, ...),
        ...
    ]

生成此文件的操作必须设置该文件的可执行位。对于 ctx.actions.runctx.actions.run_shell 操作,此操作应由该操作调用的底层工具完成。对于 ctx.actions.write 操作,请传递 is_executable=True

作为旧版行为,可执行规则具有一个特殊的 ctx.outputs.executable 预声明输出。如果您未使用 DefaultInfo 指定可执行文件,则此文件将用作默认可执行文件;切勿以其他方式使用此文件。此输出机制已弃用,因为它不支持在分析时自定义可执行文件的名称。

请参阅可执行规则测试规则的示例。

可执行规则测试规则除了为所有规则添加的属性外,还隐式定义了其他属性。隐式添加的属性的默认值无法更改,具体方法是将专用规则封装在更改默认设置的 Starlark 宏中:

def example_test(size="small", **kwargs):
  _example_test(size=size, **kwargs)

_example_test = rule(
 ...
)

Runfiles 位置

当使用 bazel run(或 test)运行可执行文件目标时,runfiles 目录的根目录将与可执行文件相邻。相关路径如下:

# Given executable_file and runfile_file:
runfiles_root = executable_file.path + ".runfiles"
workspace_name = ctx.workspace_name
runfile_path = runfile_file.short_path
execution_root_relative_path = "%s/%s/%s" % (
    runfiles_root, workspace_name, runfile_path)

runfiles 目录下的 File 路径对应于 File.short_path

bazel 直接执行的二进制文件毗邻 runfiles 目录的根目录。不过,从 runfiles 调用的二进制文件无法做出相同的假设。为了缓解此问题,每个二进制文件都应提供一种方法,以使用环境或命令行参数/标志将其 runfiles 根作为参数接受。这样一来,二进制文件便可以将正确的规范运行文件根传递给其调用的二进制文件。如果未设置,则二进制文件会猜测它是第一个被调用的二进制文件,并查找相邻的 runfiles 目录。

高级主题

请求输出文件

一个目标可以有多个输出文件。运行 bazel build 命令时,分配给该命令的目标的某些输出被视为请求。Bazel 只会构建这些请求的文件及其直接或间接依赖的文件。(就操作图而言,Bazel 仅执行可作为所请求文件的传递依赖项访问的操作。)

除了默认输出之外,您还可以在命令行中明确请求任何预声明的输出。规则可以通过输出属性指定预声明的输出。在这种情况下,用户在实例化规则时就会明确选择输出的标签。如需获取输出属性的 File 对象,请使用 ctx.outputs 的相应属性。规则也可以根据目标名称隐式定义预声明的输出,但此功能已被弃用。

除了默认输出之外,还有输出组,即可以一起请求的输出文件的集合。您可以使用 --output_groups 请求这些权限。例如,如果目标 //pkg:mytarget 属于具有 debug_files 输出组的规则类型,则可以通过运行 bazel build //pkg:mytarget --output_groups=debug_files 构建这些文件。由于非预先声明的输出没有标签,因此只能通过显示在默认输出或输出组中进行请求。

可以使用 OutputGroupInfo 提供程序指定输出组。请注意,与许多内置提供程序不同,OutputGroupInfo 可以接受具有任意名称的参数来定义具有该名称的输出组:

def _example_library_impl(ctx):
    ...
    debug_file = ctx.actions.declare_file(name + ".pdb")
    ...
    return [
        DefaultInfo(files = depset([output_file]), ...),
        OutputGroupInfo(
            debug_files = depset([debug_file]),
            all_files = depset([output_file, debug_file]),
        ),
        ...
    ]

此外,与大多数提供程序不同,只要 OutputGroupInfo 没有应用相同的输出组,方面和应用该方面的规则目标都可以返回。在这种情况下,生成的提供程序将被合并。

请注意,OutputGroupInfo 通常不应用于从目标将特定类型的文件传递给其使用方的操作。应改为定义特定于规则的提供程序

配置

假设您要为不同的架构构建 C++ 二进制文件。build 可能很复杂,涉及多个步骤。某些中间二进制文件(如编译器和代码生成器)必须在执行平台(可能是您的主机或远程执行程序)上运行。某些二进制文件(如最终输出)必须为目标架构构建。

因此,Bazel 具有“配置”和过渡的概念。最顶层的目标(在命令行中请求的目标)构建在“目标”配置中,而应在执行平台上运行的工具则是在“执行”配置中构建的。规则可能会根据配置生成不同的操作,例如,更改传递给编译器的 CPU 架构。在某些情况下,不同的配置可能需要同一个库。如果发生这种情况,系统会对其进行分析,并且可能会构建多次。

默认情况下,Bazel 会在与目标本身相同的配置中构建目标的依赖项,即不使用过渡。当依赖项是帮助构建目标所需的工具时,相应的属性应指定向执行配置的转换。这会使该工具及其所有依赖项都针对执行平台进行构建。

对于每个依赖项属性,您都可以使用 cfg 来决定依赖项是否应在同一配置中构建或转换为执行配置。如果依赖项属性具有 executable=True 标志,则必须明确设置 cfg。这是为了防止意外为错误配置构建工具。查看示例

通常,运行时所需的源代码、相关库和可执行文件可以使用相同的配置。

应在构建期间执行的工具(例如编译器或代码生成器)应针对执行配置构建。在这种情况下,请在特性中指定 cfg="exec"

否则,应针对目标配置构建在运行时使用的可执行文件(如测试的一部分)。在这种情况下,请在特性中指定 cfg="target"

cfg="target" 实际上并未执行任何操作:它只是为了方便规则设计人员明确其意图。当 executable=False(表示 cfg 是可选项)时,仅在确实有助于可读性时才设置此值。

您还可以使用 cfg=my_transition 使用用户定义的过渡,这使得规则作者在更改配置方面具有很大的灵活性,其缺点是会使构建图变得更大且更易于理解

注意:过去,Bazel 并没有执行平台的概念,而是将所有构建操作都视为在主机上运行。因此,可以使用一个“主机”配置和一个“主机”转换在主机配置中构建依赖项。许多规则仍会为其工具使用“主机”转换,但该机制目前已被弃用,并且将尽可能迁移到“执行”转换。

“host”配置与“exec”配置有很多不同之处:

  • “host”是终端,“exec”则不是:当依赖项处于“host”配置中时,不允许再进行转换。进入“执行”配置后,您可以继续进行更多配置转换。
  • “host”是单体式的,“exec”则不是:只有一个“host”配置,但每个执行平台可以有不同的“exec”配置。
  • “host”假定您在 Bazel 所在的机器上运行工具,或在明显相似的机器上运行工具。这种情况不会再发生:您可以在本地机器上或远程执行程序上运行构建操作,也无法保证远程执行程序与本地机器具有相同的 CPU 和操作系统。

“exec”和“host”配置均应用相同的选项更改(例如,从 --host_compilation_mode 设置 --compilation_mode,通过 --host_cpu 设置 --cpu 等)。不同之处在于,“host”配置从其他所有标志的 default 值开始,而“exec”配置则基于目标配置,从标志的 current 值开始。

配置 Fragment

规则可以访问配置 Fragment,例如 cppjavajvm。不过,必须声明所有必需的 Fragment 以避免访问错误:

def _impl(ctx):
    # Using ctx.fragments.cpp leads to an error since it was not declared.
    x = ctx.fragments.java
    ...

my_rule = rule(
    implementation = _impl,
    fragments = ["java"],      # Required fragments of the target configuration
    host_fragments = ["java"], # Required fragments of the host configuration
    ...
)

ctx.fragments 仅为目标配置提供配置 Fragment。如果要访问主机配置的 fragment,请改用 ctx.host_fragments

通常,runfiles 树中文件的相对路径与源代码树或生成的输出树中该文件的相对路径相同。如果出于某种原因需要使用不同的参数,您可以指定 root_symlinkssymlinks 参数。root_symlinks 是映射到文件路径的字典,路径相对于 runfiles 目录的根目录。symlinks 字典是相同的,但路径隐式添加工作区名称的前缀。

    ...
    runfiles = ctx.runfiles(
        root_symlinks = {"some/path/here.foo": ctx.file.some_data_file2}
        symlinks = {"some/path/here.bar": ctx.file.some_data_file3}
    )
    # Creates something like:
    # sometarget.runfiles/
    #     some/
    #         path/
    #             here.foo -> some_data_file2
    #     <workspace_name>/
    #         some/
    #             path/
    #                 here.bar -> some_data_file3

如果使用了 symlinksroot_symlinks,请注意不要将两个不同的文件映射到 runfiles 树中的同一路径。这会导致构建失败,并显示描述冲突的错误。如需修复此冲突,您需要修改 ctx.runfiles 参数以移除冲突。系统会针对使用规则的所有目标以及依赖于这些目标的任何类型的目标进行这项检查。如果该工具可能被其他工具以传递方式使用,则尤其会有风险;符号链接名称在工具的运行文件及其所有依赖项中必须是唯一的。

代码覆盖率

运行 coverage 命令时,build 可能需要为某些目标添加覆盖率插桩。build 还会收集插桩的源文件列表。考虑的一部分目标由标志 --instrumentation_filter 控制。除非指定了 --instrument_test_targets,否则测试目标将被排除。

如果规则实现会在构建时添加覆盖率插桩,则需要在实现函数中考虑到这一点。如果要对目标的来源进行插桩,ctx.coverage_instrumented 在覆盖率模式下会返回 true:

# Are this rule's sources instrumented?
if ctx.coverage_instrumented():
  # Do something to turn on coverage for this compile action

需要在覆盖模式下始终开启的逻辑(无论目标的来源是否进行了特定插桩)都可以通过 ctx.configuration.coverage_enabled 获得调节。

如果规则在编译之前直接包含其依赖项中的源代码(例如头文件),那么在依赖项的插桩时需要启用编译时插桩:

# Are this rule's sources or any of the sources for its direct dependencies
# in deps instrumented?
if (ctx.configuration.coverage_enabled and
    (ctx.coverage_instrumented() or
     any([ctx.coverage_instrumented(dep) for dep in ctx.attr.deps]))):
    # Do something to turn on coverage for this compile action

规则还应提供有关哪些属性与 InstrumentedFilesInfo 提供程序覆盖率相关的信息(使用 coverage_common.instrumented_files_info 构造)。instrumented_files_infodependency_attributes 参数应列出所有运行时依赖项属性,包括代码依赖项(如 deps)和数据依赖项(如 data)。如果添加了覆盖率插桩,source_attributes 参数应列出相应规则的源文件属性:

def _example_library_impl(ctx):
    ...
    return [
        ...
        coverage_common.instrumented_files_info(
            ctx,
            dependency_attributes = ["deps", "data"],
            # Omitted if coverage is not supported for this rule:
            source_attributes = ["srcs", "hdrs"],
        )
        ...
    ]

如果未返回 InstrumentedFilesInfo,系统会使用在 dependency_attributes 中不将属性架构中的 cfg 设置为 "host""exec" 的每个非工具依赖项属性创建一个默认属性。(这并不是理想的行为,因为它在 dependency_attributes 而非 source_attributes 中放入了 srcs 等属性,但无需为依赖项链中的所有规则配置探索范围。)

验证操作

有时,您需要验证 build 的某些内容,而验证所需的信息仅在工件(源文件或生成的文件)中提供。由于这些信息位于工件中,因此规则无法在分析时进行验证,因为规则无法读取文件。相反,操作必须在执行时进行验证。如果验证失败,操作将失败,因此构建也会失败。

可能运行的验证示例包括静态分析、执行 lint 请求、依赖项和一致性检查以及样式检查。

验证操作还有助于将构建工件不需要的单独部分操作移至单独的操作,从而提高构建性能。例如,如果执行编译和 lint 操作的单个操作可以分为编译操作和 lint 操作,那么 lint 操作可以作为验证操作运行,并可与其他操作并行运行。

这些“验证操作”通常不会生成 build 中其他位置使用的任何内容,因为它们只需要声明关于输入的内容。但这会带来问题:如果验证操作未生成 build 中其他位置使用的任何内容,规则如何使操作运行?过去,这种方法是让验证操作输出一个空文件,人为地将该输出添加到 build 中其他某个重要操作的输入中:

这之所以行得通,是因为 Bazel 将始终在编译操作运行时运行验证操作,但这样做存在一些缺点:

  1. 验证操作位于构建的关键路径中。由于 Bazel 认为运行编译操作需要空白输出,因此它会先运行验证操作,即使编译操作会忽略输入也是如此。这样可以减少并行性并减慢构建速度。

  2. 如果 build 中的其他操作可能会代替编译操作运行,那么还需要将空的验证操作输出到这些操作(例如,java_library 的源 jar 输出)。如果稍后添加了可能会运行的新操作(而不是编译操作),并且意外清空空的验证输出,也会带来问题。

这些问题的解决方案是使用验证输出组。

验证输出组

验证输出组是一个输出组,专门用于保存其他验证操作未使用的输出,因此无需人为添加到其他操作的输入中。

这种组非常特殊,因为无论 --output_groups 标志的值如何,也无论目标如何依赖(例如在命令行上、作为依赖项或通过目标的隐式输出),都会始终请求其输出。请注意,正常的缓存和增量操作仍然适用:如果验证操作的输入未更改且验证操作之前成功,则验证操作不会运行。

使用此输出组仍需要验证操作输出一些文件,即使是空文件。这可能需要封装一些通常不会创建输出的工具,以便创建一个文件。

在以下三种情况下,系统不会运行目标的验证操作:

  • 当目标作为工具使用时
  • 当目标作为隐式依赖项(例如,以“_”开头的属性)依赖时
  • 目标是在主机或执行配置中构建的。

假定这些目标有各自的单独构建和测试,可以发现任何验证失败情况。

使用验证输出组

验证输出组的名称为 _validation,其使用方式与任何其他输出组相同:

def _rule_with_validation_impl(ctx):

  ctx.actions.write(ctx.outputs.main, "main output\n")

  ctx.actions.write(ctx.outputs.implicit, "implicit output\n")

  validation_output = ctx.actions.declare_file(ctx.attr.name + ".validation")
  ctx.actions.run(
      outputs = [validation_output],
      executable = ctx.executable._validation_tool,
      arguments = [validation_output.path])

  return [
    DefaultInfo(files = depset([ctx.outputs.main])),
    OutputGroupInfo(_validation = depset([validation_output])),
  ]


rule_with_validation = rule(
  implementation = _rule_with_validation_impl,
  outputs = {
    "main": "%{name}.main",
    "implicit": "%{name}.implicit",
  },
  attrs = {
    "_validation_tool": attr.label(
        default = Label("//validation_actions:validation_tool"),
        executable = True,
        cfg = "exec"),
  }
)

请注意,验证输出文件不会添加到 DefaultInfo 或任何其他操作的输入中。如果目标依赖于标签,或者目标的任何隐式输出直接或间接依赖,则此规则类型的目标的验证操作仍将运行。

通常,请务必将验证操作的输出放入验证输出组,而不添加到其他操作的输入中,否则可能会降低并行性。但请注意,Bazel 目前没有执行任何特殊检查。因此,您应测试验证操作输出不会添加到 Starlark 规则测试的任何操作输入中。例如:

load("@bazel_skylib//lib:unittest.bzl", "analysistest")

def _validation_outputs_test_impl(ctx):
  env = analysistest.begin(ctx)

  actions = analysistest.target_actions(env)
  target = analysistest.target_under_test(env)
  validation_outputs = target.output_groups._validation.to_list()
  for action in actions:
    for validation_output in validation_outputs:
      if validation_output in action.inputs.to_list():
        analysistest.fail(env,
            "%s is a validation action output, but is an input to action %s" % (
                validation_output, action))

  return analysistest.end(env)

validation_outputs_test = analysistest.make(_validation_outputs_test_impl)

验证操作标志

验证操作由 --run_validations 命令行标志(默认为 true)控制。

已弃用的功能

弃用了预先声明的输出

使用预声明输出有两种已弃用的方法:

  • ruleoutputs 参数指定输出属性名称和字符串模板之间的映射,用于生成预声明的输出标签。首选使用未预先声明的输出,并明确地向 DefaultInfo.files 添加输出。对于使用输出(而不是预先声明的输出)的标签,请使用规则目标的标签作为输入。

  • 对于可执行规则,ctx.outputs.executable 指的是与规则目标同名的预声明可执行输出。最好明确声明输出(例如使用 ctx.actions.declare_file(ctx.label.name)),并确保生成可执行文件的命令将其权限设置为允许执行。将可执行输出明确传递给 DefaultInfoexecutable 参数。

要避免的 Runfile 功能

ctx.runfilesrunfiles 类型具有一组复杂的功能,其中很多功能都是出于旧版原因保留的。以下建议有助于降低复杂性:

  • 避免使用 ctx.runfilescollect_datacollect_default 模式。这些模式会以硬编码的方式跨特定硬编码依赖项边缘隐式收集运行文件。您可以使用 ctx.runfilesfilestransitive_files 参数添加文件,也可以通过使用 runfiles = runfiles.merge(dep[DefaultInfo].default_runfiles) 从依赖项合并 runfile 来添加文件。

  • 避免使用 DefaultInfo 构造函数的 data_runfilesdefault_runfiles。请改为指定 DefaultInfo(runfiles = ...)。 “default”和“data”运行文件之间的区别因旧版原因而保持不变。例如,某些规则会将默认输出放在 data_runfiles(而非 default_runfiles)中。规则应包括默认输出,并合并到来自提供 Runfile 的属性(通常是 data)的 default_runfiles 中,而不是使用 data_runfiles

  • DefaultInfo 检索 runfiles(通常仅用于在当前规则与其依赖项之间合并运行文件)时,请使用 DefaultInfo.default_runfiles,而不是 DefaultInfo.data_runfiles

从旧版提供程序迁移

过去,Bazel 提供程序是 Target 对象中的简单字段。它们是使用点运算符访问的,它们通过将字段放入规则的实现函数返回的结构体中来创建。

此样式已弃用,不应在新代码中使用;请参阅下文,了解可能有助于您迁移的信息。新的提供程序机制可避免名称冲突。它还支持数据隐藏,方法是要求访问提供程序实例的任何代码都使用提供程序符号检索实例。

目前,旧版提供程序仍受支持。规则可以返回旧版提供程序和现代提供程序,如下所示:

def _old_rule_impl(ctx):
  ...
  legacy_data = struct(x="foo", ...)
  modern_data = MyInfo(y="bar", ...)
  # When any legacy providers are returned, the top-level returned value is a
  # struct.
  return struct(
      # One key = value entry for each legacy provider.
      legacy_info = legacy_data,
      ...
      # Additional modern providers:
      providers = [modern_data, ...])

如果 dep 是此规则实例生成的 Target 对象,则提供程序及其内容可检索为 dep.legacy_info.xdep[MyInfo].y

除了 providers 之外,返回的结构体还可以采用几个具有特殊含义的字段(因此不会创建相应的旧版提供程序):

  • 字段 filesrunfilesdata_runfilesdefault_runfilesexecutable 对应于 DefaultInfo 的同名字段。在返回 DefaultInfo 提供方的同时,不允许指定其中任何字段。

  • output_groups 字段接受一个结构体值,并且与 OutputGroupInfo 相对应。

在规则的 provides 声明和依赖项属性的 providers 声明中,旧版提供程序以字符串形式传入,而现代提供程序通过其 *Info 符号传入。迁移时,务必要从字符串更改为符号。对于难以以原子方式更新所有规则的复杂或大型规则集,您可以按照以下一系列步骤操作,从而节省时间:

  1. 使用上述语法修改生成旧版提供方的规则,以同时生成旧版提供方和现代提供方。对于声明返回旧版提供程序的规则,请更新该声明,以同时包含旧版提供程序和现代提供程序。

  2. 修改使用旧版提供程序的规则,以使用新版提供程序。如果任何属性声明需要旧版提供程序,也请将它们更新为需要新版提供程序。(可选)您可以将此工作与第 1 步交错运行,方法是让使用方接受/需要提供程序:使用 hasattr(target, 'foo') 测试是否存在旧提供程序,或使用 FooInfo in target 测试新提供程序。

  3. 从所有规则中完全移除旧提供商。