Bazel Blog

Bazel 0.27

By Laurent Le Brun on 17 June 2019

Bazel 0.27 has just been released.

With Bazel 0.27, we start a 3 month stability window. Bazel 0.28 and Bazel 0.29 will be backward compatible with Bazel 0.27. See our announcement about Bazel Stability and Semantic Versioning. This release contains more incompatible changes than usual, as we try to fix the important issues before Bazel 1.0.

Incompatible changes

Bazel 0.27 Linux release binaries have been built on Ubuntu 16.04 (before: Ubuntu 14.04, which is now EOL). This change will probably break compatibility with older Linux distributions like Ubuntu 14.04. If this causes you problems, please open an issue and let us know.

Before updating to Bazel 0.27, first check if your codebase is compatible either by running bazelisk --migrate or by building your code with Bazel 0.26 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.

Android

  • Introduced the --incompatible_disable_native_android_rules flag. This flag facilitates the migration of the Android native rules to Starlark. For more information, see Android Native to Starlark Migration.
  • Android desugaring actions now use persistent workers by default. This has been measured to provide up to 20% reduction in build times. To disable it, use the --strategy=Desugar=sandboxed flag. See Bazel issue 8342 and Bazel issue 8427 for more details on local build speed optimization for Android apps.
  • Fixed an issue with Android builds where --fat_apk_cpu doesn't pack all selected shared libraries from aar_import targets into the APK. See Bazel issue 8283.
  • Added support for Android NDK 19 and 20.
  • Optimized build times further by 10% by trimming unused build actions. See Bazel issue 8340 for more details.

Apple platforms

  • BAZEL_USE_XCODE_TOOLCHAIN=1 tells Bazel not to look for Xcode to decide whether to enable toolchains for Apple rules, but to assume Xcode is available. It can be also used when building on Darwin and no C++ or ObjC is being built, so there is no need to detect Xcode.

C++

  • Added a generic additional_linker_inputs attribute on cc_binary rules.
  • Windows, C++ autoconfigure: BAZEL_VC and BAZEL_VS can now use quotes. If you set these envvars' values in cmd.exe via TAB-completion, you no longer need to remove the surrounding quotes.
  • cc_import() of a DLL with no interface library on Windows is now allowed. This is used to document runtime dependencies.
  • Repository containing autoconfigured C++ toolchain @local_config_cc has been split. See local_config_cc_toolchains.
  • Added new option --cs_fdo_absolute_path= to support the absolute path profile for LLVM's context-sensitive FDO.

Python

  • Python rules now find the Python runtime using toolchains, rather than the --python_top and --python_path flags, which are deprecated. See the migration issue for more information on declaring Python toolchains and migrating your code.
  • As a side-benefit of enabling toolchains, Bazel now enforces that Python targets execute under the same version of Python that was determined in the analysis phase (fixing #4815), on all platforms besides Windows. This means that builds may start to fail with Python 2 vs 3 errors, if they previously relied on getting the "wrong" Python version. To fix this, make sure that any target containing PY2-only code has the attribute python_version = "PY2". Furthermore, if your (or your dependencies') host-configured tools use Python 2, add --host_force_python=PY2 to your bazelrc to tell Bazel about this requirement.
  • When a py_binary built for the host configuration fails, it will now emit a warning on stderr suggesting to check whether --host_force_python=PY2 needs to be set.
  • For users who do not have both a Python 2 and Python 3 runtime installed, there is now a non-strict Python toolchain that launches whatever python command it finds on PATH without caring about its version. Effectively this opts back into the buggy behavior of #4815. Pass --extra_toolchains=@bazel_tools//tools/python:autodetecting_toolchain_nonstrict to use it.

Configurations

Remote Execution

  • The flag --incompatible_list_based_execution_strategy_selection has been flipped. Users of remote execution no longer need to specify --spawn_strategy=remote, --strategy=Javac=remote, --strategy=Closure=remote, --strategy=Genrule=remote. See a Blog post or Bazel issue 7480.
  • The flag --remote_local_fallback_strategy has been deprecated. Setting it is no longer be necessary as Bazel now automates selects the best strategy. See Bazel issue 7480.
  • The flag --tls_enabled has been deprecated and will be removed once --incompatible_tls_enabled_removed will be flipped. Instead, enable TLS directly via the URI passed to --remote_executor, --remote_cache and --bes_backend. See Bazel issue 8061 for details.
  • The new flag --remote_retries has been introduced to tune the number of times RPCs should be retried by Bazel. Setting --remote_retries=0 will disable retries. The flags --experimental_remote_retry_* have been deprecated and made a no-op.

Other changes

  • The copy-pasted init code of the Bash runfiles library is now shorter. See comments in tools/bash/runfiles/runfiles.bash. To use the new init code, you need Bazel 0.27 or newer. The old init code still works.
  • pkg_deb has new attributes: config and templates that can be used for integration with debconf.

Community

This release contains contributions from many people at Google, as well as Alex Thompson, Andy Scott, Benjamin Peterson, David McNett, Drew Gassaway, James deBoer, Jay Vercellone, Josh Rosen, Keith Smiley, Lee Mracek, Marwan Tammam, Matt Passell, Michael Hackner, Michal Majcherski, Patrick Niklaus, Peter Mounce, Ricky Pai, Steeve Morin, szakmary, Takuto Ikuta, Vladimir Chebotarev, and Yen-Chi Chen.