Bazel Configurability 2019 Roadmap
Last verified: 2019-01-28 (update history)
Point of contact: gregestren
Discuss: Configurability roadmap: discussion
$ bazel build :all just works, for whatever platform(s) you build for.
- Targets “know” how to build themselves. For example, an
android_binary automatically chooses the right SDK.
- Builds don’t require command-line flags.
- Any target can be built with any other. For example, a binary’s Mac and Linux versions can be built in the same command.
- Dependencies can build differently than their parents. For example, a test builds helper binaries without debug symbols.
- All rule logic and related flags are user-defined. Nothing requires a Bazel release.
- Builds can target any platform or any mix of platforms. Nothing requires a Bazel release.
- These features scale well for large builds.
Dates are approximate based on our best understanding of problem complexity
and developer availability. ETAs will change, but we’ll keep them refreshed and
Also see the Platforms Roadmap for detailed priorities.
Jun 2019C++ rules fully support
IN PROGRESS (#6516)
- This gives them first-class Starlark support,
and configuration via
- These set best practice templates for adding platform and toolchain support to other rules
Jun 2019Java rules fully support
IN PROGRESS (#6521)
- A second major rule set adopts this API
Jun 2019There’s one standard way to select platforms
at the command line
see status (#6518)
$ bazel build //a:myrule --platforms=@bazel_tools/platforms:mac
--apple_crosstool_top, etc. are deprecated
Jun 2019Legacy flags like
--cpu automatically set
--platform while the former are removed
NOT STARTED (#6426)
- This prevents
--cpu, and legacy command lines from breaking as rules adopt platforms
- Rules can leverage the benefits of platforms without having to wait on migration
late 2019Flagless multiplatform builds
NOT STARTED (#6519)
$ cat a/BUILD
cc_binary(name = "app_for_linux", platforms = ["//platforms:linux"])
cc_binary(name = "app_for_mac", platforms = ["//platforms:mac"])
$ bazel build //a:all # No command line flags!
- Unoptimized means memory and performance issues may not be resolved
late 2019All supported Bazel rules fully support
User-Defined Build Settings
See Starlark Build Configuration for in-depth motivation and design.
Mar 2019Starlark supports custom configuration transitions
IN PROGRESS (#5574)
- Rule designers can have rules change their flags or their dependencies’ flags
- This may have memory and performance consequences
Apr 2019Starlark supports fancy transitions
IN PROGRESS (#5574)
- Transitions can read a rule’s attributes to determine what to change
- Transitions on a rule can read attributes with
Apr 2019Starlark supports user-defined build settings
IN PROGRESS (#5577)
Apr 2019All native Bazel rules can be implemented
IN PROGRESS (#5578)
- This automatically comes out of user-defined build settings and custom transitions
Memory and Performance
Mar 2019Documentation explains how to use
configuration transitions efficiently
NOT STARTED (#6525)
- Explains why builds may use more memory and take more time
- Explains how to minimize these risks and make informed use of these features
- Points to tools for profiling your build
- Explains ongoing work to automatically improve efficiency
May 2019An experimental Bazel mode automatically
shrinks build graphs
IN PROGRESS (#6524)
- No rule builds twice when unrelated flags change
- Building the Mac and Linux versions of a binary at the same time doesn’t double the build graph
Jul 2019An experimental Bazel mode makes identical actions unique
NOT STARTED (#6526)
- Stops different actions from writing to the same path and overwriting each other’s output
- Improves multiplatform build time and remoe execution caching
- Makes pure Java compilation cacehable across different CPUs.
late 2019Bazel automatically shrinks graphs with
mixed build settings
NOT STARTED (#6524)
- Productionizes experimental build graph shrinking
late 2019Projects can selectively opt into automatic shareable actions
NOT STARTED (#6526)
- Exposes the benefits of experimental unique actions while recognizing complete migration may take time