标签是目标的标识符。完整规范的典型标签 如下所示:
@@myrepo//my/app/main:app_binary
标签的第一个部分是代码库名称 @@myrepo
。双 @
语法表示这是一个规范代码库
名称,该名称在
工作区。无论在何种上下文中显示,使用规范代码库名称的标签都能明确标识目标。
通常,规范代码库名称是类似于 @@rules_java~7.1.0~toolchains~local_jdk
的神秘字符串。更常见的是,标签具有明显的代码库名称,如下所示:
@myrepo//my/app/main:app_binary
唯一的区别是代码库名称的前缀是一个 @
,而不是两个。
表示具有表观名称 myrepo
的代码库,该名称可能不同
将会根据此标签所在的上下文进行选择。
在典型情况下,标签所引用的
但代码库名称部分可以省略。在 @@myrepo
中,第一个
标签通常写为
//my/app/main:app_binary
标签的第二部分是不符合条件的软件包名称
my/app/main
,软件包的路径
代码库根目录的相对路径代码库名称和非限定软件包名称共同构成完全限定软件包名称 @@myrepo//my/app/main
。如果标签引用的是其所使用的同一软件包,则可以省略软件包名称(以及可选的分号)。因此,在 @@myrepo//my/app/main
中,此标签可以通过以下任一方式编写:
app_binary
:app_binary
通常,对于文件,我们会省略英文冒号,但对于规则,则会保留英文冒号,但这并不重要。
英文冒号后面的部分 app_binary
是不符合条件的目标
名称。如果它与软件包路径的最后一个组件匹配,则可以省略它和英文冒号。因此,以下两个标签是等效的:
//my/app/lib
//my/app/lib:lib
软件包子目录中文件目标的名称是相对于软件包根目录(包含 BUILD
文件的目录)的文件路径。因此,
此文件位于代码库的 my/app/main/testdata
子目录中:
//my/app/main:testdata/input.txt
//my/app
和 @@some_repo//my/app
等字符串有两个含义,具体取决于
标签的使用环境:当 Bazel 需要标签时,
//my/app:app
和 @@some_repo//my/app:app
。但是,当 Bazel
需要软件包(例如在 package_group
规范中),则应引用
包含该标签的软件包。
BUILD
文件中的一个常见错误是使用 //my/app
引用软件包,或者
应用于软件包中的所有目标,但实际上不是。请注意,它等同于 //my/app:app
,因此会为当前代码库的 my/app
软件包中的 app
目标命名。
不过,在使用 //my/app
来引用软件包时,
package_group
规范或.bzl
文件中
用于表明软件包名称是绝对名称且位于顶级目录
目录。
相对标签不能用于引用其他软件包中的目标;该
在这种情况下,必须始终指定代码库标识符和软件包名称。
例如,如果源代码树同时包含软件包 my/app
和软件包 my/app/testdata
(这两个目录各有自己的 BUILD
文件),则后者软件包包含一个名为 testdepot.zip
的文件。在这里
引用该文件的方式有两种(一种错误,一种正确)
//my/app:BUILD
:
错误 - testdata
是另一个软件包,因此您无法使用相对路径
testdata/testdepot.zip
正确 - 请参阅 testdata
的完整路径
//my/app/testdata:testdepot.zip
以 @@//
开头的标签是对主代码库的引用,即使从外部代码库引用,也仍然有效。因此,@@//a/b/c
不同于
//a/b/c
(在从外部代码库引用时)。
前者会返回主代码库,而后者会在外部代码库本身中查找 //a/b/c
。当在主仓库中编写引用主仓库中目标的规则时,这一点尤为重要,并且这些规则将从外部仓库中使用。
如需了解引用目标的不同方式,请参阅目标模式。
标签的词法规范
标签语法不建议使用对 shell。这有助于避免无意中引用问题,并使 构建用于操控标签的工具和脚本,如 Bazel 查询语言。
下面列出了允许的目标名称的确切详细信息。
目标名称 - package-name:target-name
target-name
是软件包中目标的名称。规则的名称是 BUILD
文件中规则声明中的 name
属性的值;文件的名称是相对于包含 BUILD
文件的目录的路径名。
目标名称必须完全由从 a
- z
字符集中提取的字符组成,
A
–Z
、0
–9
和标点符号 !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
。
文件名必须是正常形式的相对路径名,这意味着它们必须
开头和结尾都不是正斜杠(例如 /foo
和 foo/
是
也不允许包含多个连续斜杠作为路径分隔符
(例如 foo//bar
)。同样,上层引用 (..
) 和
禁止使用当前目录引用 (./
)。
错误 - 请勿使用 `..` 来引用其他软件包中的文件
正确 - 使用“//package-name:filename”
虽然在文件目标的名称中使用 /
很常见,但请避免使用
/
。尤其是在使用标签的简写形式时,可能会让读者感到困惑。标签 //foo/bar/wiz
始终是 //foo/bar/wiz:wiz
的简写形式,即使没有此类软件包 foo/bar/wiz
;它绝不会引用 //foo:bar/wiz
,即使该目标存在也是如此。
不过,在某些情况下,使用斜线会很方便,有时甚至是必要的。例如,某些规则的名称必须与其主要源文件(可能位于软件包的子目录中)相匹配。
软件包名称 - //package-name:target-name
软件包的名称是相对于包含该软件包的代码库的顶级目录的包含其 BUILD
文件的目录的名称。例如:my/app
。
软件包名称必须完全由 A
-Z
、a
-z
、0
-9
、'/
'、'-
'、'.
'、'@
' 和 '_
' 集合中的字符组成,并且不能以斜线开头。
对于目录结构对其模块系统至关重要的语言(例如 Java),请务必选择在该语言中有效的标识符目录名称。
虽然 Bazel 支持工作区的根软件包(例如 //:foo
)中的目标,但最好将该软件包留空,以便所有有意义的软件包都有描述性名称。
软件包名称不得包含子字符串 //
,也不能以斜杠结尾。
规则
规则指定了输入和输出之间的关系, 构建输出的步骤。规则可以是多种不同类型(有时称为规则类)中的一种,它们会生成编译后的可执行文件和库、测试可执行文件以及其他受支持的输出,如构建百科全书中所述。
BUILD
文件通过调用规则来声明目标。
在下面的示例中,我们会看到使用 cc_binary
规则声明目标 my_app
。
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
每个规则调用都有一个 name
属性(必须是有效的
<目标名称>),用于在软件包中声明目标
(位于 BUILD
文件内)。
每条规则都有一组属性;为指定的 而每个属性的重要性和语义都是 规则的类型请参阅构建百科全书 规则及其相应属性的列表。每个属性都有一个名称和一个类型。属性的一些常见类型有:整数、标签、列表 标签列表、字符串、字符串列表、输出标签、输出标签列表。并非每条规则都需要指定所有属性。因此,属性会形成一个字典,其中键(名称)对应于可选的类型化值。
许多规则中的 srcs
属性的类型为“标签列表”;其
值(如果存在)是一个标签列表,每个标签都是要
为该规则输入值
在某些情况下,规则类型的名称有点任意性,更有趣的是规则生成的文件的名称,genrule 就是如此。如需了解详情,请参阅常规规则:genrule。
在其他情况下,名称很重要:例如,对于 *_binary
和 *_test
规则,规则名称决定了 build 生成的可执行文件的名称。
此目标有向非循环图称为目标图或构建依赖项图,是 Bazel 查询工具操作的领域。
目标 | build 文件 |