bazel: incompatible_use_platforms_repo_for_constraints: Don't use constraints from @bazel_tools, use @platforms instead

Available since: 0.28 Tracking issue: https://github.com/bazelbuild/bazel/issues/6516

Motivation

Bazel currently provides common constraints for platforms and toolchains in @bazel_tools//platforms. We are migrating these out of the Bazel binary to a principled, standalone repository over at https://github.com/bazelbuild/platforms which can be released independently from the Bazel binary and which defines a process for adding more constraints.

Migration

Ideally, declare an explicit dependency on https://github.com/bazelbuild/platforms, name the repository as @platforms, and use constraints from this repository. In cases where you cannot depend on https://github.com/bazelbuild/platforms (please tell us the reason in the comment), you can use the snapshot of https://github.com/bazelbuild/platforms in Bazel - Bazel implicitly provides this repository for Bazel’s needs.

The actual migration in BUILD files is simple - use @platforms//setting:value instead of @bazel_tools//platforms:value:

sed 's$@bazel_tools//platforms:(linux|osx|windows|android|freebsd|ios|os)$@platforms//os:\1$' -E -i **/*
sed 's$@bazel_tools//platforms:(cpu|x86_32|x86_64|ppc|arm|aarch64|s390x)$@platforms//cpu:\1$' -i -E **/*

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 3
  • Comments: 31 (23 by maintainers)

Commits related to this issue

Most upvoted comments

We are also seeing regression of the form reported by @schwehr with Bazel 6.0. For people using Bazelisk, as a temporary workaround, you can add a file called .bazelversion with the contents

5.4.0

to the root of your repo, to keep using Bazel 5.

I am quite happy Bazel is performing breaking changes. Imho the workflow based on incompatibility flags is working well and giving each project the possibility to adjust in its own pace. I am working a lot with C++ and would hate to see Bazel running into the same problem of ever growing complexity and need for best practices and linters just because nothing is ever deprecated.

Quick analysis. There are only about 10 instances of @bazel_tools//platforms in the code, so this should no be that hard to fix.

It actually looks like most of the work is done, so it might be as simple as flipping the flag, then eliminating the tests.

What is the point of having bazel to fight against the dependency hell and then changing bazel itself throwing people into another dependency hell?

That’s a good question, and I appreciate that this is difficult for some users. That is one of the reasons this has taken so long to roll out. This particular change is specifically to decouple bazel versions from the ability to build for new hardware. Let’s say Bazel 6 had a set of CPUs built in based on what was made in 2022, and rules depend on that version of platforms. You want to use Bazel 6 for a 5 year long project, but new hardware keeps being developed. So you want to build the 3rd generation of your device with a new RISC-V variant. You don’t want to have to update Bazel to pick up a new CPU name. Instead, you just want to pick up a new version of platforms.

Now that the flag is in the graveyard. Can you delete tools/platforms/… I’m not sure if there is a distinct issue for that, but it should happen before bazel 7.

Bazelisk’s --migrate no longer relies on GitHub labels: https://github.com/bazelbuild/bazelisk/pull/248

I would recommend to build / test your project with Bazel’s rolling releases (and additionally with the latest LTS, if you need to provide backwards compatibility to a long-term supported Bazel version) and also run a regular build / test with Bazelisk’s --migrate feature to detect whether any existing --incompatible_* flags would break you.

In that case, feel free to provide feedback to the author of the flag and/or file a bug, so that the team is aware and can take this into account prior to flipping.

I don’t know what the current practices are. Please send an email to bazel-dev to discuss this, since it’s a bigger question than this issue can manage.

s390x is a CPU, not an OS, so the constraint should be @platforms/./cpu:s390x.

👍 @philwo its a bit annoying that the bazel flag bot adds a non actionable issue. I like the concept a lot but I think the implementation needs to change