Bazel和Gradle有什么区别?

Google只是开源他们的构build工具Bazel 。 这个工具和Gradle有什么区别? Gradle不能做什么,它有什么更好的做法,Gradle做得更好?

免责声明:我在巴泽尔工作,我不熟悉Gradle。 然而,我的一位同事写了一个两个系统的比较,我将在这里解释一下:

Bazel和Gradle强调了构build体验的不同方面。 在一定程度上,它们的优先级是不相容的 – Gradle对灵活性和非侵入性的期望限制了它可以对构build结构施加的限制,而Bazel对可靠性和性能的期望必然会强制不可协商的限制。

Gradle确实重视Bazel所遵循的原则,即Gradle团队非常重视性能(增量构build,并行configuration和执行,Gradle守护进程),正确性(基于内容的“最新”检查)和可重复性(对声明性语法,依赖版本化,显式声明的依赖性的丰富支持)。 而Bazel尊重灵活的项目布局的需要。

不同的是,Gradle希望在Bazel要求的时候促进良好的实践。 Gradle的目标是在Ant体验(自由定义自己的项目结构和不一致的结果)和Maven体验(强制执行的最佳实践,没有空间满足不同的项目需求)之间的中间地带。 巴泽尔认为,灵活的项目支持是可能的,而不会牺牲强大的保证,使其强大的工作stream程。

两种哲学都不是“正确的” – 最适合一个项目的工具取决于这个特定项目的价值。

Gradle概述

Gradle是一个高度灵活的系统,使用户可以方便地构build完整,可靠的构buildstream程,并且对组织项目的方式进行限制。 它通过提供function强大的构build块(例如自动依赖关系跟踪和检索,紧密集成的插件支持)和通用的图灵完成脚本界面来完成这一任务,而这些界面可以结合用户需要的这些块。

Gradle强调以下function:

  • 从其他系统轻松迁移。 Gradle可轻松容纳任何项目组织,轻松实现任意工作stream程结构。 它原生理解Ant任务,并与Maven和Ivy存储库本地集成。
  • 高度可扩展的脚本模型。 用户通过编写Groovy脚本来实现所有构build逻辑。 一个“构build”就是generics任务的依赖性顺序执行,它们本质上是开放式的,可重复的,可扩展的方法定义。
  • 丰富的依赖pipe理。 可以从外部代码存储库,本地文件系统和其他Gradle项目声明和自动分阶段执行版本化的依赖关系。 构build输出也可以自动发布到存储库和其他位置。
  • 紧密集成的插件系统。 插件只是简单的任务组合,以促进所需的工作stream程。 Gradle的许多“核心”特性实际上是通过插件(例如Java,Android)实现的。 插件与构build脚本逻辑紧密交互(自行决定)。 插件可以深入访问Gradle的核心数据结构。

巴泽尔概况

Bazel从需要可靠高效地构build内部Google项目演变而来。 由于Google的开发环境exception庞大而复杂,Bazel对其构build的完整性以及exception低的性能开销提供了非常有力的保证。

这为基于可重复构build的强大开发工作stream提供了基础,“构build”成为一个抽象实体,可以被引用,重复,传递到不同的机器,并传递到任意程序和服务,使得每个实例都被认为是一模一样。

巴泽尔强调以下特点:

  • 正确性。 巴泽尔build立的目的是始终产生正确的产出,时期。 如果两个用户在不同的机器上使用相同的Bazel标志调用相同的构build,他们将看到相同的结果。 增量构build与清理构build一样可靠,使后者基本上不必要。
  • 性能。 构build被devise为在给定可用资源的情况下以尽可能快的速度执行。 任务与其依赖链所允许的一样可并行化。 不必要的工作永远不会执行(即“最新”任务总是被跳过)。 自然可以将工作交给远程执行者来克服本地机器的限制。
  • 重复性。 任何构build的实例都可以在任何环境中忠实地再现。 例如,如果一个错误报告显示软件Y的X版在生产环境Z中出现故障,开发人员可以在自己的机器上忠实地重新创build软件,并确信他们正在debugging同样的事情。

由于文章链接往往死亡,这里是Gradle团队对Bazel的看法的总结(大部分直接从2015年3月发布的文章中解除):

它旨在解决Google独有的问题; 一个庞大的单一代码库(数以百万计的LOC)。

Bazel目前提供的并行优势将与“我们即将推出的新configuration和组件模型”相匹配(请记住这里的文章date)。

Bazel没有一个高级声明性的构build语言,使开发人员易于使用的构build。 在Google,这可以由拥有构build工具的专业服务团队来弥补。

Bazel不是为可扩展性而构build的(尽pipeBazel开发团队已经对此做出反驳,并保证他们正在开发可扩展性)。

速度是围绕这样的想法进行优化的,即所有的传递依赖都存储在一个大的回购中; 所有的库和工具都被签入到这个中央仓库。 大多数企业有更多的分布式依赖pipe理需求。

Bazel只是* nix,它不能在Windows上运行。 这消除了大量的潜在企业。

没有插件生态系统。