With CROSSTOOL not existing anymore, the comparison script can continue being useful in refactoring Starlark toolchain config rules.
RELNOTES: None.
PiperOrigin-RevId: 262544859
Change-Id: I633fdc4c09c7643d6e5d1c10537efa3c9a82003c
We don't need to select a toolchain by the identifier when we get the proto from Starlark rules because in that case the proto contains a single toolchain.
The difference in toolchain_identifier field between the first and the second proto file will be caught as any other field.
RELNOTES: None.
PiperOrigin-RevId: 262543753
Change-Id: I1e66ee302bf551ade883c217f6269f44382393c0
*** Reason for rollback ***
Rolling back. No time before 1.0.
*** Original change description ***
C++: Move tools/cpp from bazel_tools to rules_cc
Here we are duplicating bazel_tools/tools/cpp. The goal is for the BUILD files in bazel_tools/tools/cpp to have an alias that point to rules_cc. Then later on with the incompatible flag these aliases will no longer be valid.
Working towards #8743
RELNOTES:none
PiperOrigin-RevId: 258756552
Change-Id: Ia44c0b5084ed9b28efbf9058e3dc29696db86fac
Here we are duplicating bazel_tools/tools/cpp. The goal is for the BUILD files in bazel_tools/tools/cpp to have an alias that point to rules_cc. Then later on with the incompatible flag these aliases will no longer be valid.
Working towards #8743
RELNOTES:none
PiperOrigin-RevId: 258344117
Change-Id: I5c0ffb1c7b501facabb543ad57440ea067ab3d34
This is in preparation for --incompatible_load_cc_rules_from_bzl
Closes #8744.
PiperOrigin-RevId: 256969979
Change-Id: I4f73790b9204156a5380e97e6bda70e2066d04a7
This target will eventually be the canonical place for C++ toolchain
type. Currently the actual target resides in @bazel_tools, but that will
soon change.
In order to migrate C++ rules to platforms, we need the access to the C++
configuration fragment in Starlark APIs. All existing APIs have already access
to it, but cc_common.configure_features doesn't. This change adds a
ctx argument to configure_features.
This is the migration needed for
https://github.com/bazelbuild/bazel/issues/7793, and is part of the effort for
https://github.com/bazelbuild/bazel/issues/6516.
If the rule doesn't depend on cpp fragment yet, you will have to add `fragments
=['cpp']` argument to the rule() call.
Note that this behavior is only available in Bazel 0.25 (to be released this month).
RELNOTES: None.
PiperOrigin-RevId: 247171967
When cpu value is not enough to distinguish between two toolchains, we use the compiler value. In that case, the user needs to specify the compiler value for all cc_toolchain_config rules, even for the ones with unique cpu. This cl fixes the allowed values in the compiler attribute to account for the values from unique toolchains.
Issue #5380
RELNOTES: None.
PiperOrigin-RevId: 239396228
This would have not introduced the osx crosstool bug in 2d0e27e8bc which was then fixed in unknown commit.
RELNOTES: None.
PiperOrigin-RevId: 238699176
This will make sure the copybara export is reversible, which is needed for setting up copybara workflow for importing github PRs.
RELNOTES: None.
PiperOrigin-RevId: 238445502
*** Reason for rollback ***
And now rolling forward because apparently ospo approved renovate.
*** Original change description ***
Automated rollback of commit 776b274c8a.
*** Reason for rollback ***
Because they use agpl licence.
*** Original change description ***
Enable 'renovate' bot for rules_cc
Fixes https://github.com/bazelbuild/rules_cc/pull/5.
RELNOTES: None.
PiperOrigin-RevId: 237213545
Since unknown commit is submitted, the principled variable to use in per_object_debug_info is is_using_fission, not per_object_debug_info_file (in case of thinlto build, the former is present also for thinlto bitcode compile, the latter only for backend compile).
RELNOTES: None.
PiperOrigin-RevId: 237192121
*** Reason for rollback ***
Because they use agpl licence.
*** Original change description ***
Enable 'renovate' bot for rules_cc
Fixes https://github.com/bazelbuild/rules_cc/pull/5.
RELNOTES: None.
PiperOrigin-RevId: 235746738
