工作区、软件包和目标

<ph type="x-smartling-placeholder"></ph> 报告问题 查看来源 敬上 每晚 · 7.3。 · 7.2 条 · 7.1。 · 7.0。 · 6.5

Bazel 基于源代码构建软件,这些源代码以名为 一个工作区。工作区中的源文件被整理在一个嵌套层中, 软件包层次结构,其中每个软件包都是一个目录,其中包含一组 一组相关源文件和一个 BUILD 文件。BUILD 文件指定 可以在源代码的基础上构建软件输出

工作区

工作区是文件系统上包含源代码的目录树 为您要构建的软件提供文件。每个工作区都有一个名为 WORKSPACE,可能为空,或可能包含对 构建输出所需的外部依赖项

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

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 文件。大多数目标都属于以下两种主要类型之一:文件和规则

文件进一步分为两种类型。源文件通常 编写出来的,并签入代码库。 生成的文件(有时称为派生文件或输出文件); 不会签入,而是从源文件生成的。

第二种目标使用规则进行声明。每条规则 实例指定了一组输入和一组 输出文件。规则的输入可以是源文件,但也可以是 可能是其他规则的输出

规则输入是源文件还是生成的文件 多数情况下是无实质意义的;重要的是 文件。这样,您就可以轻松地将复杂的源文件替换为 根据规则生成的文件 与手动维护高度结构化的文件相比, 于是有人编写了程序来派生它。无变化 所需内容相反, 文件可以轻而易举地替换为 更改。

规则的输入可能还包括“其他规则”。通过 这种关系的确切含义通常相当复杂, 取决于语言或规则,但直观上很简单: 库规则 A 可能具有另一个 C++ 库规则 B 作为输入。 此依赖项的作用是,将 B 的头文件 可以在编译期间对 A 使用,而 B 的符号可供 A 使用 因此在关联期间,A 将能够使用 B 的运行时数据 执行。

所有规则都有不变性,即规则生成的文件 始终与规则本身同属一个包;不是 将文件生成到另一个软件包中。这并不罕见 规则的输入会来自其他软件包

软件包组是指旨在限制无障碍功能的一系列软件包 特定规则软件包组由 package_group 函数定义。 它们具有三个属性:其中包含的软件包列表、名称以及 其中包含的其他软件包组引用这些变量的唯一方式包括 来自规则的 visibility 属性或来自 default_visibility package 函数的属性;而不会生成或使用文件 如需了解详情,请参阅 package_group 文档

标签