如何看待 monorepo？

闲聊灌水
1

谷歌和 Meta 使用了这种模式，Bazel 和 Buck 是为了满足他们这一需求开发出来的。

Git/Hg 是否依旧是最适合 monorepo 的 SCM？（这点不太了解）

2

没有必要把 google 和 meta 当作圣经。他们能做 mono repo，维护性工作的成本也不是一般团队能够承受得起的。

谷歌写过文章专门介绍他们的 mono repo 是怎么工作的：

https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/

可以感受一下他们付出了多少基建上的努力。

而且 谷歌的 mono repo 也有很多非常特别的实践…比如基本上不使用分支功能，让新的 feature 的代码和旧的代码同时存在于当前版本库…再比如把所有第三方的代码都 copy 下来专门放到一个 third party 的目录底下

3 个赞
3

没有，主要是想试一试 Bazel/Buck。越来越感觉 CMake 不好用了，而 GNU Make 和 LSP 的配合不佳，没有 compilation database 的 builtin support，而 bear 也不好用，经常给我生成空的 JSON 文件 :frowning:

剩下的选项也就只有：

  • 谷歌的 Ninja（提供了 builtin 的 compilation database 生成功能，也有 Emacs 插件）

  • 谷歌的 GN（生成 ninja.build 的）

  • 谷歌的 Bazel

  • Meta 的 Buck2
  • xmake （我目前在试这个，感觉很有潜力，个人开发者能做到这种程度已经很厉害了）
4

还是用 xmake 吧，我最近两年都在用xmake，还蛮有心得的。很好用！

5

monorepo 很好，可以用 svn or 微软的 scaler，跟 git 兼容。

bazel 这类是封闭式构建，就是说所有依赖都自行存储，个人和小公司很难做到的，你用 xmake 就好。

6

CMake 和 xmake 要实践 monorepo 有一个坑：它俩对于 target name 都是全局的，不像 Bazel 那样是按照文件夹来划分作用域的（即只要同一个文件夹里的 target 不重名即可，不同文件夹里可以有同名的 target）。

7

cmake 和 xmake 都不是 monorepo 的工具

8

用xmake写过公司里一个项目的构建，挺好的