此页面由 Cloud Translation API 翻译。

宏

本页介绍了使用宏的基础知识，并介绍了典型用例、调试方法和惯例。

宏是从 BUILD 文件中调用的函数，可以实例化规则。宏主要用于封装和重复使用现有规则和其他宏。在加载阶段结束时，宏不再存在，Bazel 只能看到一组具体的实例化规则。

用法

宏的典型用例是您希望重复使用规则。

例如，BUILD 文件中的 genrule 使用 //:generator 生成文件，该文件包含通过命令硬编码的 some_arg 参数：

genrule(
    name = "file",
    outs = ["file.txt"],
    cmd = "$(location //:generator) some_arg > $@",
    tools = ["//:generator"],
)

如果要生成更多具有不同参数的文件，可能需要将此代码提取为宏函数。我们来调用宏 file_generator，它具有 name 和 arg 参数。将 genrule 替换为以下内容：

load("//path:generator.bzl", "file_generator")

file_generator(
    name = "file",
    arg = "some_arg",
)

file_generator(
    name = "file-two",
    arg = "some_arg_two",
)

file_generator(
    name = "file-three",
    arg = "some_arg_three",
)

在这里，您可以从 //path 软件包中的 .bzl 文件加载 file_generator 符号。通过将宏函数定义放入单独的 .bzl 文件中，可使 BUILD 文件保持简洁且具有声明性，可以从工作区中的任何软件包加载 .bzl 文件。

最后，在 path/generator.bzl 中编写该宏的定义，以封装和参数化原始的 Genrule 定义：

def file_generator(name, arg, visibility=None):
  native.genrule(
    name = name,
    outs = [name + ".txt"],
    cmd = "$(location //:generator) %s > $@" % arg,
    tools = ["//:generator"],
    visibility = visibility,
  )

您还可以使用宏将规则链接在一起。以下示例展示了链式规则，其中 genrule 使用上一个 Genrule 的输出作为输入：

def chained_genrules(name, visibility=None):
  native.genrule(
    name = name + "-one",
    outs = [name + ".one"],
    cmd = "$(location :tool-one) $@",
    tools = [":tool-one"],
    visibility = ["//visibility:private"],
  )

  native.genrule(
    name = name + "-two",
    srcs = [name + ".one"],
    outs = [name + ".two"],
    cmd = "$(location :tool-two) $< $@",
    tools = [":tool-two"],
    visibility = visibility,
  )

该示例仅向第二个世代分配了可见性值。这样，宏编写人员就可以隐藏中间规则的输出，以免工作区中的其他目标依赖于中间规则。

扩展宏

如果您想调查宏的用途，请将 query 命令与 --output=build 搭配使用，以查看扩展形式：

$ bazel query --output=build :file
# /absolute/path/test/ext.bzl:42:3
genrule(
  name = "file",
  tools = ["//:generator"],
  outs = ["//test:file.txt"],
  cmd = "$(location //:generator) some_arg > $@",
)

正在实例化原生规则

原生规则（不需要 load() 语句的规则）可以从 native 模块实例化：

def my_macro(name, visibility=None):
  native.cc_library(
    name = name,
    srcs = ["main.cc"],
    visibility = visibility,
  )

如果您需要知道软件包名称（例如，哪个 BUILD 文件正在调用宏），请使用函数 native.package_name()。请注意，native 只能在 .bzl 文件中使用，不能在 WORKSPACE 或 BUILD 文件中使用。

宏中的标签解析

由于宏是在加载阶段求值的，因此在宏中出现的标签字符串（例如 "//foo:bar"）会根据使用宏的 BUILD 文件进行解释，而不是相对于定义宏的 .bzl 文件进行解释。对于要在其他代码库中使用的宏（例如，因为它们是已发布的 Starlark 规则集的一部分），通常不适合此行为。

如需获得与 Starlark 规则相同的行为，请使用 Label 构造函数封装标签字符串：

# @my_ruleset//rules:defs.bzl
def my_cc_wrapper(name, deps = [], **kwargs):
  native.cc_library(
    name = name,
    deps = deps + select({
      # Due to the use of Label, this label is resolved within @my_ruleset,
      # regardless of its site of use.
      Label("//config:needs_foo"): [
        # Due to the use of Label, this label will resolve to the correct target
        # even if the canonical name of @dep_of_my_ruleset should be different
        # in the main workspace, such as due to repo mappings.
        Label("@dep_of_my_ruleset//tools:foo"),
      ],
      "//conditions:default": [],
    }),
    **kwargs,
  )

调试

bazel query --output=build //my/path:all 将显示 BUILD 文件在评估后的外观。所有宏、glob、循环都会扩展。已知限制：输出中当前不显示 select 表达式。
您可以根据 generator_function（哪个函数生成规则）或 generator_name（宏的名称属性）过滤输出： bash $ bazel query --output=build 'attr(generator_function, my_macro, //my/path:all)'
如需确定规则 foo 在 BUILD 文件中的确切生成位置，您可以尝试以下技巧。在 BUILD 文件顶部附近插入以下代码行：cc_library(name = "foo")。运行 Bazel。创建 foo 规则后，您会遇到一个异常（由于名称冲突），该异常会显示完整的堆栈轨迹。
您也可以使用 print 进行调试。它会在加载阶段将消息显示为 DEBUG 日志行。在将代码提交到仓库之前，请移除 print 调用，或者在默认为 False 的 debugging 参数下有条件地调用（除非在极少数情况下）。

错误数

如果要抛出错误，请使用 fail 函数。向用户清楚说明问题所在，以及如何修复 BUILD 文件。无法捕获错误。

def my_macro(name, deps, visibility=None):
  if len(deps) < 2:
    fail("Expected at least two values in deps")
  # ...

惯例

所有实例化规则的公共函数（不以下划线开头的函数）都必须具有 name 参数。此参数不应为可选参数（无需提供默认值）。
公共函数应使用遵循 Python 惯例的文档字符串。
在 BUILD 文件中，宏的 name 参数必须是关键字参数（而不是位置参数）。
由宏生成的规则的 name 属性应将名称参数作为前缀。例如，macro(name = "foo") 可以生成 cc_library foo 和 Genrule foo_gen。
在大多数情况下，可选参数的默认值应该为 None。None 可以直接传递给原生规则，原生规则的处理方式与未传入任何参数相同。因此，无需将其替换为 0、False 或 [] 即可实现此目的。相反，该宏应遵从它创建的规则，因为它们的默认值可能很复杂，也可能随时间发生变化。此外，明确设置为默认值的参数与通过查询语言或构建系统内部构件访问时从未设置（或设置为 None）的参数看起来有所不同。
宏应有一个可选的 visibility 参数。