Contribute

Bazel Configurability 2019 Roadmap

Last verified: 2019-01-28 (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. 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
  • These set best practice templates for adding platform and toolchain support to other rules

Jun 2019Java rules fully support platforms and toolchains 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
  • --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 NOT STARTED (#6426)

  • This prevents .bazelrcs, select()s on --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 (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

late 2019All supported Bazel rules fully support platforms and toolchains NOT STARTED

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 select()

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

Apr 2019All native Bazel rules can be implemented in Starlark 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