Bazel和Gradle之间有什么区别？

谷歌只是它的构建工具。这个工具和其他工具有什么区别？什么是Gradle做不到的，什么是Gradle做得更好，什么是Gradle做得更好？

免责声明：我在Bazel工作，我对Gradle不太熟悉。然而，我的一位同事写了一份两种系统的比较报告，我将在这里进行解释：

Bazel和Gradle强调构建体验的不同方面。在某种程度上，它们的优先级是不相容的——Gradle对灵活性和非突兀性的渴望限制了它对构建结构的限制，而Bazel对可靠性和性能的渴望必然会强制实施不可协商的限制

Gradle重视Bazel所重视的原则，即Gradle团队非常重视性能（增量构建、并行配置和执行、Gradle守护进程）、正确性（基于内容的“最新”检查）和再现性（对声明性语法、依赖项版本控制和显式声明的依赖项的丰富支持）。Bazel尊重灵活项目布局的需要

细微差别在于Gradle希望推广良好实践，而Bazel希望这样做。Gradle的目标是在Ant体验（自由定义自己的项目结构，结果不连贯）和Maven体验（强制执行最佳实践，没有满足不同项目需求的余地）之间找到一个中间点.Bazel认为，灵活的项目支持是可能的，而不会牺牲支持其强大工作流的强大保证

这两种理念都不是“正确的”——无论哪种工具最适合一个项目，都取决于该项目的价值观

格雷德尔概述 Gradle是一个高度灵活的系统，用户可以轻松构建完整、可靠的构建流程，对项目的组织方式限制最小。它通过提供强大的构建块（例如自动依赖项跟踪和检索、紧密集成的插件支持）来实现这一点具有通用的、图灵完整的脚本接口，可以根据用户的需要组合这些块

Gradle强调了以下特点：

• 易于从其他系统迁移。Gradle可以轻松适应任何项目组织，轻松实现任意工作流结构。它本机理解Ant任务，并与Maven和Ivy存储库集成
• 高度可扩展的脚本模型。用户通过编写Groovy脚本来实现所有构建逻辑。“构建”只是对一般任务的依赖顺序执行，基本上是开放的、可重写的、可扩展的方法定义
• 丰富的依赖关系管理。版本化的依赖关系可以从外部代码存储库、本地文件系统和其他Gradle项目声明和自动暂存。构建输出同样可以自动发布到存储库和其他位置
• 紧密集成的插件系统。插件是简单的任务包，用于组织所需的工作流程。Gradle的许多“核心”功能实际上是通过插件（例如Java、Android）实现的。插件交互（自行决定）与构建脚本逻辑紧密结合。插件可以深入访问Gradle的核心数据结构

巴泽尔概述 Bazel的发展源于可靠高效地构建谷歌内部项目的需要。由于谷歌的开发环境异常庞大和复杂，Bazel为构建的完整性提供了异常强大的保证，并在实现这些构建时提供了异常低的性能开销

这为围绕可复制构建的强大开发工作流提供了基础，其中“构建”成为可被引用、重复、传递到不同机器的抽象实体，并传递给任意程序和服务，使得每个实例都知道完全相同。

Bazel强调以下特点：

• 正确性。Bazel构建旨在始终生成正确的输出，句号。如果两个用户在不同的计算机上使用相同的Bazel标志在相同的提交时调用相同的构建，他们将看到相同的结果。增量构建与干净构建一样可靠地正确，因此后者基本上是不必要的
• 性能。考虑到可用的资源，构建被设计为以尽可能快的速度执行。任务在其依赖链允许的范围内尽可能并行。不必要的工作永远不会执行（即始终跳过“最新”任务）。工作自然可以外包给远程执行者，以克服本地机器的限制
• 可再现性。构建的任何实例都可以在任何环境中忠实地再现。例如，如果错误报告说软件Y的X版本在生产环境Z中失败，开发人员可以在自己的机器上忠实地再现，并确信他们正在调试同一件事

---

随着文章链接逐渐消失，以下是对以下内容的总结（大部分内容直接摘自2015年3月发表的文章）：

它被设计用来解决谷歌独有的一个问题：一个巨大的单片代码库（几亿LOC）

Bazel目前提供的并行化优势将与“我们即将推出的新配置和组件模型”相匹配（请记住本文日期）

Bazel没有一种高级的声明性构建语言，使构建易于开发人员使用。在谷歌，这可以通过拥有构建工具的专业服务团队来补偿

Bazel并不是为可扩展性而构建的（尽管Bazel开发团队保证他们正在开发可扩展性，以此来反驳这一点）

围绕所有可传递依赖项都存储在一个大型回购协议（即所有libr）中这一理念，对速度进行了优化