Contribute

Bazel Configurability 2019 Roadmap

Last verified: 2019-04-25 (update history)

Point of contact: gregestren

Discuss: Configurability roadmap: discussion

Previous

Goal

$ 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.

Roadmap

Dates are approximate based on our best understanding of problem complexity and developer availability. Dates represent expected availability in released Bazel. If a feature requires an incompatible flag, dates represent the first time the feature can be used, even if it requires setting the flag before it’s on by default. ETAs will change, but we’ll keep them refreshed and current.

Platforms

Also see the Platforms Roadmap for detailed priorities.

Jun 2019C++ rules fully support platforms and toolchains IN PROGRESS (#6516)

  • This gives them first-class Starlark support, select() on platforms, and configuration via --platforms
  • Sets best practices for adding platform and toolchain support to other rules

Jun 2019Java rules fully support platforms and toolchains IN PROGRESS (#6521)

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
  • --cpu, --host_cpu, --crosstool_top, --javabase, --apple_crosstool_top, etc. are deprecated

Jun 2019Legacy flags like --cpu automatically set --platform while the former are removed IN PROGRESS (#6426)

  • This prevents .bazelrcs, select()s on --cpu, and legacy command lines from breaking as rules adopt platforms
  • Rules can get platforms’ benefits without having to wait on migration

Aug 2019All supported Bazel rules support platforms and toolchains IN PROGRESS

late 2019Flagless multiplatform builds (unoptimized) 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

User-Defined Build Settings

See Starlark Build Configuration for in-depth motivation and design.

Mar 2019Starlark supports custom configuration transitions DONE (#5574)

  • Rule designers can have rules change their flags or their dependencies’ flags
  • This may have memory and performance consequences

Jul 2019Starlark supports fancy transitions IN PROGRESS (#5574)

  • Transitions can read a rule’s attributes to determine what to change DONE
  • Transitions on a rule can read attributes with select()

Jul 2019Starlark supports user-defined build settings IN PROGRESS (#5577)

Jul 2019All native Bazel rules can be implemented in Starlark IN PROGRESS (#5578)

  • This automatically comes out of user-defined build settings and custom transitions

Efficiency

May 2019An experimental Bazel mode automatically shrinks build graphs DONE (#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 2019This mode automatically optimizes test trimming and feature flags 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 IN PROGRESS (#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.

Jul 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

Jul 2019Documentation explains how to use configuration transitions efficiently NOT STARTED (#6525)

  • Explains why builds may use more memory and be slower
  • Explains how to minimize this and make informed use of these features
  • Points to tools for profiling your build
  • Explains ongoing work to automatically improve efficiency

late 2019Bazel automatically shrinks graphs with mixed build settings NOT STARTED (#6524)

  • Productionizes experimental build graph shrinking