1

我们将所有产品和库放在一个单一的 git 存储库中。它的布局如下所示：

- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
 |- fftw
 |- msgpack
 |- zlib

目前，我们正在使用CMake来控制构建。由于CMake将 config、generate 和 build 阶段分开，如果您将所有内容一起生成，将需要非常长时间才能运行。为避免这种情况，我们为每个部分提供顶层，并通过上层调用CMakeLists.txt引用对等项目。add_subirectory例如：

# FooProduct/CMakeLists.txt
project(FooProduct)
add_subdirectory(../BazLibrary sibling/BazLibrary)
add_subdirectory(../3rd_party/zlib sibling/3rd_party/zlib)
......

现在我们正在评估BazelWORKSPACE ，我立即得到了一个问题：我应该只在 git repo 的顶级目录中放置一个吗？

- WORKSPACE
- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
 |- fftw
 |- msgpack
 |- zlib

或者在每个产品/库中放置许多文件并使用规则WORKSPACE相互引用？local_repository

- FooProduct
 |- WORKSPACE
- BarProduct
 |- WORKSPACE
- BazLibrary
 |- WORKSPACE
- 3rd_party
 |- fftw
   |- WORKSPACE
 |- msgpack
   |- WORKSPACE
 |- zlib
   |- WORKSPACE
4

1 回答 1

1

根据定义，单个工作区或源/构建树只有一个（顶级）WORKSPACE。从理论上讲，您可以放置WORKSPACE​​树的分支，但一个明显的混淆来源是，当从目录运行 bazel 时，您无法到达项目目标，而另一个目录位于项目根目录WORKSPACE之间的路径上。cwd虽然您不会真正获得任何回报。

如果您想跨多个目录（甚至子模块）分发配置，您可以添加 Starlark ( .bzl) 文件，其中包含定义相应存储库规则目标（外部依赖项）的宏（“函数”）在树中的任何位置（例如//3rd_party/...）并加载和在您的（项目）WORKSPACE文件中执行相应的相应定义。

但这更像是一个组织问题（例如，不同的人/组维护不同的依赖关系；或者只是保持文件小），它有效地工作（最终评估）就像拥有一个大WORKSPACE文件一样。

如果外部依赖被称为来源和BUILD描述。它是从完全不同的 repo 中提取还是位于同一棵树上并不重要。无论哪种方式，它都需要重建，但也需要缓存。

于 2020-01-28T13:37:30.817 回答