本页面介绍了 Starlark 配置(用于自定义项目构建方式的 Bazel 的 API)的优势和基本用法。其中介绍了如何定义构建设置,并提供了相关示例。
这样,您就可以:
- 为项目定义自定义标志,从而无需使用
--define
- 编写转换,以在与其父级不同的配置(例如
--compilation_mode=opt
或--cpu=arm
)中配置依赖项 - 将更好的默认值融入规则中(例如,使用指定 SDK 自动构建
//my:android_app
)
等等,完全通过 .bzl 文件完成(不需要发布 Bazel 版本)。如需查看示例,请参阅 bazelbuild/examples
代码库。
用户定义的 build 设置
构建设置是一段配置信息。您可以将配置视为键值对映射。设置 --cpu=ppc
和 --copt="-DFoo"
会生成类似于 {cpu: ppc, copt: "-DFoo"}
的配置。每个条目都是一项构建设置。
cpu
和 copt
等传统标志是原生设置 - 其键是在原生 bazel Java 代码中定义的,其值是在原生 bazel Java 代码中设置的。Bazel 用户只能通过命令行和其他以原生方式维护的 API 对它们进行读取和写入。更改原生标志以及公开这些标志的 API 需要 Bazel 版本。用户定义的 build 设置在 .bzl
文件中定义(因此无需 Bazel 版本即可注册更改)。它们也可以通过命令行进行设置(如果它们被指定为 flags
,请参阅下文了解详情),但也可以通过用户定义的转换进行设置。
定义构建设置
build_setting
rule()
参数
构建设置是与其他规则一样的规则,可通过 Starlark rule()
函数的 build_setting
属性进行区分。
# example/buildsettings/build_settings.bzl
string_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
build_setting
属性接受一个用于指定 build 设置类型的函数。该类型仅限于一组基本的 Starlark 类型,例如 bool
和 string
。如需了解详情,请参阅 config
模块文档。您可以在规则的实现函数中完成更复杂的输入。详见下文。
config
模块的函数接受可选的布尔值参数 flag
,该参数默认设为 false。如果 flag
设为 true,则用户既可以在命令行中设置构建设置,也可以由规则编写者通过默认值和转换在内部设置构建设置。并非所有设置都应该由用户自行设置。例如,如果您作为规则编写者,希望在测试规则内启用某种调试模式,那么您肯定不希望允许用户在其他非测试规则中随意启用该功能。
使用 ctx.build_setting_value
与所有规则一样,构建设置规则也有实现函数。您可以通过 ctx.build_setting_value
方法访问 build 设置的基本 Starlark 类型值。此方法仅适用于 build 设置规则的 ctx
对象。这些实现方法可以直接转发 build 设置值,也可以对其执行额外的工作,例如类型检查或更复杂的结构体创建。下面展示了如何实现 enum
类型的构建设置:
# example/buildsettings/build_settings.bzl
TemperatureProvider = provider(fields = ['type'])
temperatures = ["HOT", "LUKEWARM", "ICED"]
def _impl(ctx):
raw_temperature = ctx.build_setting_value
if raw_temperature not in temperatures:
fail(str(ctx.label) + " build setting allowed to take values {"
+ ", ".join(temperatures) + "} but was set to unallowed value "
+ raw_temperature)
return TemperatureProvider(type = raw_temperature)
temperature = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
定义多集字符串标志
字符串设置具有额外的 allow_multiple
参数,该参数允许在命令行或 bazelrcs 中多次设置标志。它们的默认值仍使用字符串类型的属性进行设置:
# example/buildsettings/build_settings.bzl
allow_multiple_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True, allow_multiple = True)
)
# example/BUILD
load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
allow_multiple_flag(
name = "roasts",
build_setting_default = "medium"
)
该标志的每个设置都被视为单个值:
$ bazel build //my/target --//example:roasts=blonde \
--//example:roasts=medium,dark
以上内容会被解析为 {"//example:roasts": ["blonde", "medium,dark"]}
,ctx.build_setting_value
会返回列表 ["blonde", "medium,dark"]
。
实例化构建设置
使用 build_setting
参数定义的规则具有隐式强制性 build_setting_default
属性。此属性采用 build_setting
参数声明的类型。
# example/buildsettings/build_settings.bzl
FlavorProvider = provider(fields = ['type'])
def _impl(ctx):
return FlavorProvider(type = ctx.build_setting_value)
flavor = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
# example/BUILD
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
name = "favorite_flavor",
build_setting_default = "APPLE"
)
预定义设置
Skylib 库包含一组预定义设置,您无需编写自定义 Starlark 即可实例化。
例如,如需定义接受一组有限字符串值的设置,请使用以下代码:
# example/BUILD
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
string_flag(
name = "myflag",
values = ["a", "b", "c"],
build_setting_default = "a",
)
如需查看完整列表,请参阅常见的 build 设置规则。
使用 build 设置
取决于构建设置
如果目标想要读取一段配置信息,可以通过常规属性依赖项直接依赖于 build 设置。
# example/rules.bzl
load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
def _rule_impl(ctx):
if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
...
drink_rule = rule(
implementation = _rule_impl,
attrs = {
"flavor": attr.label()
}
)
# example/BUILD
load("//example:rules.bzl", "drink_rule")
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
name = "favorite_flavor",
build_setting_default = "APPLE"
)
drink_rule(
name = "my_drink",
flavor = ":favorite_flavor",
)
语言可能希望创建一组规范的 build 设置,该语言的所有规则都依赖于这些设置。虽然 fragments
的原生概念在 Starlark 配置环境中不再作为硬编码对象存在,但转换此概念的一种方法是使用一组常用隐式属性。例如:
# kotlin/rules.bzl
_KOTLIN_CONFIG = {
"_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
"_mode": attr.label(default = "//kotlin/config:mode-flag"),
...
}
...
kotlin_library = rule(
implementation = _rule_impl,
attrs = dicts.add({
"library-attr": attr.string()
}, _KOTLIN_CONFIG)
)
kotlin_binary = rule(
implementation = _binary_impl,
attrs = dicts.add({
"binary-attr": attr.label()
}, _KOTLIN_CONFIG)
在命令行中使用 build 设置
与大多数原生标志类似,您可以使用命令行来设置标记为标志的构建设置。构建设置的名称是使用 name=value
语法的完整目标路径:
$ bazel build //my/target --//example:string_flag=some-value # allowed
$ bazel build //my/target --//example:string_flag some-value # not allowed
支持特殊的布尔语法:
$ bazel build //my/target --//example:boolean_flag
$ bazel build //my/target --no//example:boolean_flag
使用 build 设置别名
您可以为 build 设置目标路径设置别名,以便在命令行中更轻松地进行读取。别名的功能与原生标志类似,并且还会使用双短划线选项语法。
通过将 --flag_alias=ALIAS_NAME=TARGET_PATH
添加到 .bazelrc
来设置别名。例如,如需将别名设置为 coffee
,请使用以下代码:
# .bazelrc
build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp
最佳实践:多次设置别名会使最新的别名优先。使用唯一的别名以避免意外的解析结果。
如需使用别名,请输入它来代替 build 设置目标路径。
对于上述 coffee
在用户的 .bazelrc
中设置的示例:
$ bazel build //my/target --coffee=ICED
来替代
$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED
最佳实践:虽然可以在命令行中设置别名,但将其保留在 .bazelrc
中可以减少命令行的混乱。
标签类型的构建设置
与其他构建设置不同,标签类型的设置无法使用 build_setting
规则参数进行定义。但 bazel 有两条内置规则:label_flag
和 label_setting
。这些规则用于转发设置了 build 设置的实际目标的提供程序。label_flag
和 label_setting
可由转换读取/写入,label_flag
可以由用户设置,就像其他 build_setting
规则一样。它们的唯一区别是它们无法自定义。
标签类型的设置最终将取代后期绑定默认值的功能。延迟绑定默认属性是标签类型的属性,其最终值可能会受到配置的影响。在 Starlark 中,这将替换 configuration_field
API。
# example/rules.bzl
MyProvider = provider(fields = ["my_field"])
def _dep_impl(ctx):
return MyProvider(my_field = "yeehaw")
dep_rule = rule(
implementation = _dep_impl
)
def _parent_impl(ctx):
if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
...
parent_rule = rule(
implementation = _parent_impl,
attrs = { "my_field_provider": attr.label() }
)
# example/BUILD
load("//example:rules.bzl", "dep_rule", "parent_rule")
dep_rule(name = "dep")
parent_rule(name = "parent", my_field_provider = ":my_field_provider")
label_flag(
name = "my_field_provider",
build_setting_default = ":dep"
)
构建设置和 select()
用户可以使用 select()
在 build 设置中配置属性。build 设置目标可以传递给 config_setting
的 flag_values
属性。与配置匹配的值会作为 String
传递,然后解析为构建设置的类型以进行匹配。
config_setting(
name = "my_config",
flag_values = {
"//example:favorite_flavor": "MANGO"
}
)
用户定义的转换
配置转换用于将 build 图内一个配置目标的转换映射到另一个配置目标。
定义
转换定义了规则之间的配置更改。例如,“编译我的依赖项,将其用于与父项不同的 CPU”这样的请求是由过渡处理的。
正式地说,转换是指从输入配置到一个或多个输出配置的函数。大多数转换都是 1:1 的,例如“使用 --cpu=ppc
替换输入配置”。也可以存在 1:2+ 转换,但会有一些特殊限制。
在 Starlark 中,过渡的定义与规则非常相似,具有定义 transition()
函数和实现函数。
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {"//example:favorite_flavor" : "MINT"}
hot_chocolate_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
transition()
函数接受一个实现函数、一组要读取的 build 设置(inputs
) 和一组要写入的 build 设置 (outputs
)。该实现函数有两个参数:settings
和 attr
。settings
是 transition()
参数中声明的所有设置的字典{String
:Object
}。inputs
attr
是附加过渡的属性和值字典。作为传出边缘转换附加时,这些属性的值都经过 select() 后分辨率配置。作为传入边缘过渡附加时,attr
不包含任何使用选择器解析其值的属性。如果 --foo
上的传入边缘过渡读取属性 bar
,然后也在 --foo
上选择设置属性 bar
,那么传入的边缘过渡有可能在过渡中读取错误的 bar
值。
实现函数必须返回要应用的新 build 设置值的字典(如果是具有多种输出配置的转换,则必须返回字典列表)。返回的字典密钥集必须与传递给转换函数的 outputs
参数的一组 build 设置完全一致。即使 build 设置在转换过程中实际上并未更改,也是如此 - 必须在返回的字典中明确传递其原始值。
定义 1:2+ 过渡
传出边缘转换可以将单个输入配置映射到两个或更多输出配置。这对于定义捆绑多架构代码的规则非常有用。
通过在过渡实现函数中返回字典列表来定义 1:2+ 过渡。
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return [
{"//example:favorite_flavor" : "LATTE"},
{"//example:favorite_flavor" : "MOCHA"},
]
coffee_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
它们还可以设置自定义键,规则实现函数可以使用这些键来读取各个依赖项:
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {
"Apple deps": {"//command_line_option:cpu": "ppc"},
"Linux deps": {"//command_line_option:cpu": "x86"},
}
multi_arch_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
)
附加过渡效果
过渡可以附加在两个位置:入射边缘和出出边缘。实际上,这意味着规则可以转换自己的配置(传入边缘转换)并转换其依赖项的配置(传出边缘转换)。
注意:目前无法将 Starlark 转换附加到原生规则。如果您需要执行此操作,请联系 bazel-think@googlegroups.com,以获得有关解决方法的帮助。
传入的边缘过渡效果
通过将 transition
对象(由 transition()
创建)附加到 rule()
的 cfg
参数,可激活传入的边缘过渡:
# example/rules.bzl
load("example/transitions:transitions.bzl", "hot_chocolate_transition")
drink_rule = rule(
implementation = _impl,
cfg = hot_chocolate_transition,
...
传入的边缘过渡必须为 1:1 过渡。
传出边缘转换
通过将 transition
对象(由 transition()
创建)附加到属性的 cfg
参数来激活传出边缘过渡:
# example/rules.bzl
load("example/transitions:transitions.bzl", "coffee_transition")
drink_rule = rule(
implementation = _impl,
attrs = { "dep": attr.label(cfg = coffee_transition)}
...
传出边缘过渡效果可以是 1:1 或 1:2+。
如需了解如何读取这些键,请参阅通过转换访问属性。
原生选项的过渡
Starlark 转换还可以通过为选项名称添加特殊前缀,声明对原生 build 配置选项的读写操作。
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {"//command_line_option:cpu": "k8"}
cpu_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
不支持的原生选项
Bazel 不支持在 --define
上使用 "//command_line_option:define"
进行转换。您可以改用自定义构建设置。一般来说,不建议改用 build 设置,而不是重新使用 --define
。
Bazel 不支持在 --config
上转换。这是因为 --config
是扩展到其他标志的“展开”标志。
至关重要的是,--config
可能包含不影响 build 配置的标志,如 --spawn_strategy
。根据设计,Bazel 无法将此类标志绑定到各个目标。这意味着,没有一致的方式将其应用于过渡。
如需解决此问题,您可以明确列出转换中属于配置一部分的标志。这需要在两个位置保持 --config
的扩展,这是已知的界面缺陷。
“允许”多项构建设置中的转换
在设置允许多个值的 build 设置时,必须使用列表来设置设置的值。
# example/buildsettings/build_settings.bzl
string_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True, allow_multiple = True)
)
# example/BUILD
load("//example/buildsettings:build_settings.bzl", "string_flag")
string_flag(name = "roasts", build_setting_default = "medium")
# example/transitions/rules.bzl
def _transition_impl(settings, attr):
# Using a value of just "dark" here will throw an error
return {"//example:roasts" : ["dark"]},
coffee_transition = transition(
implementation = _transition_impl,
inputs = [],
outputs = ["//example:roasts"]
)
免运维转换
如果过渡返回 {}
、[]
或 None
,这表示将所有设置保留为原始值。这比将每个输出明确设置为其自身更方便。
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (attr)
if settings["//example:already_chosen"] is True:
return {}
return {
"//example:favorite_flavor": "dark chocolate",
"//example:include_marshmallows": "yes",
"//example:desired_temperature": "38C",
}
hot_chocolate_transition = transition(
implementation = _impl,
inputs = ["//example:already_chosen"],
outputs = [
"//example:favorite_flavor",
"//example:include_marshmallows",
"//example:desired_temperature",
]
)
通过转换访问属性
将过渡附加到出向边缘时(无论过渡是 1:1 过渡还是 1:2+ 过渡),如果 ctx.attr
尚未成为列表,则强制执行此操作。此列表中元素的顺序未指定。
# example/transitions/rules.bzl
def _transition_impl(settings, attr):
return {"//example:favorite_flavor" : "LATTE"},
coffee_transition = transition(
implementation = _transition_impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
def _rule_impl(ctx):
# Note: List access even though "dep" is not declared as list
transitioned_dep = ctx.attr.dep[0]
# Note: Access doesn't change, other_deps was already a list
for other_dep in ctx.attr.other_deps:
# ...
coffee_rule = rule(
implementation = _rule_impl,
attrs = {
"dep": attr.label(cfg = coffee_transition)
"other_deps": attr.label_list(cfg = coffee_transition)
})
如果转换为 1:2+
并设置了自定义键,则 ctx.split_attr
可用于读取每个键的各个依赖项:
# example/transitions/rules.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {
"Apple deps": {"//command_line_option:cpu": "ppc"},
"Linux deps": {"//command_line_option:cpu": "x86"},
}
multi_arch_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
)
def _rule_impl(ctx):
apple_dep = ctx.split_attr.dep["Apple deps"]
linux_dep = ctx.split_attr.dep["Linux deps"]
# ctx.attr has a list of all deps for all keys. Order is not guaranteed.
all_deps = ctx.attr.dep
multi_arch_rule = rule(
implementation = _rule_impl,
attrs = {
"dep": attr.label(cfg = multi_arch_transition)
})
如需查看完整示例,请访问此处。
与平台和工具链集成
目前,许多原生标志(如 --cpu
和 --crosstool_top
)都与工具链解析有关。将来,在目标平台上进行转换可能会取代这些类型的标志上的显式转换。
内存和性能注意事项
为 build 添加转换以及新配置会带来一定的代价:build 图较大、build 图不易理解以及 build 速度较慢。考虑在构建规则中使用转换时,有必要考虑这些费用。以下示例展示了过渡如何使 build 图呈指数增长。
行为不当的 build:案例研究
图 1. 显示顶级目标及其依赖项的可伸缩性图表。
此图显示了一个顶级目标 //pkg:app
,该目标依赖于 //pkg:1_0
和 //pkg:1_1
这两个目标。这两个目标都依赖于 //pkg:2_0
和 //pkg:2_1
这两个目标。这两个目标都依赖于 //pkg:3_0
和 //pkg:3_1
这两个目标。此过程将持续到 //pkg:n_0
和 //pkg:n_1
,它们都依赖于单个目标 //pkg:dep
。
构建//pkg:app
需要 \(2n+2\) 目标:
//pkg:app
//pkg:dep
- \(i\) 的 \([1..n]\)价格为
//pkg:i_0
和//pkg:i_1
假设您implement了 --//foo:owner=<STRING>
标志,且 //pkg:i_b
适用
depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"
换句话说,//pkg:i_b
会针对其所有依赖项将 b
附加到 --owner
的旧值。
这会生成以下配置的目标:
//pkg:app //foo:owner=""
//pkg:1_0 //foo:owner=""
//pkg:1_1 //foo:owner=""
//pkg:2_0 (via //pkg:1_0) //foo:owner="0"
//pkg:2_0 (via //pkg:1_1) //foo:owner="1"
//pkg:2_1 (via //pkg:1_0) //foo:owner="0"
//pkg:2_1 (via //pkg:1_1) //foo:owner="1"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_0) //foo:owner="00"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_1) //foo:owner="01"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_0) //foo:owner="10"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_1) //foo:owner="11"
...
//pkg:dep
会生成 \(2^n\) 已配置的目标:config.owner=
\(\{0,1\}\)中的所有 \(b_i\) “\(b_0b_1...b_n\)”。
这会使构建图呈指数级大于目标图,并产生相应的内存和性能影响。
待办事项:添加衡量和缓解这些问题的策略。
深入阅读
如需详细了解如何修改 build 配置,请参阅:
- Starlark build 配置
- Bazel 可配置性路线图
- 完整的端到端示例集