此页面由 Cloud Translation API 翻译。

Switch to English

标签的第二部分是非限定软件包名称 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，因此它将 app 目标命名为当前代码库的 my/app 软件包中。

不过，在指定 package_group 或 .bzl 文件中时，建议使用 //my/app 来引用软件包，因为它清楚地表明软件包名称是绝对的且位于工作区的顶级目录中。

相对标签不能用于引用其他软件包中的目标；在本例中，必须始终指定代码库标识符和软件包名称。例如，如果源代码树同时包含软件包 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 查询工具运行的网域。

目标

构建文件

标签

标签的词法规范

目标名称 - package-name:target-name

软件包名称 - //package-name:target-name

规则

目标名称 - `package-name:target-name`

软件包名称 - `//package-name:target-name`