gradle - Bazel 和 Gradle 有什么区别？

Question

谷歌只是 open-sourced它的构建工具 Bazel .这个工具和Gradle有什么区别？ ?它可以做什么 Gradle 不能做的事情，它在哪些方面做得更好，以及 Gradle 在哪些方面做得更好？

Answer 1

免责声明:我在 Bazel 上工作，我对 Gradle 并不十分熟悉。但是，我的一位同事对这两个系统进行了比较，我将在此处对其进行解释:

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

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

细微之处在于 Gradle 想要推广良好的实践，而 Bazel 想要要求它。 Gradle 的目标是在 Ant 体验(自由定义您自己的项目结构与不一致的结果)和 Maven 体验(强制执行的最佳实践，没有空间满足不同的项目需求)之间的中间地带。 Bazel 认为，在不牺牲支持其强大工作流程的强有力保证的情况下，灵活的项目支持是可能的。

这两种哲学都不是更“正确”——最适合项目的工具取决于该特定项目的值(value)观。

Gradle 概览

Gradle 是一个高度灵活的系统，它使用户可以轻松构建完整、可靠的构建流程，同时对他们如何组织项目的限制最小。它通过提供强大的构建块(例如自动依赖跟踪和检索、紧密集成的插件支持)和一个通用的、图灵完备的脚本接口(interface)来实现这一点，该接口(interface)可以根据用户的需要组合这些块。

Gradle 强调以下特点:

从其他系统轻松迁移。 Gradle 可以轻松适应任何项目组织，以轻松实现任意工作流结构。它原生地理解 Ant 任务，并原生地与 Maven 和 Ivy 存储库集成。

高度可扩展的脚本模型。用户通过编写 Groovy 脚本来实现所有构建逻辑。 “构建”只是通用任务的依存顺序执行，这些任务本质上是开放式的、可覆盖的、可扩展的方法定义。

丰富的依赖管理。可以从外部代码存储库、本地文件系统和其他 Gradle 项目中声明和自动暂存版本依赖项。构建输出同样可以自动发布到存储库和其他位置。

紧密集成的插件系统。插件只是为促进所需工作流程而组织的任务包。 Gradle 的许多“核心”功能实际上是通过插件(例如 Java、Android)实现的。插件(由他们自行决定)与构建脚本逻辑紧密交互。插件可以深入访问 Gradle 的核心数据结构。

巴泽尔概述

Bazel 的发展源于可靠、高效地构建 Google 内部项目的需要。由于 Google 的开发环境异常庞大且复杂，因此 Bazel 为其构建的完整性提供了异常强大的保证，并在实现这些构建时提供了异常低的性能开销。

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

Bazel 强调了以下特点:

正确性。 Bazel 构建旨在始终产生正确的输出，周期。如果两个用户在不同机器上使用相同的 Bazel 标志在同一提交中调用相同的构建，他们将看到相同的结果。增量构建与干净构建一样可靠，因此后者基本上是不必要的。

性能。考虑到可用的资源，构建旨在尽可能快地执行。任务在它们的依赖链允许的情况下是可并行化的。永远不会执行不必​​要的工作(即始终跳过“最新”任务)。工作可以自然地分配给远程执行者以克服本地机器限制。

再现性。任何构建实例都可以在任何环境中忠实再现。例如，如果错误报告说软件 Y 的版本 X 在生产环境 Z 中失败，开发人员可以在自己的机器上忠实地重新创建它，并确信他们正在调试相同的东西。