Bazel Build：Bazel是一把双刃剑

Bazel是一个支持多语言、跨平台的构建工具。Bazel支持任意大小的构建目标，并支持跨多个仓库的构建，是Google主推的一种构建工具。

优势

Bazel存在如下方面的优势。

• 易理解：Bazel对外提供声明式表达的构建DSL，可读性好，降低了构建系统的实现复杂度；
• 速度快：得益于Bazel优异的编译缓存和依赖分析技术，更好地支持并行和增量编译，甚至增量测试；
• 跨平台：一套构建系统，支持多平台，异构系统的构建；
• 可扩展：使用类Python语言(Starlark)扩展规则，支持多语言构建；
• 大规模：支持100k+源文件规模的构建，支持多仓的依赖管理；
• 云构建：天然地支持云构建，复用既有的计算资源。

举个例子，使用Bazel，工程中如果需要自动生成Protobuf代码，配置CUDA编程环境，管理多仓代码的依赖等，Bazel相对具有明显的优势。

劣势

但是，Bazel也存在一些与生俱来的缺陷。

Bazel运行于JRE

也就是说，安装Bazel需要额外安装JRE，即使Bazel二进制包内嵌了一个最小化的JRE；此外，Bazel启动速度迟钝，内存消耗很厉害。

业界存在其他构建工具，例如Scons，它使用Python。但是，在几乎所有的Unix开发环境中，Python是预装的，这给开发者减少了很大麻烦。

所以，Native风格的构建工具具有很大的竞争优势。一方面，安装极简，用户心智负担不大；另一方面，用户不需要额外安装依赖，整个工具链的安装是完备的、闭包的。

Bazel与Unix社区文化存在冲突

在Unix社区，开发者已然非常熟悉./configure, make, make install的构建工作流，及其相关的工具链。而且，开发者一致遵循FHS(文件系统层次标准)的约定。

但是，Bazel改变了Unix一贯的风格和文化，与社区文化产生了剧烈的矛盾。如果你使用Bazel发布一个库，对不起，你的用户也得用Bazel，才能引用到你的库。Bazel不支持类似于bazel install命令，你的用户只能使用Bazel，然后创建新的规则去依赖你的库。使用Bazel，你强奸了你的用户群。

反过来，如果Bazel要想依赖于一个非Bazel的库，得做适配才能使用，用户不能复用既有存在的CMake或Make的构建系统。众所周知，有的构建系统异常复杂，适配过程并非易事，你得对库的架构，依赖关系把握非常准确才行。Bazel开发团队也没有提供相关工具链，翻译既有存在构建脚本，这个过程留待给用户自行解决。

总结起来，Bazel到Make，不支持；从Make到Bazel，得出血；从Bazel到Bazel，零成本，但可能招致用户的强制性。这对社区文化是一种伤害，这也是Bazel最大的硬伤。如果没有背后有钱的老爹Google，估计Bazel早死了。

这可能与Bazel的定位和架构有关系，大家也不能骂爹骂娘骂Google傻逼。Bazel定位在于支持多语言，而不仅仅只包括C/C++，C/C++的一些惯用法和工具链，在其他语言可能不成立。

此外，/usr/include, /usr/lib是系统目录。如果你存在两个工程，分别依赖于相同的、当版本不同的库。它们都安装到系统目录，必然存在版本冲突。幸运的是，容器时代这个问题得到了缓解。相反地，在每个Bazel项目中，将其依赖控制在自己的工作区(Workspace)内，避免了类似的版本冲突问题。

另外，Bazel的霸道，也复合Google一贯高傲的风格。通过Bazel的黏性，Google在多语言多语言编程领域，尤其在云构建领域，正在积极构建强大的生态系统和技术壁垒。

Bazel的生态系统不够成熟

在C/C++领域，CMake，Make占据主流。Bazel作为后起之秀，能否在生态中站稳脚跟，还得靠时间证明。此外，上文提及Bazel与社区文化存在冲突和矛盾，Bazel的生态建设还是不够乐观。

目前，整个Bazel的生态，基本由TensorFlow社区挑大梁。但是，TensorFlow的最佳实践，也很难在社区中得到有效的传播和复制。而且，TensorFlow在实践Bazel也遇到了一些挑战，包括复杂度(构建脚本代码行，及其依赖的复杂度)。

一方面，TensorFlow的系统架构和实现存在固有的复杂度；因为TensorFlow是多语言、异构的系统实现，常见的工程的构建过程不见得拥有TensorFlow那么复杂，而且大部分公司的工程也不见得拥有Google的复杂度。在Google玩得转的技术实践，在其他公司并不一定有效。

另一方面，抢占既有存在的生态系统，本身门槛极高。犹如在Java领域，个人认为Gradle比Maven优秀，但Gradle的生态依然没有Maven健全和完善。从社区活跃度看，目前只有Google相关的项目在推进Bazel，其他项目几乎没什么动静，由此可见一斑。

Monorepo并非是万能的

Bazel的架构思维是Monorepo哲学的技术延伸。但是，Monorepo是否有效，要取决于公司的文化，团队协助方式，项目特点等众多因素，在日常的项目中，并非一定是灵丹妙药。采用Monorepo组织项目，Git库变得越来越大，甚至对IDE也提出了挑战；更有甚者，Monorepo往往导致模块之间的依赖隐式化，不能得到及时的显性暴露，增加了系统架构的耦合度。