I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:
Experimental Bazel Support
Some of these samples can be built with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.
This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.
- What is the added advantage of using Bazel over the existing Gradle?
- Is it really good to have TWO build tools for Android?
- Does it mean that Android developers will probably need to learn this new build tool in future?
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files:
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
you don’t like how it works, you can write your own. Want to use a
custom compiler? A custom static checker? A custom test harness? No
problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
There is a similar level of functionality between these two build formats, and it becomes apparent that the two systems are made with different philosophies. Bazel provides a structured system that is easy to reason about and provides a strong, functional foundation for large and growing products. Gradle, on the other hand, offers a flexible, stateful, object-oriented interface that may feel familiar to those who don’t frequently use scripting languages.