谷歌和 Meta 使用了这种模式，Bazel 和 Buck 是为了满足他们这一需求开发出来的。
Git/Hg 是否依旧是最适合 monorepo 的 SCM？（这点不太了解）
没有必要把 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 的目录底下
4 个赞
没有，主要是想试一试 Bazel/Buck。越来越感觉 CMake 不好用了，而 GNU Make 和 LSP 的配合不佳，没有 compilation database 的 builtin support，而 bear 也不好用，经常给我生成空的 JSON 文件 
剩下的选项也就只有：
- 谷歌的 Ninja（提供了 builtin 的 compilation database 生成功能，也有 Emacs 插件）
-
谷歌的 GN（生成 ninja.build 的）
-
谷歌的 Bazel
- Meta 的 Buck2
- xmake （我目前在试这个，感觉很有潜力，个人开发者能做到这种程度已经很厉害了）
还是用 xmake 吧，我最近两年都在用xmake，还蛮有心得的。很好用！
monorepo 很好，可以用 svn or 微软的 scaler，跟 git 兼容。
bazel 这类是封闭式构建，就是说所有依赖都自行存储，个人和小公司很难做到的，你用 xmake 就好。
CMake 和 xmake 要实践 monorepo 有一个坑：它俩对于 target name 都是全局的，不像 Bazel 那样是按照文件夹来划分作用域的（即只要同一个文件夹里的 target 不重名即可，不同文件夹里可以有同名的 target）。
cmake 和 xmake 都不是 monorepo 的工具
用xmake写过公司里一个项目的构建，挺好的
bazel 和 buck2 目前虽然 bazel 的讨论热度相对高一些，但我还是更喜欢 buck2。
因为 bazel 要在 windows 上用还需要 msys 而且貌似还必须把 msys 添加到 path 里且要把 msys 提供的 utils 都添加进去，这可能会污染环境变量，干扰 windows 自带的命令。而 buck2 只要求使用 clang，不需要 msys。
你就这么想，整个互联网就是个大 repo，那么你在 cmake 里所有依赖都 FetchContent，这不就是正常的 mono repo 么🫠
1 个赞
是的。mono repo 分两个层次，自己的代码放一起，第三方依赖也放一起，前者很好，后者不是一般公司能用的，用依赖锁定文件来折中就行了。
git 其实并不适合 mono repo，但现在太流行了，用微软的 scalar 能弥补下。 hg 也不适合，反倒是传统的 svn, perforce 更适合。
3 个赞
试了一下现在 Bazel 不需要 MSYS 也可以调用 MSVC 编译 C++ 项目了。
不过我遇到了另一个问题：bazel 不加 --batch 参数就会出现长时间连接不上 local server 的情况（本地编译）。不知道这个是 bug 还是新版本的特性。
Meta 出了一个自己的工具，不知道怎么样？
只开源了客户端，没服务端，目前只能用来跟 git repos 交互。
特点不够鲜明，工具还很原始，我挺怀疑能火起来。