Bazel, the build and test tool that is dervied from Google's internal build tool "Blaze", recently released version 2.0. This release introduces several flagged changes that will be incompatible with previous versions of the tool. Version 2.0 also includes a number of other stability and performance improvements.
Bazel is an open-source build tool built to handle projects with large codebases, multiple compiled languages, and extensive tests. It leverages both local and distributed caching, coupled with dependency analysis, in order to rebuild only the portions of the build that are affected by the current changeset. Bazel is also designed to be capable of running parallel, distributed builds in order to minimize build time. InfoQ previously published a detailed article discussing Bazel and its features.
This announcement follows shortly on the release of version 1.0, back in October. With the 1.0 release came the promise of greater stability and backward compatibility guarantees. This major release also follows on the commitment to follow semantic versioning for future releases, and does potentially contain breaking changes.
The flag --incompatible_remap_main_repo is now enabled by default, causing both methods of addressing the main repository (by name and by @) to be interpreted as referring to the same repository. This change will affect the evaluation of labels within the repo. For example within the repo foo, the labels @foo//some/path:lib and //some/path:lib are now the same label.
The native maven_jar rule is now no longer available as the flag --incompatible_remove_native_maven_jar is now enabled by default and the flag has been removed. The team has provided an automated migration tool to assist in updating the workspace files appropriately. Updating the files manually is also possible. For example, Given a WORKSPACE file that looks like the following:
maven_jar(
name = "truth",
artifact = "com.google.truth:truth:0.30",
sha1 = "9d591b5a66eda81f0b88cf1c748ab8853d99b18b",
)
It will need to look like this after updating:
load("@bazel_tools//tools/build_defs/repo:jvm.bzl", "jvm_maven_import_external")
jvm_maven_import_external(
name = "truth",
artifact = "com.google.truth:truth:0.30",
artifact_sha256 = "59721f0805e223d84b90677887d9ff567dc534d7c502ca903c0c2b17f05c116a",
server_urls = ["http://central.maven.org/maven2"],
licenses = ["notice"], # Apache 2.0
)
Note that the licenses attribute is now mandatory. For the hash, only SHA256 is supported. If your maven_jar targets did not previously specify a server_urls value, then you should use the default server http://central.maven.org/maven2.
Additional changes include the deprecation of support for aapt in favor of using aapt2 by default. The flag --incompatible_disallow_lookup_unhashable_keys is now enabled by default, causing dict key lookups via in or dict.get to fail on unhashable types. As well, package loading now fails consistently if there is a glob eval that encounters either a symlink cycle or a symlink infinite expansion.
The team is looking to deprecate runfiles manifest files in an upcoming release. They note that these are not safe in the presence of whitespace, and require local CPU even when remote execution is used. The experimental flag --experimental_skip_runfiles_manifests can be enabled to test out the initial work towards this change, but they note that the exact semantics are still subject to change.
Developer sentiment about the release is predominantly positive, although many commented on their challenges in implementing Bazel within their projects. Some commenters on Hacker News expressed frustration with integrating Bazel into their pre-existing projects. User habitue commented that, "if you're a small shop, the benefits Bazel is going to provide over, say, make (or whatever standard build system your primary language uses), are going to be minimal."
However, user malkia felt that the investment was worth it, as the benefits of more efficient builds coupled with the requirement for creation of the dependency graph outweigh the cost of adopting this "opinionated" tool. User klodoph was also positive and shared that "With Bazel, I have much higher confidence that I’ll get consistent results when I checkout the repository on different computers, or work with other people."
Bazel is available to download for macOS, Ubuntu, Fedora/CentOS, and Windows. BazelCon 2019 was hosted this past December and the recordings from the conference presentations are now available.