外部依赖项概览

Bazel 支持 外部依赖项,即构建中使用的源文件(文本和二进制文件),这些文件并非来自您的工作区。例如,它们可以是托管在 GitHub 代码库中的 规则集、Maven 工件,也可以是本地机器上当前工作区之外的 目录。

从 Bazel 6.0 开始,您可以通过两种方式使用 Bazel 管理外部依赖项: 传统的、以代码库为中心的 WORKSPACE 系统,以及 较新的、以模块为中心的 MODULE.bazel 系统(代号为 Bzlmod, 通过 --enable_bzlmod 标志启用)。这两个系统可以 一起使用,但 Bzlmod 将在未来的 Bazel 版本中取代 WORKSPACE 系统,请查看 Bzlmod 迁移指南,了解如何 迁移。

本文档将先介绍 Bazel 中与外部依赖项管理相关的概念 ,然后再详细介绍这两个系统。

概念

代码库

一个目录树,其根目录中有一个边界标记文件,其中包含可在 Bazel 构建中使用的源 文件。通常简称为代码库

代码库边界标记文件可以是 MODULE.bazel(表示此代码库 代表 Bazel 模块)、REPO.bazel(见下文),或者在 旧版上下文中,可以是 WORKSPACEWORKSPACE.bazel。任何代码库边界标记文件 都将表示代码库的边界;多个此类文件可以共存于一个 目录中。

主代码库

当前 Bazel 命令正在其中运行的代码库。

主代码库的根目录也称为 工作区根目录

工作区

在同一主代码库中运行的所有 Bazel 命令共享的环境。它 包含主代码库和所有已定义外部代码库的集合。

请注意,从历史上看,“代码库”和“工作区”这两个概念一直混为一谈 ;“工作区”一词通常用于指代主 代码库,有时甚至用作“代码库”的同义词。

规范代码库名称

代码库可寻址的规范名称。在工作区的上下文中,每个代码库都有一个规范名称。规范名称为 canonical_name 的代码库中的目标可通过标签 @@canonical_name//package:target(注意双 @)寻址。

主代码库的规范名称始终为空字符串。

显式代码库名称

在某个其他代码库的上下文中,代码库可寻址的名称。 这可以看作是代码库的“昵称”:规范名称为 michael的代码库在代码库 alice的上下文中可能具有显式名称mike,但在代码库 bob的上下文中可能具有显式名称mickey。在这种情况下,michael 中的目标可在 alice 的上下文中通过标签 @mike//package:target(注意单个 @)寻址。

相反,这可以理解为代码库映射:每个代码库 都维护从“显式代码库名称”到“规范代码库名称”的映射。

代码库规则

代码库定义的架构,用于告知 Bazel 如何实现代码库。例如,它可以是“从某个网址下载 zip 归档 并将其解压缩”,也可以是“提取某个 Maven 工件并使其作为 java_import 目标可用”,或者只是“符号链接本地目录”。每个代码库都是通过使用适当数量的实参调用代码库规则来 定义 的。

如需详细了解如何编写自己的代码库规则,请参阅代码库规则

到目前为止,最常见的代码库规则是 http_archive(用于从网址下载归档并将其解压缩)和 local_repository(用于符号链接已是 Bazel 代码库的本地目录)。

提取代码库

通过运行与代码库关联的 代码库规则,使代码库在本地磁盘上可用的操作。在提取之前,工作区中定义的代码库在本地磁盘上不可用 。

通常,Bazel 仅在需要代码库中的某些内容且尚未提取代码库时提取代码库, 并且尚未提取代码库。如果代码库之前已提取 ,Bazel 仅在其定义发生更改时重新提取。

fetch 命令可用于启动代码库、 目标或执行任何构建所需的所有代码库的预提取。此功能 支持使用 --nofetch 选项进行离线构建。

--fetch 选项用于管理网络访问权限。其默认值为 true。 但是,当设置为 false (--nofetch) 时,该命令将使用依赖项的任何缓存 版本,如果不存在任何缓存版本,该命令将导致 失败。

如需详细了解如何控制提取,请参阅提取选项

目录布局

提取后,可以在 输出库的子目录 external 中找到该代码库,其名称为规范名称。

您可以运行以下命令来查看规范名称为 canonical_name的代码库的内容:

