Contribute

Bazel Configurability 2018 Roadmap

Last verified: 2018-10-18 (update history)

Point of contact: gregestren

Discuss: Configurability 2018 Roadmap: discussion

Goal

Configurability’s goal is to make Bazel a graceful multiplatform build tool. It also focuses on how users decide how their projects are built.

This translates into the following high-level goals:

  1. $ bazel {build|test} :all just works
    1. All targets “know” how to build for the right platforms with the right toolchains and desired options
    2. Users only have to fiddle with options they care about
  2. “Platforms” is a first-class concept
    1. “Platforms” and “toolchains” are well-defined, map well to reality, and are easy to create
    2. Builds, build rules, remote executors, etc. naturally integrate platforms
  3. Users decide what to configure

    $ bazel build //myapp:fancy_edition automatically builds my app with “fancy” features

  4. Users decide what rules to configure
    1. e.g. “all foo rules use the foo toolchain
    2. All rules can have multiplatform dependencies
    3. All configuration can be encoded in Starlark or BUILD files
  5. Builds stay fast and efficient
    1. Multiplatform builds don’t duplicate platform-agnostic work
    2. Building “foo” in distinct configurations produces distinct output paths
    3. Builds remain cross platform-cacheable and remote execution-friendly
    4. Users have robust tools to understand multiplatform effects

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

There’s a more detailed Platforms Roadmap available with more details on ongoing subprojects.

June 2018

Rules can declare what kinds of machines they can build on DONE (#5217)

  • Because of remote execution, this might not be the same machine Bazel runs on
Dec 2018

C++ 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 adoption by other rules
Dec 2018

“Toolchain modes” documentation explains how to use flags and configuration to select between multiple toolchains for the same platform see status (#6517)

2019

There’s one, simple way to choose platforms at the command line see status (#6518)

  • $ bazel build //a:foo_lang_rule --platforms=//platforms:mac
  • --cpu, --host_cpu, --crosstool_top, --javabase, --apple_crosstool_top, etc. are obsolete and trigger deprecation warnings
2019

Flagless 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!
    
  • Platform-independent deps (e.g. Java libraries) may be built twice: see Correctness and Speed below
2019

Java, Android, Apple rules fully support platforms and toolchains NOT STARTED (#6521)

  • These depend on Java and C++, so need to happen after those rules
  • --android_sdk, --ios_sdk_version, etc. are deprecated and obsolete

User-Defined Configuration

Oct 2018

Starlark supports platform transitions IN PROGRESS (#5574)

  • Rule designers can decide which rules target which platforms
  • Rule designers can declare default target platforms
  • Rule designers can have dependencies target different platforms than their parents
Dec 2018

Starlark supports multi-architecture (“fat”) binaries IN PROGRESS (#5575)

  • Rule designers can write rules that bundle deps configured for multiple platforms
Jan 2019

Starlark supports user-defined configuration settings IN PROGRESS (#5577)

Jan 2019

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

Correctness and Speed

May 2018

Users can manually tag rules to not duplicate under feature flags DONE (#6523)

  • This makes “feature customization” under Android binaries more efficient
  • Non-Android dependencies won’t duplicate due to Android-only changes
June 2018

Bazel updates fast on --test_timeout, etc. changes DONE ([#5579] (http://github.com/bazelbuild/bazel/issues/5579))

Dec 2018

An experimental Bazel mode automatically minimizes build graphs IN PROGRESS (#6524)

  • No rule builds twice due to unrelated flag changes
Dec 2018

User documentation provides clear guidance on “safe” Starlark transitions use IN PROGRESS (#6525)

  • Explains the risks of performance and memory regressions
  • Explains how to minimize these risks and make informed use of the feature
  • Explains how to track improvements and report problemns
2019

Java compilation doesn’t include cpu in its output paths ON HOLD (#6527)

  • This improves multiplatform build times and cross-build cacheability
  • This is conditional on the impact of generated sources, selects(), etc.
2019

Distinct actions can’t write to the same output path IN PROGRESS (#6526)

  • This prevents “output clobbering” when the same command is invoked twice with different inputs, producing different versions of the same output
  • This is especially important for Starlark rules
2019

Bazel automatically minimizes graphs over feature flag changes NOT STARTED (#6524)

2019

Bazel automatically minimizes graphs over all configuration changes NOT STARTED (#6524)

  • This productionizes the experimental minimization mode
2019

Build actions cache efficiently IN PROGRESS (#6526)

  • Content-identical outputs have the same file name (as much as possible)
  • Output paths don’t include cache-poisoning segments.: bazel-out/ppc-fastbuild/PlatformIndependentModule.class