We've just released Bazel 0.21!
Before updating Bazel, you may try if anything would break with 0.21. To do so, build your code with Bazel 0.20 and the following flags:
For more information about the changes, please click on the links and read the GitHub issues. Comment there if you need help.
If you use external repositories, you might first have to update the dependencies in your WORKSPACE file.
Breaking changes in the next release (0.22) are marked with GitHub label breaking-change-0.22.
- We revamped our Android with Bazel tutorial. Check it out here.
--experimental_check_desugar_depsis enabled by default. This flag rules out several types of invalid Android builds at compile-time. Note that this is incompatible with remote Android builds, so you can disable it with
- Bazel now supports Android Databinding v2. It can be enabled with
XCRUNWRAPPER_LABELis removed. If you used this value before, please use @bazel_tools//tools/objc:xcrunwrapper instead.
--experimental_stlcommand line option is removed.
cppconfiguration fragment doesn't do package loading anymore. That means:
- You can now use Bazel without a C++ toolchain (as long as you don't build C++ rules).
- Bazel may start about 2 seconds faster than before, because it does not analyze C++ toolchain anymore when it is not needed.
--strict_java_depsare renamed to
--experimental_strict_java_deps. (The two flags used to do the same.)
- A new incompatible flag
--incompatible_strict_argument_orderingis added. This concerns a corner case in function calls. When this flag is enabled,
**kwarghave to be after all other arguments.
repository_ctx.download_and_extractnow return a struct, instead of
--genrule_strategyis deprecated in favor of
--strategy=Genrule=<strategy>(for genrules) or
--spawn_strategy=<strategy>(for all actions).
- Dynamic execution is now available with
--experimental_spawn_scheduler. Dynamic execution allows a build action to run locally and remotely simultaneously, and Bazel picks the fastest action. This provides the best of both worlds: faster clean builds than pure local builds, and faster incremental builds than pure remote builds.
- Our documentation is now versioned. You can see the documentation for a specific Bazel version. This is especially useful when a flag or a feature is removed.
defaults to human readable output format, use
--output=prototo get the result in proto format..
- The deprecated and unmaintained Docker rules in
tools/build_defs/dockerare removed. Please use
- A new incompatible flag
--incompatible_merge_genfiles_directoryis added. When enabled, Bazel does not create a
bazel-genfilesdirectory, and writes everything to
- When build options change, Bazel discards the analysis cache. The changed
options are now printed in the output. It is possible to control the number
of options to show using
--experimental_remote_grpc_lognow also logs updateActionResult. This is the Remote Execution API call used in remote caching, so now remote caching can be debugged using the grpc log.
- The deprecated flavors of
git_repository(), etc. no longer respect the
HTTPS_PROXYenvironment variables. Support for this was removed to prevent interference with GRPC, causing remote builds to fail. The non-deprecated flavors of these functions should work as intended.
- Natan Silnitsky talked about Wix's lessons learned for successful migration to Bazel and Google Cloud Build to build their Scala codebase.
- David Stanke also did a talk: Build and test your code faster with Bazel, the cloud-accelerated build system.
- Philipp Wollermann created Bazelisk, a wrapper for Bazel that automatically picks a good version of Bazel given your current working directory.
- John Millikin started new rules for the GNU m4 macro processor, the Flex scanner generator, and the GNU Bison parser generator.
This release contains contributions from many people at Google, as well as Andy Scott, Attila Oláh, Benjamin Peterson, Clint Harrison, Dave Lee, Ed Schouten, Gregor Jasny, Jamie Snape, Jerry Marino, Loo Rong Jie, Or Shachar, Sevki Hasirci, and William Chargin.
Thanks to everyone who contributed!
Discuss on HackerNews.