ls $(bazel info output_base)/external/ canonical_name 

REPO.bazel 文件

REPO.bazel 文件用于标记构成代码库的目录树 的最顶层边界。它不需要包含任何内容即可作为代码库 边界文件;不过,它也可用于为代码库内的所有构建目标指定一些常见属性 。

REPO.bazel 文件的语法与 BUILD 文件类似,只不过不支持 load 语句,并且仅提供一个函数 repo()repo() 采用与 package() 函数BUILD 文件中的用法相同的实参;而 package() 用于为软件包内的所有构建目标指定常见属性,repo() 则类似地为代码库内的所有构建目标指定常见属性。

例如,您可以通过以下 REPO.bazel 文件为代码库中的所有目标指定通用许可:

repo(
    default_package_metadata = ["//:my_license"],
)

使用 Bzlmod 管理外部依赖项

Bzlmod 是新的外部依赖项子系统,不直接使用代码库 定义。相反,它会从 模块构建依赖关系图,在图上运行 扩展,并相应地定义代码库。

Bazel 模块 是一个 Bazel 项目,可以有多个 版本,每个版本都会发布有关其所依赖的其他模块的元数据 。模块必须在其代码库根目录中有一个 MODULE.bazel 文件,该文件位于 WORKSPACE 文件旁边。此文件是模块的清单,用于声明模块的名称、 版本、依赖项列表以及其他信息。以下是一个基本 示例:

module(name = "my-module", version = "1.0")

bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")

模块必须仅列出其直接依赖项,Bzlmod 会在 Bazel 注册表中查找这些依赖项 - 默认情况下,Bazel 中央 注册表。该注册表提供 依赖项的 MODULE.bazel 文件,这使得 Bazel 能够在执行版本解析之前发现整个 传递依赖关系图。

在版本解析(为每个模块选择一个版本)之后, Bazel 会再次查询注册表,以了解如何为每个模块定义代码库 (在大多数情况下,使用 http_archive)。

模块还可以指定称为标记的自定义数据片段,这些标记在模块解析后由模块扩展使用,以定义其他代码库。这些扩展具有与代码库 规则类似的功能,使它们能够执行文件 I/O 和发送网络 请求等操作。除其他事项外,它们还允许 Bazel 与其他软件包 管理系统进行交互,同时遵守由 Bazel 模块构建的依赖关系图。

使用 WORKSPACE 定义代码库

从历史上看,您可以通过在 WORKSPACE(或 WORKSPACE.bazel)文件中定义代码库来管理外部依赖项。此文件的语法与 BUILD文件类似,只不过它使用代码库规则而不是构建规则。

以下代码段是在 http_archive 代码库规则的 WORKSPACE 文件中使用示例:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "foo",
    urls = ["https://example.com/foo.zip"],
    sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)

该代码段定义了一个规范名称为 foo 的代码库。在 WORKSPACE 系统中,默认情况下,代码库的规范名称也是其对 所有其他代码库的显式名称。

请参阅 完整列表 的函数,这些函数在 WORKSPACE 文件中可用。

WORKSPACE 系统的缺点

WORKSPACE 系统推出以来,用户报告了 许多痛点,包括:

  • Bazel 不会评估任何依赖项的 WORKSPACE 文件,因此除了直接依赖项之外,所有 传递依赖项都必须在主 代码库的 WORKSPACE 文件中定义。
  • 为了解决此问题,项目采用了 "deps.bzl" 模式,在该模式中 它们定义了一个宏,该宏又定义了多个代码库,并要求用户 在其 WORKSPACE 文件中调用此宏。
    • 这有其自身的问题:宏无法 load 其他 .bzl 文件,因此 这些项目必须在此 “deps”宏中定义其传递依赖项,或者通过让用户调用多个 分层“deps”宏来解决此问题。
    • Bazel 会按顺序评估 WORKSPACE 文件。此外, 依赖项是使用 http_archive 指定的,带有网址,没有任何 版本信息。这意味着,在菱形依赖项(A 依赖于 BCBC 都依赖于不同版本的 D)的情况下,没有可靠的方法来执行 版本解析。

由于 WORKSPACE 的缺点,Bzlmod 将在未来的 Bazel 版本中取代旧版 WORKSPACE 系统。请阅读Bzlmod 迁移 指南,了解如何迁移到 Bzlmod。