工作区、软件包和目标

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

工作区

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

包含名为 WORKSPACE 的文件的目录被视为工作区的根。因此,当一个目录基于包含 WORKSPACE 文件的子目录时,Bazel 将在该工作区中忽略任何目录树,因为在它们构成另一个工作区时。

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

代码库

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

与 Bazel 捆绑的工作区规则记录在工作区规则部分(位于构建百科全书以及有关嵌入式 Starlark 代码库规则中披露政府所要求信息的数量和类型。

由于外部代码库本身是代码库,因此它们通常还包含 WORKSPACE 文件。不过,这些额外的 WORKSPACE 文件会被 Bazel 忽略。具体来说,依赖于传递性的代码库不会自动添加。

包裹

代码库中的代码组织的主要单元是软件包。 软件包是相关文件的集合,以及有关如何使用这些文件生成输出工件的规范。

软件包定义为包含名为 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。{ 101}这种依赖项的影响是,在编译期间,B 的头文件可供 A 使用;在关联期间,B 的符号可提供给 A;在执行期间,B 的运行时数据将可供 A 使用。

所有规则的不变的是,规则生成的文件与规则本身始终属于同一软件包;无法将文件生成到其他软件包中。然而,规则的输入来自其他软件包的情况并不少见。

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

标签