作者Jack47

之前博主写了系列文章Google软件构建工具Bazel原理及使用方法介绍。最近使用了一段时间后，觉得这个东西不是一种通用的构建工具，很难对接到情况复杂的大的工程项目里。今天来讲讲为什么博主觉得google bazel构建工具不会大规模流行起来。本文是参考Gradle--另外一个很出名的构建工具--的人对bazel的看法的这篇文章基础上整理而成的

Google bazel想解决什么问题？

Bazel是Google内部构建系统Blaze的子集，所以Bazel想解决的最主要是Google所面临的独一无二[可能不完全是]的问题“：
这篇文章记录了Google面临的问题：

Google的代码库是非常巨大的（有数百万行代码），好处是公司内部都推行一套统一的开发风格。例如，对每种语言都有写好的风格规范，有一个多语言的构建系统来给所有的项目构建代码，源代码都在一个地方存放，一个统一的持续集成来运行所有的单测。软件工具开发者们可以访问并分析到所有的代码，每个人都使用相同的code reviews工具并使用同一套索引来搜索代码库

所有代码都在一个源代码仓库里，因此Google是世界上少数几个遇到这样大规模问题的公司，所以构建过程中的性能问题是最关键的需求，其他需求都是次要的，尤其是跟Google不相关的需求。可惜的是大部分公司都不是Google，有更广泛的需求。

bazel为什么不适合其他公司

大部分公司都不是Google的这种情况，不会有强大的构建团队来专门做软件构建相关的工具，也不会有Google那么好的开发文化，没有统一的构建工具，因此大项目想对接bazel，会遇到很多困难。

Google 内部软件构建系统已经开发了超过7年了，所以开发适合Google自己的构建工具是他们的初衷。Google构建工具跟其他工具相比，强调的是“更加结构化”，这样能够提高并发度，拥有更好的可重现性[reproducibility]。但这样对源代码的组织方式和头文件的书写规则，库之间依赖关系的书写要求就比较高：

1. 要求所有相关的源代码都以Bazel要求的组织形式来发布：
   
2. 要求所有代码的传递依赖都存储在一个代码仓库里
   
3. 所有的库和相关的工具都是提交到这个代码库里。

以上这几点是很难同时达到的，大部分公司管理依赖关系的方式都不尽相同。举个例子，在Linux下开发，很多包是rpm形式发布的，对于这种第三方的包，就很难实现Bazel的要求，不可能要求每个rpm包都提供Bazel的依赖描述文件：BUILD文件，而且在构建过程中，怎么把rpm文件组织到工程的源代码里面，也是一个头疼的问题。虽然有办法也可以做到，例如使用程序自动下载，解压rpm文件，然后生成BUILD文件，但是这当中会遇到很多一些问题。所以google的bazel这一套构建工具，需要公司里上下游的开发团队都用起来，才能发挥应有的效益。

另外一个原因是Bazel目前不支持Windows操作系统。