所有目标都只能属于一个软件包。目标的名称称为其标签。每个标签唯一地标识一个目标。规范形式的标签如下所示：
@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 目标。
不过，在 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 查询工具在哪个网域上运行。
| 目标 | 构建文件 |