Bazel Configurability 2019 Roadmap

Last verified: 2020-01-17 (update history)

Point of contact: gregestren

Discuss: Configurability roadmap: discussion

This roadmap has been retired. See here for the current roadmap.

Previous roadmaps

EOY Review

Status as of Jan 2020:

Platforms:

  • C++ rules support the new platforms API. Deferred enabling by default since depending Android and iOS projects break.
  • Java rules support the new platforms API. Actual platform definitions remain pending.
  • To enable C++ and Java support in 2020, we’ll use platform mappings to manage Android / iOS integration. We’ll need help from project owners to ensure we don’t break them.
  • Lesson learned: global rollout is an involved cross-team effort.

User-defined configuration:

  • Starlark build configuration is v1.0 feature-complete: the core API is working and stable.
  • Some features will continue to need bake-in time (example). We’ll prioritize these as individual feature requests vs. a larger overarching effort.

Efficiency:

  • Due to an unanticipated temporary developer squeeze, this work stalled in Q4 to support basic maintenance (API bug fixes, cquery support, etc.).
  • As of 2020 the squeeze is over. Trimming and caching efforts will ramp up in earnest starting Q1.

Collaboration:

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 PARTIALLY DONE (#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 PARTIALLY DONE (#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 DONE (w/ opt in) (#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 DONE FOR PYTHON

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 DONE (#5574)

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

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

Jul 2019All native Bazel rules can be implemented in Starlark DONE (#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 PARTIALLY 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 2019An experimental Bazel mode makes identical actions unique PARTIALLY DONE (#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