如果 A 在构建时需要 B，则目标 A 依赖于目标 B；或
执行时间。depends upon 关系会在目标上诱导出有向无环图 (DAG)，称为依赖关系图。
目标的直接依赖项是指依赖项图中长度为 1 的路径可到达的其他目标。目标的传递依赖项包括 通过图表上任意长度的路径所依赖的目标。
事实上，在 build 上下文中，有两个依赖项图，一个是实际依赖项图，另一个是声明的依赖项图。大多数情况下，这两个图表非常相似，因此无需进行这种区分，但对于下面的讨论，这种区分很有用。
实际依赖项和声明的依赖项
如果必须存在、构建并保持最新的 Y，才能正确构建 X，则目标 X 实际上依赖于目标 Y。已构建可以是指生成、处理、编译、关联、归档、压缩、执行或构建期间常规发生的任何其他类型的任务。
目标 X 声明了对目标 Y 的依赖性（如果存在依赖项）
X 软件包中从 X 到 Y 的边缘。
为了构建正确的 build，实际依赖项 A 的图必须是声明的依赖项 D 的子图。也就是说，
A 中直接连接的节点 x --> y 也必须直接连接到
D。可以说，D 是对 A 的过度近似。
BUILD 文件写入器必须向构建系统明确声明每个规则的所有实际直接依赖项，且不得超出此范围。
不遵守此原则会导致未定义的行为：构建可能会失败， 但更糟糕的是，构建可能依赖于之前的某些操作， 目标所声明的依赖项Bazel 会检查是否缺少依赖项并报告错误，但在所有情况下都无法完成此检查。
您无需（也不应）尝试列出间接导入的所有内容，
即使 A 在执行时需要它也是如此。
在构建目标 X 期间，构建工具会检查 X 依赖项的整个传递闭包，以确保这些目标中的任何更改都会反映在最终结果中，并根据需要重新构建中间文件。
依赖项的传递性质会导致一个常见错误。有时，一个文件中的代码可能会使用间接依赖项提供的代码，即声明的依赖关系图中传递但非直接的边。间接依赖项不会显示在 BUILD 文件中。由于规则不直接依赖于提供程序，因此无法跟踪更改，如以下示例时间轴所示：
1. 声明的依赖项与实际依赖项匹配
最初，一切正常。a 软件包中的代码使用 b 软件包中的代码。软件包 b 中的代码使用 c 软件包中的代码，因此以传递 a 方式
依赖于 c。
a/BUILD |
b/BUILD |
|---|---|
rule(
name = "a",
srcs = "a.in",
deps = "//b:b",
)
|
rule(
name = "b",
srcs = "b.in",
deps = "//c:c",
)
|
a / a.in |
b / b.in |
import b;
b.foo();
|
import c;
function foo() {
c.bar();
}
|
|
|
声明的依赖项优先于实际依赖项。一切正常。
2. 添加未声明的依赖项
如果有人向 a 添加了会对 c 创建直接实际依赖项的代码，但忘记在 build 文件 a/BUILD 中声明该依赖项，就会引入潜在的隐患。
a / a.in |
|
|---|---|
import b;
import c;
b.foo();
c.garply();
|
|
|
|
|
声明的依赖项不再过于近似于实际依赖项。这样可能没问题，因为两个图的传递闭包相等，
但掩盖了问题：a 实际对 c 有未声明的依赖项。
3. 声明的依赖项图与实际依赖项图之间存在差异
当有人重构 b 以使其不再依赖于它时，就会发现危害
c，无意中将 a 突破了 no
自己的过错。
b/BUILD |
|
|---|---|
rule(
name = "b",
srcs = "b.in",
deps = "//d:d",
)
|
|
b / b.in |
|
import d;
function foo() {
d.baz();
}
|
|
|
|
声明的依赖关系图现在是实际 和以传递方式关闭的依赖项；构建可能会失败
通过确保
已在 BUILD 文件中正确声明第 2 步中引入的 a 到 c。
依赖项类型
大多数构建规则都有三个属性，用于指定不同类型的
通用依赖项：srcs、deps 和 data。具体如下所述。如需了解详情，请参阅所有规则共有的属性。
许多规则还有适用于特定规则类型的
依赖项，例如 compiler 或 resources。如需了解详情，请参阅构建百科全书。
srcs 依赖项
输出源文件的规则直接使用的文件。
deps 依赖项
指向单独编译的模块的规则，用于提供头文件、符号、库、数据等
data 个依赖项
build 目标可能需要一些数据文件才能正常运行。这些数据文件 不是源代码：它们不会影响目标的构建方式。例如，单元测试可能会将函数的输出与文件的内容进行比较。当您 构建单元测试时，您不需要此文件，但在运行 测试。这同样适用于在执行期间启动的工具。
构建系统在一个隔离的目录中运行测试，该目录下仅列出了
data 可用。因此，如果二进制文件/库/测试需要运行一些文件，
请在 data 中指定这些变量（或包含这些变量的构建规则）。例如：
# I need a config file from a directory named env:
java_binary(
name = "setenv",
...
data = [":env/default_env.txt"],
)
# I need test data from another directory
sh_test(
name = "regtest",
srcs = ["regtest.sh"],
data = [
"//data:file1.txt",
"//data:file2.txt",
...
],
)
您可以使用相对路径 path/to/data/file 访问这些文件。在测试中，您可以通过连接测试的源目录路径和相对于工作区的路径（例如 ${TEST_SRCDIR}/workspace/path/to/data/file）来引用这些文件。
使用标签引用目录
查看 BUILD 文件时，您可能会注意到某些 data 标签会引用目录。这些标签以 /. 或 / 结尾，如以下示例所示：
不应使用：
不建议 -
data = ["//data/regression:unittest/."]
不建议 -
data = ["testdata/."]
不建议 -
data = ["testdata/"]
这似乎很方便，尤其是对于测试，因为它允许测试使用目录中的所有数据文件。
但尽量不要这样做。为了确保更改后正确进行增量重新构建（以及重新执行测试），构建系统必须知道构建（或测试）的输入文件的完整集。如果您指定
则只有在该目录本身存在的情况下，
（由于添加或删除文件），但无法检测
可以修改个别文件，因为这些更改不会影响封闭目录。
您应枚举目录中包含的一组文件，而不是将目录指定为构建系统的输入，可以明确枚举，也可以使用 glob() 函数枚举。（使用 ** 强制 glob() 进行递归。）
推荐 - data = glob(["testdata/**"])
遗憾的是，在某些情况下，必须使用目录标签。
例如，如果 testdata 目录包含名称不符合标签语法的文件，则对文件进行显式枚举或使用 glob() 函数会导致标签无效错误。在这种情况下，您必须使用目录标签，
出现上述错误重新构建的相关风险。
如果您必须使用目录标签，请注意，您不能使用相对 ../ 路径引用父级软件包；而应使用 //data/regression:unittest/. 等绝对路径。
任何需要使用多个文件的外部规则（例如测试）都必须明确声明其对所有这些文件的依赖项。您可以使用 filegroup() 在 BUILD 文件中将文件分组：
filegroup(
name = 'my_data',
srcs = glob(['my_unittest_data/*'])
)
然后，您可以在测试中引用 my_data 标签作为数据依赖关系。
| BUILD 文件 | 公开范围 |