Building with platforms
Bazel has sophisticated support for modeling platforms and toolchains. Integrating this into real projects requires coherent cooperation between project and library owners, rule maintainers, and core Bazel devs.
This page summarizes the arguments for using platforms and shows how to navigate these relationships for maximum value with minimum cognitive overhead.
In short: the core APIs are available but the rule and depot migrations required to make them work universally are ongoing. This means you may be able to use platforms and toolchains with your project, with some work. But you have to explicitly opt your project in.
For more formal documentation, see:
Platforms and toolchains were introduced to standardize the need for software projects to target different kinds of computers with different language-appropriate tools.
This is a relatively recent addition to Bazel. It was
by the observation that language maintainers were already doing this in ad hoc
and incompatible ways. For example, C++ rules use
to set a build’s target CPU and C++ toolchain. Neither of these correctly models a
“platform”. Historic attempts to use them for that inevitably led to awkward and
inaccurate build APIs. They also don’t say anything about Java toolchains,
which evolved their own independent interface with
Bazel aims to excel at large, mixed-language, multi-platform projects. This demands more principled support for these concepts, including clear APIs that bind rather than diverge languages and projects. This is what the new platform and toolchain APIs achieve.
These APIs aren’t enough for all projects to use platforms. We also have to
retire the old APIs. This isn’t trivial because all of a project’s languages,
toolchains, dependencies, and
select()s have to support the new APIs. This
requires an ordered migration sequence to keep projects working correctly.
For example, Bazel’s C++ rules aleady support platforms while the Android rules don’t. Your C++ project may not care about Android. But others may. So it’s not yet safe to globally enable platforms for all C++ builds.
The thrust of this page describes this migration sequence and how and when your projects can fit in.
Bazel’s platform migration is complete when all projects build with the form:
$ bazel build //:myproject --platforms=//:myplatform
- The rules your project uses can infer correct toolchains from
- The rules your project’s dependencies use can infer correct toolchains
- Either the projects depending on yours support
//:myplatformor your project supports the legacy APIs (like
//:myplatformreferences common declarations of
OS, and other generic concepts that support automatic cross-project compatibility.
- All relevant projects’
select()s understand the machine properties implied by
//:myplatformis defined in a clear, reusable place: in your project’s repo if the platform is unique to your project, otherwise somewhere all projects that may use this platform can find.
As soon as this goal is achieved, we’ll remove the old APIs and make this the way projects select platforms and toolchains.
Should I use platforms?
If you just want to build or cross-compile a project, you should follow the project’s official documentation.
If you’re a project, language, or toolchain maintainer, you’ll eventually want to support the new APIs. Whether you wait until the global migration is complete or opt in early depends on your specific value / cost needs:
- You can
select()or choose toolchains on the exact properties you care about instead of hard-coded flags like
--cpu. For example, multiple CPUs can support the same instruction set.
- More correct builds. If you
--cpuin the above example, then add a new CPU that supports the same instruction set, the
select()fails to recognize the new CPU. But a
select()on platforms remains accurate.
- Simpler user experience. All projects understand:
--platforms=//:myplatform. No need for multiple language-specific flags on the command line.
- Simpler language design. All languages share a common API for defining toolchains, using toolchains, and selecting the right toolchain for a platform.
- Dependent projects that don’t yet support platforms might not automatically work with yours.
- Making them work may require additional temporary maintenance.
- Co-existence of new and legacy APIs requires more careful user guidance to avoid confusion.
- Canonical definitions for common properties like
CPUare still evolving and may require extra initial contributions.
- Canonical definitions for language-specific toolchains are still evolving and may require extra initial contributions.
platform is a collection of
platform( name = "myplatform", constraint_values = [ "@platforms//os:linux", "@platforms//cpu:arm", ], )
constraint_value is a machine
property. Values of the same “kind” are grouped under a common
constraint_setting(name = "os") constraint_value( name = "linux", constraint_setting = ":os", ) constraint_value( name = "mac", constraint_setting = ":os", )
toolchain is a Starlark rule. Its
attributes declare a language’s tools (like
"//mytoolchain:custom_gcc"). Its providers pass
this information to rules that need to build with these tools.
Toolchains declare the
constraint_values of machines they can
target_compatible_with = ["@platforms//os:linux"]) and machines their tools can
exec_compatible_with = ["@platforms//os:mac"]).
$ bazel build //:myproject --platforms=//:myplatform, Bazel
automatically selects a toolchain that can run on the build machine and
build binaries for
//:myplatform. This is known as toolchain resolution.
The set of available toolchains can be registered in the
register_toolchains or at the
command line with
See here for a deeper dive.
Current platform support varies among languages. All of Bazel’s major rules are moving to platforms. But this process will take time. This is for three main reasons:
Rule logic must be updated to get tool info from the new toolchain API (
ctx.toolchains) and stop reading legacy settings like
--crosstool_top. This is relatively straightforward.
Toolchain maintainers must define toolchains and make them accessible to users (in GitHub repositories and
WORKSPACEentries). This is technically straightforward but must be intelligently organized to maintain an easy user experience.
Platform definitions are also necessary (unless you build for the same machine Bazel runs on). But we generally expect projects to define their own platforms.
Existing projects must be migrated.
select()s and transitions also have to be migrated. This is the biggest challenge. It’s particularly challenging for multi-language projects (which may fail if all languages can’t read
If you’re designing a new rule set, we strongly recommend you support platforms from the beginning. This automatically makes your rules compatible with other rules and projects, with increasing value as the platform API becomes more ubiquitious.
Common platform properties
Platform properties like
CPU that are common across projects should
be declared in a standard, centralized place. This encourages cross-project
and cross-language compatibility.
For example, if MyApp has a
@myapp//cpus:arm and SomeCommonLib has a
@commonlib//constraints:arm, these trigger their “arm” modes with incompatible
Globally common properties are declared in the
(so the canonical label for the above example is
Language-common properties should be declared in the repos of their respective
Generally, project owners should define explicit
platforms to describe the
kinds of machines they want to build for. These are then triggered with
--platforms isn’t set, Bazel defaults to a
platform representing the
local build machine. This is auto-generated at
so there’s no need to explicitly define it. It maps the local machine’s
constraint_values declared in
Bazel’s C++ rules use platforms to select toolchains when you set
This means you can configure a C++ project with
$ bazel build //:my_cpp_project --platforms=//:myplatform
instead of the legacy
$ bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
If your project is pure C++ and not depended on by non-C++ projects, you can use
this mode safely as long as your
transitions also work with platforms. See
#7260 and Configuring C++
toolchains for further migration guidance.
This mode is not enabled by default. This is because Android and iOS projects
still configure C++ dependencies with
it requires adding platform support for Android and iOS.
Bazel’s Java rules use platforms to select toolchains.
This replaces legacy flags
PR #8 defines the Java-specific
constraint_values, toolchains, and other settings that make migration
practical. This mode will be enabled by default after those changes are
Bazel’s Android rules do not yet support platforms to select Android toolchains.
They do support setting
--platforms to select NDK toolchains: see
which builds multi-architecture fat APKs, does not work with platform-enabled
C++. This is because it sets legacy flags like
which platform-enabled C++ rules don’t read. Until this is migrated, using
--platforms requires platform
Bazel’s Apple rules do not yet support platforms to select Apple toolchains.
They also don’t support platform-enabled C++ dependencies because they use the
--crosstool_top to set the C++ toolchain. Until this is migrated, you
can mix Apple projects with platorm-enabled C++ with platform
- Bazel’s Rust rules fully support platforms.
- Bazel’s Go rules fully support platforms (details).
If you’re designing rules for a new language, we strongly encourage you to use platforms to select your language’s toolchains. See the toolchains documentation for a good walkthrough.
email@example.com. or the owners of the appropriate rules.
For discussions on the design and evolution of the platform/toolchain APIs, contact firstname.lastname@example.org.