为什么google bazel构建工具流行不起来

y35w 6年前

作者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操作系统。