单个或多个bazel WORKSPACE应该用于整体回购吗? [英] Single or multiple bazel WORKSPACE should be used for monolithic repo?

问题描述

我们将所有产品和库放在一个整体的git存储库中.其布局如下所示:

We put all products and libraries in one monolithic git repository. Its layout looks like this:

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

目前，我们正在使用 CMake 来控制构建.由于 CMake 分开了配置，生成和构建阶段，因此，如果一起生成所有内容，则将花费非常长的时间.为了避免这种情况，我们为每个部分提供顶级的 CMakeLists.txt ，并通过上级的 add_subirectory 调用引用对等项目.例如:

At current, we are using CMake to control the build. As CMake has separated config, generate and build phase, it would take extremely long time to run if you generate all things together. To avoid this, we give top-level CMakeLists.txt for each part, and referring peer projects by up-level add_subirectory calls. For example:

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

现在我们正在评估 Bazel ，我立即想到一个问题:我应该只在git repo的顶部目录中放置一个 WORKSPACE 吗?

Now we are evaluating Bazel, and I immediately got the question: should I only place one single WORKSPACE at top dir of the git repo?

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

还是在每个产品/库中放置许多 WORKSPACE 文件，并使用 local_repository 规则互相引用?

Or put many WORKSPACE files in each product/library and referring each other using local_repository rule?

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

推荐答案

按定义，单个工作空间或源/构建树只有一个(顶层) WORKSPACE .从理论上讲，您可以放置​​树的 WORKSPACE 分支，但是一个明显的混乱根源是，当从另一个 WORKSPACE 所在的目录运行bazel时，您无法达到项目目标 cwd 和项目根目录之间的路径.虽然您实际上不会获得任何回报.

Single workspace or source/build tree by definition only has one (top-level) WORKSPACE. In theory you could place WORKSPACE branches of your tree, but one obvious source of confusion would be, you could not reach project targets when running bazel from directories where another WORKSPACE is along the path between cwd and project root. While you would not really be gaining anything in return.

如果您想在多个目录(甚至子模块)中分配配置，则可以添加具有定义相应存储库规则目标(外部依赖项)的宏(函数")的Starlark( .bzl )文件.)在树中的任何位置(例如//3rd_party/...)，然后在(项目) WORKSPACE 文件中加载并执行相应的相应定义.

If you wanted to distribute your configuration across multiple directories (or even submodules), you can add Starlark (.bzl) files with macros ("functions") defining corresponding repository rule targets (external dependencies) anywhere in your tree (such as //3rd_party/...) and load and execute corresponding corresponding definitions in your (project) WORKSPACE file.

但这更多的是组织问题(例如，不同的人/小组保持不同的依赖关系；或者只是保持文件较小)，有效地工作(最终被评估)，就像拥有一个大的 WORKSPACE 文件.

But that would be more of an organizational matter (e.g. different people/groups maintaining different dependencies; or just keeping files small), effectively it works (is ultimately evaluated) just like having one big WORKSPACE file.

如果将外部依赖项称为源和 BUILD 描述.它是从完全不同的回购中拉出还是位于同一棵树中，这真的无关紧要.无论哪种方式，都需要对其进行重建，但也需要对其进行缓存.

If the external dependency is referred to as a source and BUILD description. It really does not matter whether it was pulled from entirely different repo or sits in the same tree. It needs to be rebuild, but also gets cached, either way.

这篇关于单个或多个bazel WORKSPACE应该用于整体回购吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！