标签的第二部分是不合格的软件包名称 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 目标。

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

相对标签不能用于引用其他软件包中的目标；在这种情况下，必须始终指定代码库标识符和软件包名称。例如，如果源树同时包含软件包 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 是软件包中目标的名称。规则的名称是规则声明中 name 属性的值，该声明位于 BUILD 文件中；文件的名称是其相对于包含 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 规则，规则名称决定了构建生成的可执行文件的名称。

这种针对目标的有向无环图称为 目标图 或 构建依赖关系图，是 Bazel 查询工具运行的领域。

目标

BUILD 文件

标签 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

标签的词法规范

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

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

规则

标签

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

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