依赖项

如果 A 在构建或执行时需要 B，则目标 A 依赖于目标 B。 “依赖于”关系会在目标上生成 有向无环图 (DAG)，称为依赖关系图。

目标的直接依赖项 是指在依赖关系图中长度为 1 的路径可到达的其他目标。目标的传递依赖项 是指通过图中任意长度的路径依赖的目标。

实际上，在构建上下文中，存在两个依赖关系图：实际依赖关系图 和声明的依赖关系图 。大多数情况下，这两个图非常相似，因此无需进行这种区分，但对于下面的讨论很有用。

实际依赖项和声明的依赖项

如果 Y 必须存在、已构建且为最新状态，X 才能正确构建，则目标 X 实际上依赖于目标 Y 。构建 可能意味着生成、处理、编译、链接、归档、压缩、执行或构建期间经常发生的任何其他类型的任务。

如果 X 的软件包中存在从 X 到 Y 的依赖关系边，则目标 X 具有对目标 Y 的声明的依赖项 。

为了正确构建，实际依赖关系图 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 的直接实际依赖项 __，但忘记在构建文件 a/BUILD 中声明该依赖项时，就会引入潜在的风险。

a / a.in
import b; import c; b.foo(); c.garply();

声明的依赖项不再过近似于实际依赖项。 这可能会构建成功，因为两个图的传递闭包相等， 但会掩盖一个问题：a 具有对 c 的实际依赖项，但未声明。

3. 声明的依赖关系图与实际依赖关系图之间的差异

当有人重构 b，使其不再依赖于 c 时，风险就会显现出来，从而无意中破坏了 a，而这并非他们自己的错。

	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 依赖项

构建目标可能需要一些数据文件才能正确运行。这些数据文件不是源代码：它们不会影响目标的构建方式。例如，单元测试可能会将函数的输出与文件的内容进行比较。构建单元测试时，您不需要该文件，但在运行测试时需要该文件。在执行期间启动的工具也是如此。

构建系统在隔离的目录中运行测试，其中仅提供列为 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 引用为数据依赖项。