本页介绍了如何创建代码库规则,并提供了示例以供您详细了解。
外部代码库是一种只能在 WORKSPACE
文件中使用的规则,可在 Bazel 的加载阶段启用非封闭操作。每个外部代码库规则都会创建自己的工作区,并包含自己的 BUILD
文件和工件。它们可用于依赖第三方库(例如 Maven 打包的库),也可用于生成特定于 Bazel 运行主机的 BUILD
文件。
创建代码库规则
在 .bzl
文件中,使用 repository_rule 函数创建新的代码库规则并将其存储在全局变量中。
自定义代码库规则的使用方式与原生代码库规则一样。它具有必需的 name
属性,并且其 build 文件中存在的每个目标都可以称为 @<name>//package:target
,其中 <name>
是 name
属性的值。
当您明确构建该规则或该规则是 build 的依赖项时,系统会加载该规则。在这种情况下,Bazel 将执行其 implementation
函数。此函数介绍了如何创建代码库及其内容和 BUILD
文件。
属性
属性是作为字典传递给 attrs
规则参数的规则参数。在定义代码库规则时,系统会列出已定义的属性及其类型。将 url
和 sha256
属性定义为字符串的示例:
local_repository = repository_rule(
implementation=_impl,
local=True,
attrs={
"url": attr.string(mandatory=True)
"sha256": attr.string(mandatory=True)
}
)
如需在实现函数中访问属性,请使用 repository_ctx.attr.<attribute_name>
:
def _impl(repository_ctx):
url = repository_ctx.attr.url
checksum = repository_ctx.attr.sha256
所有 repository_rule
都具有隐式定义的属性(就像 build 规则一样)。这两个隐式属性分别是 name
(与 build 规则相同)和 repo_mapping
。您可以使用 repository_ctx.name
访问代码库规则的名称。repo_mapping
的含义与原生代码库规则 local_repository
和 new_local_repository
相同。
如果属性名称以 _
开头,则表示该属性是私有的,用户无法对其进行设置。
实现函数
每个代码库规则都需要一个 implementation
函数。它包含规则的实际逻辑,并且仅在加载阶段执行。
该函数只有一个输入参数,即 repository_ctx
。该函数会返回 None
,表示在指定参数的情况下,该规则是可重现的;或者返回一个字典,其中包含该规则的一组参数,这些参数会将该规则转换为可生成相同代码库的可重现规则。例如,对于跟踪 Git 代码库的规则,这意味着返回特定提交标识符,而不是最初指定的浮动分支。
输入参数 repository_ctx
可用于访问属性值和非密封函数(查找二进制文件、执行二进制文件、在代码库中创建文件或从互联网下载文件)。如需了解更多背景信息,请参阅该库。示例:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
何时执行实现函数?
当 Bazel 需要该仓库中的目标时,就会执行该仓库的实现函数,例如当其他目标(在其他仓库中)依赖于该目标或在命令行中提及该目标时。然后,实现函数应在文件系统中创建代码库。这称为“提取”代码库。
与常规目标不同,当某些更改会导致代码库发生变化时,系统不一定会重新提取代码库。这是因为 Bazel 无法检测到某些更改,或者会导致每次构建时产生过多开销(例如,从网络提取的内容)。因此,只有在以下某项发生变化时,系统才会重新提取代码库:
- 传递给
WORKSPACE
文件中代码库声明的参数。 - 包含代码库实现的 Starlark 代码。
- 使用
repository_rule
的environ
属性声明的任何环境变量的值。您可以使用--action_env
标志在命令行上对这些环境变量的值进行硬编码(但此标志会使 build 的所有操作失效)。 - 传递给
repository_ctx
的read()
、execute()
和类似方法的任何文件内容,该方法由标签引用(例如//mypkg:label.txt
,但不包括mypkg/label.txt
) - 执行
bazel sync
时。
repository_rule
有两个参数用于控制何时重新提取代码库:
- 如果设置了
configure
标志,则只有在向bazel sync
传递--configure
参数时,才会在bazel sync
上重新提取代码库(如果未设置该属性,此命令不会导致重新提取) 如果设置了
local
标志,除了上述情况外,当 Bazel 服务器重启或影响代码库声明的任何文件发生更改(例如WORKSPACE
文件或其加载的文件)时,系统也会重新提取代码库,无论这些更改是否导致代码库的声明或其代码发生更改。在这些情况下,系统不会重新提取非本地代码库。这是因为这些代码库假定会与网络通信,或者存在其他高成本。
重启实现函数
如果实现函数请求的依赖项缺失,则可以在提取代码库时重启该实现函数。在这种情况下,实现函数的执行将停止,系统会解析缺失的依赖项,并在依赖项解析完毕后重新执行该函数。为避免不必要的重启(由于可能需要重复访问网络,因此代价很高),系统会预提取标签参数,前提是所有标签参数都可以解析为现有文件。请注意,从仅在函数执行期间构建的字符串或标签解析路径可能仍会导致重启。
强制重新提取外部代码库
有时,外部代码库可能会在其定义或依赖项没有任何更改的情况下过时。例如,提取源代码的代码库可能会跟踪第三方代码库的特定分支,并且该分支上有新的提交。在这种情况下,您可以通过调用 bazel sync
要求 bazel 无条件地重新提取所有外部代码库。
此外,某些规则会检查本地机器,如果本地机器升级,这些规则可能会过时。在这里,您可以使用 bazel sync --configure
指示 bazel 仅重新提取 repository_rule
定义设置了 configure
属性的外部代码库。
示例
C++ 自动配置的工具链:它使用代码库规则,通过查找本地 C++ 编译器、环境和 C++ 编译器支持的标志,为 Bazel 自动创建 C++ 配置文件。
Go 代码库使用多个
repository_rule
来定义使用 Go 规则所需的依赖项列表。rules_jvm_external 默认会创建一个名为
@maven
的外部仓库,用于为传递依赖项树中的每个 Maven 工件生成构建目标。