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
FlagSets in the CROSSTOOL no longer accept expand_if_all_available field
Fixes #7008
RELNOTES: `--incompatible_disable_expand_if_all_available_in_flag_set` has been flipped (https://github.com/bazelbuild/bazel/issues/7008)
PiperOrigin-RevId: 234466411
* # copybara-scrub suffix now works in BUILD and bzl files
* //tools/cpp is rewritten to @bazel_build//tools/cpp **in any filetype**
* //third_party/bazel_rules/rules_cc is rewritten to // **in any filetype**
PiperOrigin-RevId: 233919400
Another dark corner corner of crosstools appeared, and apparently we didn't enable MOSTLY STATIC linking mode flags for dynamic libraries or objc. This cl addresses that in the legacy fields migrator.
RELNOTES: None.
PiperOrigin-RevId: 233397974
Starlark constructors for tool_path and tool do not allow empty strings for the path field. Therefore the migrator replaces the "" with "NOT_USED". We should ignore this difference when comparing the CToolchains.
#5380
PiperOrigin-RevId: 232827179
And fix an error where we added previously unseen action_names to the dictionary of familiar ACTION_NAMES, so later when we would encounter them, we would treat them as variables, not as string literals
eg
env_set {
action = "a"
}
would translate to
env_set(
actions = [a],
)
which is, obviously wrong.
Issue #5380
PiperOrigin-RevId: 232817515
If toolchain A and B need feature f, but toolchain C doesn't, the generated declaration statement for feature f would be:
if ctx.attr.cpu == 'A.cpu':
f = feature(...)
elif ctx.attr.cpu == "B.cpu" and ctx.attr.compiler == "B.compiler":
f = feature(...)
else:
fail("Unreachable")
This will break the rule implementation in the case of toolchain C because it will reach the fail("Unreachable") although it doesn't need to declare feature f
This cl fixes that
Issue #5380
PiperOrigin-RevId: 232683639
