action_listener
示例
action_listener(
name = "index_all_languages",
mnemonics = [
"Javac",
"CppCompile",
"Python",
]
)
参数
| name |
Name; required 一个target 名称 |
| extra_actions |
List of labels; required actions_listener 中一些需要被加入到构建流程的 extra_action。例如 [ "//my/tools:analyzer"]
|
| mnemonics |
List of string;required 这个 actions_listener 应该监听的助记符列表，例如 ["Javac"]。助记符不是公共接口，因此不保证助记符的动作不会改变。 |
extra_action
将其作为常规构建目标指定时，extra_action 不会有任何有意义的输出。它允许开发者在构建流程中隐式的插入额外的动作。
这些extra_action 作为命令行运行。这个命令行能够访问包含 protocol buffer 的文件并作为 $(EXTRA_ACTION_FILE)。这在原始动作中有详细的信息。它还能访问原始动作能够访问的所有文件。查看
extra_actions_base.proto 查看更多详细信息。 每个 proto 文件包含一个和 ExtraActionInfo 信息。
和其他所有的动作一样，extra actions 也是沙箱化的，并且一个被设计成能够处理该问题。
参数
| name |
Name; required 一个构建目标的名称 你可以在 action_listener 的 extra_actions 中通过 label 引入 |
| cmd |
String; required 这个命令和 genrule cmd attribute 很像，但有以下区别： 1. 没有启发式扩展标签。仅仅使用 用文件路径代替并通过label` 引用 |
| out_template |
List of strings; optional 由 extra_action 生成的一系列模板文件。这个模板可以生成一下变量： 1. $(ACTION_ID), 表示这个 extra_action 的 id。 用于生成唯一的输出文件。 |
| requires_action_output |
Boolean; optional; default is False 表示这个 extra_action 需要原始 action 的输出作为输入。当这个值置为 true 时， 这个 extra_action 才能够将原始 action 的输出作为它输入的一部分。 |
| tools |
List of labels; optional 该规则所依赖的工具。查看 dependencies 以获取更多信息。 构建系统确保 extra_action 运行之前进行预构建；它们使用host configuration，因为它们必须在构建过程中作为工具运行。个人的工具能够通过 $(location //x:y) 以获取 //x:y
|
alias
alias 规则构建一个规则的别名。
别名只能用于 常规 targets。除此之外， package_group 和 test_suite 不能被定义别名。
alias 规则拥有自己的可见性定义。在其他方面，它的行为和所引用的规则一样除了一些小差别：
- 不会运行测试。要定义测试的别名， 在 target 的
tests中 使用test_suite规则。 - 当定义环境组时，
environment规则的别名不支持。 它们在命令行的--target_environment中不被支持。
示例
filegroup(
name = "data",
srcs = ["data.txt"],
)
alias(
name = "other",
actual = ":data",
)
参数
| 名称 | 说明 |
|---|---|
| name |
Name; required |
| actual |
Label; required 指向的target。不仅可以是规则，也可以是一个输入文件。 |
config_setting
匹配一个预期的配置状态（可以用 Bazel flags 或者 平台约束 来表示）以触发相应的配置属性。查看 select 认识如何使用该规则，Configurable attributes 来认识一般功能特性。
示例
以下将会匹配任意一个在命令行或者 .bazelrc 文件中指定 --compilation_mode=opt 或者 -c opt 的选项。
config_setting(
name = "simple",
values = {"compilation_mode": "opt"}
)
以下将会匹配任意调用在 arm 上构建并且自定义 FOO=bar，例如 bazel build --cpu=arm --defina FOO=bar ...
config_setting(
name = "two_conditions",
values = {
"cpu": "arm",
"define": "FOO=bar"
}
)
假设存在构建约束和标签，以下匹配任何在 x86_64 架构和 glibc 版本2.25 的构建。注意，如果平台定义了除这两个平台外的其他值，也依然会匹配。
config_setting(
name = "64bit_glibc_2_25",
constraint_values = [
"@platforms//cpu:x86_64",
"//example:glibc_2_25",
]
)
在所有这些情况下，构建时的这些配置都是可变的。例如一个 target 需要为不同的其他平台构建。这意味着即使一个 config_setting 没有在命令行层面匹配上，也有可能在构建其他配置时被匹配。（如何理解呢，就是说假如有一个 config_setting 我们称之为A，命令行并不满足其条件。但是在构建其他目标时，这些目标可能会直接指定这个A，此时就匹配上了）
注意
- 参考 select 来理解
config_setting究竟是如何工作的 - 对于支持简写的 flags，例如
--compilation_mode和-c，values中的定义必须 使用全称。 - 如果一个 flags 采用多个值例如
--copt=Da --copt=-Db或者列表形式的 Starlark flag，values = {"flag":"a"}匹配任意在列表出现的 a值。
values = {"myflag" : "a,b"}也是相同的工作逻辑：它匹配--myflag=a --myflag=b，--myflag=a --myflag=b --myflag=c，--myflag=a,b，和--myflag=c,b,a。这些标记之间的确切语义是有所不同的，例如，--copt在同一实例中是不支持多值的。即--copt=a,b代表的意义是 ["a,b"]。而--copt=a --copt=b代表的是 ["a","b"]。所以values = {"copt":"a,b"}仅匹配前者，而不匹配后者。但是--ios_multi_cpus则两种形式同时支持（个人觉得是不好的做法）。查看 flag 的定义并且仔细测试他们的确切语义。 - 如果你需要自定义 flag。使用 [Starlark-defined flags]。 你也可以使用
--define，但这个支持比较弱且不建议使用，参考这里Define Discussion。 - 避免在不同的保重定义完全相同的
config_setting。相反，引用规范包中定义的config_setting。 -
values,define_values 和 constraint_values 能够在同一个
config_setting中组合使用，但至少需要存在一个。
参数
| 名称 | 说明 |
|---|---|
| name |
Name; required 唯一名称 |
| constraint_values |
List of [labels]; optinal; [noconfigurable] 目标平台必须指定最小的约束条件集才能匹配此 config_setting。任何其他的 platform 的约束条件都将被忽略。参考 Configurable Build Attributes。如果两个 config_setting 都匹配了相同的 select 那么两个应该是完全相同的约束。？？？，（译者猜测是这个意思） |
| define_values |
Dictionary: String -> String; optional; [noconfigurable] define_values 和在 values 中使用define 含义相同。 |
| flag_values |
null; optional; [nonconfigurable] 和 values 含义相同但是为 Starlark flag 设计 |
| values |
Dictionary: String -> String; optional; [nonconfigurable] |
网友评论