Bazel 基于源代码构建软件，这些源代码以目录树的形式组织，称为
工作区。工作区中的源文件以嵌套层次结构的形式进行整理，
包中，每个包都是一个目录，其中包含一组相关的
一个源文件和一个 BUILD 文件。BUILD 文件用于指定
可以在源代码的基础上构建输出
工作区
工作区是文件系统上包含源代码的目录树
为您要构建的软件提供文件。每个工作区都有一个名为
WORKSPACE，可能为空，或可能包含对 external
构建输出所需的依赖项。
包含 WORKSPACE 文件的目录被视为
工作区。因此，Bazel 会忽略根目录在
包含 WORKSPACE 文件的子目录，因为它们会形成另一个工作区。
Bazel 还支持将 WORKSPACE.bazel 文件用作 WORKSPACE 文件的别名。如果
两个文件都存在，系统会使用 WORKSPACE.bazel。
代码库
代码整理到各个代码库中。包含 WORKSPACE 的目录
文件是主代码库（也称为 @）的根目录。其他（外部）
使用工作区规则在 WORKSPACE 文件中定义代码库，或者
通过 Bzlmod 系统中的模块和扩展程序生成的。请参阅外部
依赖项概览。
与 Bazel 捆绑的工作区规则记录在工作区 规则部分构建 百科全书以及有关嵌入式 Starlark 代码库规则。
由于外部代码库本身就是代码库，因此它们通常包含
WORKSPACE 文件。不过，这些额外的 WORKSPACE 文件
会被 Bazel 忽略特别是，以传递方式依赖的仓库
自动添加。
软件包
代码库中代码组织的主要单元是软件包。答 package 是相关文件的集合以及有关如何使用它们的 用于生成输出工件。
包是指包含
名为 BUILD 或 BUILD.bazel 的 BUILD 文件。答
package 包含其目录中的所有文件及其下的所有子目录，
本身包含 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 因此在执行期间 A 将可以使用 B 的运行时数据。
所有规则都有一个不变的原则是，规则生成的文件始终属于 与规则本身相同的软件包；无法将文件生成为 另一个软件包。规则的输入来自另一个规则，这种情况很常见。 还是“软件包”
软件包组是一组软件包，其目的是限制
特定规则软件包组由 package_group 函数定义。他们
具有三个属性：其所含软件包的列表、名称以及其他
它们包含的软件包组。引用这些变量的唯一方式是
规则的 visibility 属性，或来自以下规则的 default_visibility 属性：
package 函数；而不会生成或使用文件有关
信息，请参阅 package_group
文档。
<ph type="x-smartling-placeholder"></ph> 标签