-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incompatible_use_platforms_repo_for_constraints: Don't use constraints from @bazel_tools, use @platforms instead #8622
Comments
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details.
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: #8622 Tracking issue: #6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. Closes #8625. PiperOrigin-RevId: 253242115
*** Reason for rollback *** Broke Bazel downstream: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1039#72cf19a2-072a-4ca1-ace2-37c458ef8420 Fixes #8645. *** Original change description *** Add --incompatible_use_platforms_repo_for_constraints This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: #8622 Tracking issue: #6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 f... *** PiperOrigin-RevId: 253544711
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. Closes bazelbuild#8625. PiperOrigin-RevId: 253242115
*** Reason for rollback *** Broke Bazel downstream: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1039#72cf19a2-072a-4ca1-ace2-37c458ef8420 Fixes bazelbuild#8645. *** Original change description *** Add --incompatible_use_platforms_repo_for_constraints This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 f... *** PiperOrigin-RevId: 253544711
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: #8622 Tracking issue: #6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. Closes #8625. This is encore of 332379a. Previous implementation failed with dependency cycle with the configuration. In this attempt I don't use selects, but I've put the incompatible flag checking logic directly into the alias rule. Not nice, but get's thing done. RELNOTES: PiperOrigin-RevId: 254357477
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. Closes bazelbuild#8625. PiperOrigin-RevId: 253242115
*** Reason for rollback *** Broke Bazel downstream: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1039#72cf19a2-072a-4ca1-ace2-37c458ef8420 Fixes bazelbuild#8645. *** Original change description *** Add --incompatible_use_platforms_repo_for_constraints This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 f... *** PiperOrigin-RevId: 253544711
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. Closes bazelbuild#8625. This is encore of bazelbuild@332379a. Previous implementation failed with dependency cycle with the configuration. In this attempt I don't use selects, but I've put the incompatible flag checking logic directly into the alias rule. Not nice, but get's thing done. RELNOTES: PiperOrigin-RevId: 254357477
Baseline: 2e374a9 Cherry picks: + 6d0b14b: rule_test: apply "tags" to all rules in the macro Incompatible changes: - Add --incompatible_enable_profile_by_default to enable the JSON profile by default. - The --incompatible_windows_style_arg_escaping flag is flipped to "true", and the "false" case unsupported. Bazel no longer accepts this flag. Important changes: - Bazel now supports hiding compiler warnings for targets that you're not explicitly building (see https://docs.bazel.build/versions/master/user-manual.html#flag--au to_output_filter). - Flag `--incompatible_restrict_escape_sequences` is added. See #8380 - The "info" command now supports the "starlark-semantics" argument, which outputs a representation of the effective Starlark semantics option values. - The `outputs` parameter of the `rule()` function is deprecated and attached to flag `--incompatible_no_rule_outputs_param`. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. See #7977 for more info. - When `--incompatible_strict_action_env` is enabled, the default `PATH` now includes `/usr/local/bin`. - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - `@bazel_tools//tools/jdk:toolchain_java10` and `@bazel_tools//tools/jdk:toolchain_java11` are now available to enable java 10, respectively java 11 language level support. - The `command` parameter of the `actions.run_shell()` function will be restricted to only accept strings (and not string sequences). This check is attached to flag `--incompatible_run_shell_command_string`. One may migrate by using the `arguments` parameter of `actions.run()` instead. See #5903 for more info. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 f... - Bazel's C++ autoconfiguration now understands `BAZEL_LINKLIBS` environment variable to specify system libraries that should be appended to the link command line. - paths under the execution root starting with "." or "_" will be re-linked across builds - execution_log_json_file now allows actions without outputs. - Labels aapt as deprecated for aapt_version, and heavily endorses aapt2. - Update doc links still pointing to cc_binary.features to point to common features - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. RELNOTES: - --incompatible_disable_nocopts flag has been added. See #8706 for details. - Fixed treatment of <dist:module /> tags in AndroidManifest.xml - Fixed asset precedence for android_binary rules with aapt2. - Bazel now officially supports running on CentOS 7. - The runtime dynamic libraries are no longer in default output group of cc_binary. - set the FDOBuildType as CSFDO for binaries built with --cs_fdo_absolute_path. - Bazel can now be bootstrapped and built on arm64 platforms without requiring any flags or patches. - Fixed treatment of AndroidManifest.xml attributes which contained XML escaping - Retire experimental blaze flag experimental_link_compile_output_separately. The same behavior is available through the feature dynamic_link_test_srcs. - --incompatible_load_java_rules_from_bzl was added to forbid loading the native java rules directly. See more on tracking issue #8746 - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - Attribute names are going to be restricted and must be syntactically valid identifiers. #6437 - rule_test: fix Bazel 0.27 regression ("tags" attribute was ingored, #8723 This release contains contributions from many people at Google, as well as Ben Diuguid, Benjamin Peterson, Dave Lee, Loo Rong Jie, Mark Butcher, Marwan Tammam, Pedro Alvarez.
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. Closes bazelbuild#8625. PiperOrigin-RevId: 253242115
*** Reason for rollback *** Broke Bazel downstream: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1039#72cf19a2-072a-4ca1-ace2-37c458ef8420 Fixes bazelbuild#8645. *** Original change description *** Add --incompatible_use_platforms_repo_for_constraints This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 f... *** PiperOrigin-RevId: 253544711
This change adds an incompatible flag to disable constrains bundled with Bazel in @bazel_tools. Incompatible change issue: bazelbuild#8622 Tracking issue: bazelbuild#6516 RELNOTES: Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. Closes bazelbuild#8625. This is encore of bazelbuild@332379a. Previous implementation failed with dependency cycle with the configuration. In this attempt I don't use selects, but I've put the incompatible flag checking logic directly into the alias rule. Not nice, but get's thing done. RELNOTES: PiperOrigin-RevId: 254357477
Baseline: 2e374a9 Cherry picks: + 6d0b14b: rule_test: apply "tags" to all rules in the macro Incompatible changes: - Add --incompatible_enable_profile_by_default to enable the JSON profile by default. - The --incompatible_windows_style_arg_escaping flag is flipped to "true", and the "false" case unsupported. Bazel no longer accepts this flag. Important changes: - Bazel now supports hiding compiler warnings for targets that you're not explicitly building (see https://docs.bazel.build/versions/master/user-manual.html#flag--au to_output_filter). - Flag `--incompatible_restrict_escape_sequences` is added. See bazelbuild#8380 - The "info" command now supports the "starlark-semantics" argument, which outputs a representation of the effective Starlark semantics option values. - The `outputs` parameter of the `rule()` function is deprecated and attached to flag `--incompatible_no_rule_outputs_param`. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. See bazelbuild#7977 for more info. - When `--incompatible_strict_action_env` is enabled, the default `PATH` now includes `/usr/local/bin`. - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - `@bazel_tools//tools/jdk:toolchain_java10` and `@bazel_tools//tools/jdk:toolchain_java11` are now available to enable java 10, respectively java 11 language level support. - The `command` parameter of the `actions.run_shell()` function will be restricted to only accept strings (and not string sequences). This check is attached to flag `--incompatible_run_shell_command_string`. One may migrate by using the `arguments` parameter of `actions.run()` instead. See bazelbuild#5903 for more info. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 f... - Bazel's C++ autoconfiguration now understands `BAZEL_LINKLIBS` environment variable to specify system libraries that should be appended to the link command line. - paths under the execution root starting with "." or "_" will be re-linked across builds - execution_log_json_file now allows actions without outputs. - Labels aapt as deprecated for aapt_version, and heavily endorses aapt2. - Update doc links still pointing to cc_binary.features to point to common features - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See bazelbuild#8622 for details. RELNOTES: - --incompatible_disable_nocopts flag has been added. See bazelbuild#8706 for details. - Fixed treatment of <dist:module /> tags in AndroidManifest.xml - Fixed asset precedence for android_binary rules with aapt2. - Bazel now officially supports running on CentOS 7. - The runtime dynamic libraries are no longer in default output group of cc_binary. - set the FDOBuildType as CSFDO for binaries built with --cs_fdo_absolute_path. - Bazel can now be bootstrapped and built on arm64 platforms without requiring any flags or patches. - Fixed treatment of AndroidManifest.xml attributes which contained XML escaping - Retire experimental blaze flag experimental_link_compile_output_separately. The same behavior is available through the feature dynamic_link_test_srcs. - --incompatible_load_java_rules_from_bzl was added to forbid loading the native java rules directly. See more on tracking issue bazelbuild#8746 - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - Attribute names are going to be restricted and must be syntactically valid identifiers. bazelbuild#6437 - rule_test: fix Bazel 0.27 regression ("tags" attribute was ingored, bazelbuild#8723 This release contains contributions from many people at Google, as well as Ben Diuguid, Benjamin Peterson, Dave Lee, Loo Rong Jie, Mark Butcher, Marwan Tammam, Pedro Alvarez.
Baseline: 2e374a9 Cherry picks: + 6d0b14b: rule_test: apply "tags" to all rules in the macro Incompatible changes: - Add --incompatible_enable_profile_by_default to enable the JSON profile by default. - The --incompatible_windows_style_arg_escaping flag is flipped to "true", and the "false" case unsupported. Bazel no longer accepts this flag. Important changes: - Bazel now supports hiding compiler warnings for targets that you're not explicitly building (see https://docs.bazel.build/versions/master/user-manual.html#flag--au to_output_filter). - Flag `--incompatible_restrict_escape_sequences` is added. See #8380 - The "info" command now supports the "starlark-semantics" argument, which outputs a representation of the effective Starlark semantics option values. - The `outputs` parameter of the `rule()` function is deprecated and attached to flag `--incompatible_no_rule_outputs_param`. Migrate rules to use `OutputGroupInfo` or `attr.output` instead. See #7977 for more info. - When `--incompatible_strict_action_env` is enabled, the default `PATH` now includes `/usr/local/bin`. - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - `@bazel_tools//tools/jdk:toolchain_java10` and `@bazel_tools//tools/jdk:toolchain_java11` are now available to enable java 10, respectively java 11 language level support. - The `command` parameter of the `actions.run_shell()` function will be restricted to only accept strings (and not string sequences). This check is attached to flag `--incompatible_run_shell_command_string`. One may migrate by using the `arguments` parameter of `actions.run()` instead. See #5903 for more info. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 f... - Bazel's C++ autoconfiguration now understands `BAZEL_LINKLIBS` environment variable to specify system libraries that should be appended to the link command line. - paths under the execution root starting with "." or "_" will be re-linked across builds - execution_log_json_file now allows actions without outputs. - Labels aapt as deprecated for aapt_version, and heavily endorses aapt2. - Update doc links still pointing to cc_binary.features to point to common features - Incompatible change `--incompatible_use_platforms_repo_for_constraints` has been added. See #8622 for details. RELNOTES: - --incompatible_disable_nocopts flag has been added. See #8706 for details. - Fixed treatment of <dist:module /> tags in AndroidManifest.xml - Fixed asset precedence for android_binary rules with aapt2. - Bazel now officially supports running on CentOS 7. - The runtime dynamic libraries are no longer in default output group of cc_binary. - set the FDOBuildType as CSFDO for binaries built with --cs_fdo_absolute_path. - Bazel can now be bootstrapped and built on arm64 platforms without requiring any flags or patches. - Fixed treatment of AndroidManifest.xml attributes which contained XML escaping - Retire experimental blaze flag experimental_link_compile_output_separately. The same behavior is available through the feature dynamic_link_test_srcs. - --incompatible_load_java_rules_from_bzl was added to forbid loading the native java rules directly. See more on tracking issue #8746 - Turn on --experimental_build_setting_api by default for starlark build settings (see https://docs.bazel.build/versions/master/skylark/config.html#user- defined-build-settings for more info) - Attribute names are going to be restricted and must be syntactically valid identifiers. #6437 - rule_test: fix Bazel 0.27 regression ("tags" attribute was ingored, #8723 This release contains contributions from many people at Google, as well as Ben Diuguid, Benjamin Peterson, Dave Lee, Loo Rong Jie, Mark Butcher, Marwan Tammam, Pedro Alvarez.
What is the status of this for 1.0? |
Not flipping in time for 1.0 |
What's the status on this? |
What is breaking in you build? Is it because some rules still depend on bazel providing platforms via bazel_tools? There is some indication of that in the linked protobuf issue, but that seemed to wither on the vine as inconclusive. @aranguyen Do you know of anything that is breaking downstream? To be clear, any fix involves moving the ecosystem to rely on |
For one, it is braking protobuf's build, and we depend on protobuf: protocolbuffers/protobuf#12509 |
@aiuto All downstream projects that are tracked by our CI are all green. For other untracked projects, users need to migrate their code away from using contraints from bazel_tools. protocolbuffers/protobuf#12509 (comment) mentioned that https://github.com/protocolbuffers/protobuf is green and the error doesn't seem to be related to this flag. Have you tried updating your protobuf dependency to latest version which should have been migrated. |
Now that the flag is in the graveyard. Can you delete tools/platforms/... |
This is breaking my build. I was trying to compile an older version of MediaPipeUnityPlugin (which I was able to do successfully 2 years ago) and now I'm getting into a dependency hell, apparently due to the above change. What is the point of having bazel to fight against the dependency hell and then changing bazel itself throwing people into another dependency hell? Anyway. I changed the following line in my WORKSPACE file:
by
it does not compile giving me the following error:
|
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. |
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 guess there is not point in find/replace anything inside these cache files. I have to make it earlier, I guess. Can someone tell me how to fix this? Are there some lines I should add to WORKSPACE to avoid these deprecated .cache files from being checked out? |
@mgarbade sorry I missed this message. You can try doing the following to see where in your project still depends on @bazel_tools//platforms
Example output from 3:
You can see in the example that it tells me in bazel_toolchains there was still dependency on |
* Bump oneTBB to avoid using deprecated selection in build files bazelbuild/bazel#8622 * Bump TF and remove patches * Fix oneTBB patch * Fix order of glog include * Fixes in UT's after gtest bump Gtest now detects that there are parametrized fixtures and there is no instantiation of that fixture and reports that a test failure. * Update TFS Model Metadata tests after TFS update With updated TFS the model metadata response through REST API contains additional field. * New patch for TF after update JIRA:CVS-114360
* Bump oneTBB to avoid using deprecated selection in build files bazelbuild/bazel#8622 * Bump TF and remove patches * Fix oneTBB patch * Fix order of glog include * Fixes in UT's after gtest bump Gtest now detects that there are parametrized fixtures and there is no instantiation of that fixture and reports that a test failure. * Update TFS Model Metadata tests after TFS update With updated TFS the model metadata response through REST API contains additional field. * New patch for TF after update * Update tests requirements after functional tests update JIRA:CVS-114360 * Fixing python=0 compilation Co-authored-by: rasapala <rafal.a.sapala@intel.com>
@platforms//os:* instead of from @build_tools//platforms:* See bazelbuild/bazel#8622 Necessary to fix google#4096 Also need the fix for google#4098 PiperOrigin-RevId: 497182073 Change-Id: Ifd568b088d2f779755dd20264edfd5dad12ca9cc
See bazelbuild/bazel#8622 MacOS sed commands: sed -E -i '' 's$@bazel_tools//platforms:(cpu|x86_32|x86_64|ppc|arm|aarch64|s390x)$@platforms//cpu:\1$' buildfiles/*.BUILD sed -E -i '' 's$@bazel_tools//platforms:(linux|osx|windows|android|freebsd|ios|os)$@platforms//os:\1$' buildfiles/*.BUILD
Ran into this error (below) when building the tensorflow suite of packages with conda, if you hit this when trying to bazel build
|
* Bump oneTBB to avoid using deprecated selection in build files bazelbuild/bazel#8622 * Bump TF and remove patches * Fix oneTBB patch * Fix order of glog include * Fixes in UT's after gtest bump Gtest now detects that there are parametrized fixtures and there is no instantiation of that fixture and reports that a test failure. * Update TFS Model Metadata tests after TFS update With updated TFS the model metadata response through REST API contains additional field. * New patch for TF after update * Update tests requirements after functional tests update JIRA:CVS-114360 * Fixing python=0 compilation Co-authored-by: rasapala <rafal.a.sapala@intel.com>
This breaks my repo: /private/var/tmp/_bazel_javieryu/aa8e4725bf9c05d07d76211f768b2ac1/external/local_execution_config_platform/BUILD:17:9: no such package '@@bazel_tools//platforms': BUILD file not found in directory 'platforms' of external repository @@bazel_tools. Any idea to find where this error message come from? |
From the error, looks like the problem is |
Available since: 0.28
Tracking issue: #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
:The text was updated successfully, but these errors were encountered: