Monorepo 与多个连接的 Bazel 工作区 - 是否有任何“陷阱”需要考虑？

Question

我在一个正在向 Monorepo (C/C++) 发展的组织工作。简而言之：我们正在考虑在这个 Monorepo 中使用 local_repository 建立几个连接的 Bazel 工作区。这与将原始组件连接到一个大工作区形成对比。如果有人有这方面的实践经验，或者知道最初的设计意图是什么，那对我们将非常有帮助。

这样做的主要动机是开发人员的幸福感。我们在 C++ 中已经有很长的路径包含语句、Bazel 标签等，我没有找到创建“模块”的好方法，我们可以将这些路径减少为相对于模块根目录而不是存储库根目录。在网上看，我没有找到任何将他们的存储库分成几个工作区的例子，所以我觉得有充分的理由避免它。

是否建议不要有多个与原始组件对应的工作区？如果是这样，为什么？我做了一个概念验证，表明构建工作得很好，但我可以想象自动完成、查询和其他一些功能在工作区边界上不能很好地工作。

正如我所说，我在网上找到的信息很少。有Single or multiple bazel WORKSPACE should be used for monolithic repo?，但接受的答案掩盖了拥有多个工作区的优势，并没有详细说明为什么这样做是个坏主意。

Answer 1

我假设您只打算在一个“顶级”WORKSPACE 中支持构建。否则，您必须复制所有依赖项（或将它们放在每个都使用的大宏中），并且它们每个都有自己的输出根（包括动作缓存）。

我看到的最大的开发人员不友好问题是bazel build（和其他命令）在目录树上查找他们找到的第一个 WORKSPACE。这类似于git 查找 .git 文件夹的方式。这意味着当它发现“错误的”工作空间时，从错误的目录运行 bazel 命令会产生奇怪的错误。您可以通过使所有其他 WORKSPACE 文件看起来像这样来缓解这种情况：

fail("Do not build from this directory, try the root folder instead.")

至少这是一个明显的错误，但在运行构建之前必须cd 仍然很烦人。

您是否考虑过为所有规则执行includes = ["."]，并且只在模块根目录中创建 BUILD 文件？这应该可以让您按照您描述的方式执行包含路径，同时将它们全部保存在同一个工作区中。