kristina 2018/3/31

https://stackoverflow.com/questions/29245787/what-are-the-differences-between-bazel-and-gradle

Disclaimer: I work on Bazel and I'm not intimately familiar with Gradle. However, one of my coworkers wrote up a comparison of the two systems, which I will paraphrase here:

Bazel and Gradle emphasize different aspects of the build experience. To some extent, their priorities are incompatible - Gradle’s desire for flexibility and non-obtrusiveness limits the restrictions it can place on build structure, while Bazel's desire for reliability and performance necessarily enforces non-negotiable restrictions.

Gradle does value the same principles that Bazel does, i.e. the Gradle team pays great attention to performance (incremental builds, parallelized configuration and execution, the Gradle daemon), correctness (content-based “up-to-date” checking), and reproducibility (rich support for declarative syntax, dependency versioning, explicitly declared dependencies). And Bazel respects the need for flexible project layouts.

The nuance is that Gradle wants to promote good practice while Bazel wants to require it. Gradle aims for a middle ground between the Ant experience (freedom to define your own project structure with incoherent results) and the Maven experience (enforced best practices with no room for varying project needs). Bazel believes that flexible project support is possible without sacrificing the strong guarantees that enable its powerful workflows.

Neither philosophy is more “correct” - whichever tool best suits a project depends on that particular project’s values.

Gradle Overview

Gradle is a highly flexible system that makes it easy for users to construct complete, reliable build flows with minimal constraints on how they organize their projects. It does this by supplying powerful building blocks (e.g. automatic dependency tracking and retrieval, tightly integrated plugin support) with a generic, Turing-complete, scripting interface that can combine these blocks however the users wants.

Gradle emphasizes the following features:

Easy migration from other systems. Gradle easily accommodates any project organization to easily implement arbitrary workflow structures. It natively understands Ant tasks, and natively integrates with Maven and Ivy repositories.
Highly extensible scripting model. Users implement all build logic by writing Groovy scripts. A “build” is simply a dependency-sequenced execution of generic tasks, which are essentially open-ended, overridable, extensible method definitions.
Rich dependency management. Versioned dependencies can be declared and automatically staged from external code repositories, local filesystems, and other Gradle projects. Build outputs can likewise be auto-published to repositories and other locations.
Tightly integrated plugin system. Plugins are simply bundles of tasks organized to facilitate a desired workflow. Many of Gradle’s "core" features are actually implemented through plugins (e.g. Java, Android). Plugins interact (at their discretion) tightly with build script logic. Plugins enjoy deep access to Gradle’s core data structures.

Bazel Overview

Bazel evolved out of the need to build internal Google projects reliably and efficiently. Because Google’s development environment is unusually large and complex, Bazel offers unusually strong guarantees about the integrity of its builds and unusually low performance overhead in achieving them.

This provides a foundation for powerful development workflows built around reproducible builds, where a “build” becomes an abstract entity that can be referenced, repeated, passed around to different machines, and passed to arbitrary programs and services such that every instance is known to be exactly the same.

Bazel emphasizes the following features:

Correctness. Bazel builds are designed to always produce correct output, period. If two users invoke the same build at the same commit with the same Bazel flags on different machines, they will see identical results. Incremental builds are as reliably correct as clean builds, rendering the latter essentially unnecessary.
Performance. Builds are designed to execute as fast as intrinsically possible given the resources available to them. Tasks are as parallelizable as their dependency chains allow. Unnecessary work is never executed (i.e. “up-to-date” tasks are always skipped). Work can naturally be farmed out to remote executors to overcome local machine limits.
Reproducibility. Any instance of a build can be faithfully reproduced in any environment. For example, if a bug report says version X of software Y fails in production environment Z, a developer can faithfully recreate it on their own machine with confidence that they’re debugging the same thing.