工作区、软件包和目标

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。
报告问题 查看源代码

Bazel 会根据在称为工作区的目录树中组织的源代码构建软件。工作区中的源文件会整理为嵌套的软件包层次结构,其中每个软件包都是一个目录,其中包含一组相关的源文件和一个 BUILD 文件。BUILD 文件指定可以从源代码构建哪些软件输出。

工作区

工作区是文件系统上的目录树,其中包含要构建的软件的源文件。每个工作区都有一个名为 WORKSPACE 的文本文件,该配置文件可能为空,也可能包含对构建输出所需的外部依赖项的引用。

包含名为 WORKSPACE 的文件的目录被视为工作区的根目录。因此,Bazel 会忽略位于包含 WORKSPACE 文件的子目录中的工作区中的任何目录树,因为它们形成了另一个工作区。

Bazel 还支持将 WORKSPACE.bazel 文件用作 WORKSPACE 文件的别名。如果两个文件都存在,系统会使用 WORKSPACE.bazel

代码库

代码在代码库中整理。包含 WORKSPACE 文件的目录是主代码库(也称为 @)的根目录。其他(外部)代码库使用工作区规则在 WORKSPACE 文件中定义。

如需了解与 Bazel 捆绑的工作区规则,请参阅构建百科全书工作区规则部分以及有关嵌入式 Starlark 代码库规则的文档。

由于外部代码库本身是代码库,因此它们通常还包含 WORKSPACE 文件。但是,Bazel 会忽略这些额外的 WORKSPACE 文件。特别是,间接依赖的代码库不会自动添加。

软件包

代码库中的代码组织单元是软件包。软件包是相关文件的集合,详细说明了它们可用于生成输出工件的方式。

软件包定义为包含名为 BUILD(或 BUILD.bazel)的文件的目录。软件包包含该目录中的所有文件,以及其下的所有子目录(自身包含 BUILD 文件的子目录除外)。根据此定义,任何文件或目录都不能是两个不同的软件包的一部分。

例如,以下目录树中有两个软件包:my/app 和子软件包 my/app/tests。请注意,my/app/data 不是软件包,而是属于 my/app 的目录。

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

目标

软件包是目标容器,在软件包的 BUILD 文件中定义。大多数目标都是两个主要种类(文件规则)之一。

文件可进一步分为两种。源文件通常由人员编写,并且会签入代码库。生成的文件(有时称为派生文件或输出文件)不会签入,但由源文件生成。

第二类目标使用规则进行声明。每个规则实例都指定一组输入和一组输出文件之间的关系。规则的输入可以是源文件,也可以是其他规则的输出。

在大多数情况下,规则输入是源文件还是生成的文件并不重要;重要的是该文件的内容。这使得将复杂的源文件替换为规则生成的文件变得容易,例如,手动维护高度结构化文件的负担变得太麻烦时,并且有人编写程序来派生该文件。该文件的使用方无需进行更改。相反,生成的文件可能会被仅具有本地更改的源文件轻松替换。

规则的输入也可能包含其他规则。这种关系的精确含义通常非常复杂,并且依赖于语言或规则,但从直观上看,这很简单:C++ 库规则 A 可能具有针对输入的另一个 C++ 库规则 B。这种依赖项的影响在于,B 的头文件在编译期间可供 A 使用,B 的符号在链接期间可供 A 使用,并且 B 的运行时数据在执行期间可供 A 使用。

所有规则的不变之处在于,规则生成的文件始终与该规则本身属于同一软件包;不可能生成其他软件包的文件。但是,规则的输入来自其他软件包的情况并不少见。

软件包组是旨在限制某些规则可访问性的软件包。软件包组由 package_group 函数定义。它们有三个属性:它们包含的软件包列表、它们的名称以及它们包含的其他软件包组。只能引用这些规则的 visibility 属性或 package 函数的 default_visibility 属性;它们不会生成或使用文件。如需了解详情,请参阅 package_group 文档

标签