Open-Source Build and Test Tool Bazel Reaches 1.0

Derived from Google's internal build tool Blaze, Bazel is a build and test tool that offers a human-readable definition language and is particularly aimed at large, multi-language, multi-repositories projects. Originally open-sourced in 2015, Bazel has now reached 1.0.

One of the major implications of reaching version 1.0 for Bazel is the promise of greater stability and backward-compatibility guarantees. This has been a historical pain point for Bazel users, who often found themselves in the situation of having to rewrite part of their build rules due to frequent breaking changes in Bazel or its ecosystem. Accordingly, the Bazel team has committed to following semantic versioning for future Bazel releases, meaning only major versions will be allowed to include breaking changes. Furthermore, the team committed to maintaining a minimum stability window of three months between major versions.

Bazel strives to be efficient in determining out-of-date artifacts by using content digests instead of timestamps when creating its dependency graphs. This makes it possible to avoid unnecessarily re-building of targets, as well as to have predictable builds, even when distributed across multiple hosts whose clocks are not perfectly synchronized. Distributed builds are an intrisic feature of Bazel, which was created to build very large systems on a cloud infrastructure. Thanks to its use of content digests, Bazel is able to cache intermediate build step outputs and reuse them when necessary. Intermediate build artifacts can also be shared across teams.

Another peculiar feature of Bazel is hermeticity. What this means is Bazel builds are sandboxed and, if a build rule is not declared to depend on a given file, it will not be able to open that file, which rules out the possibility of hidden dependencies from the outside. This opens the door to many optimization possibilities, and enables reproducible builds.

From its inception, and contrary to most available build systems, which are usually tied to a specific language, Bazel is meant to be a multi-language build system. This is achieved by defining a number of language-specific rules for the kind of targets they can build, for example the cc_library and cc_binary rules for C/C++ targets; the java_binary and java_import for Java targets, and many more. All major languages are supported out of the box, but new rules can be easily added in case it is required.

The language used by Bazel to define new rules is called Starlark and is inspired by Python 3 syntax, although it does not include all of Python features. In particular, collection mutation or file I/O are not supported, mostly for the sake of preventing programmers from using such features to create artifacts that are not known beforehand to the build system and which would break Bazel dependency graph analysis.

The announcement of Bazel 1.0 was met with a positive reaction from several developers, who praised Bazel's performance and efficiency in comparison to other build tools such as Maven and Gradle. Particularly, the promise of backward-compatibility was considered by most developers an important step forward, allowing Bazel's third-party rule ecosystem to mature on a more stable basis.

Related Topics:

• Development
• DevOps
• Build systems
• Google
• Open Source

We protect your privacy.