Add an explicit export statement (with the same visibility) for
files that are currently only implicitly exported and used by other
pacakges. This prepares changing the visibility of implicitly-exported
files to be package private without causing a breakage.
PiperOrigin-RevId: 280171386
Change-Id: I083a9d4f82067b4d4c94d7b554013aeb91e401cc
Fixes:
* Enabled buildifier on the Bazel CI again
* Added Skydocs where missing
* Moved public files out of .../private/... (e.g. cc_toolchain_config_lib.bzl)
* Reformatted
* Removed unused loads
* Using relative labels for cc_configure related files
* Added development dependency on rules_proto
* they're not in the federation yet, so hand rolling in rules_cc's WORKSPACE file
* Added development dependency on rules_python (from federation)
* Cleaned up copybara (notable change - not using @rules_cc in labels inside rules_cc repo)
* Made cc_flags_supplier usable internally
* Moved load statements to the top of the bzl file
* Moved runfiles to the tools directory
* Unified toolchain_utils.bzl and find_cc_toolchain.bzl
RELNOTES: None.
PiperOrigin-RevId: 276479521
Change-Id: I3196896061fa2ee61a3efb130c214d288782066a
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
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
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
* # 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
If an action_config's name doesn't appear in the action_names.bzl, eg action-a.b+c, in it's assignments statement we would declare it as:
action_a.b+c_action = action_config( ...
This cl fixes it to create the action_config variable with the +, - and .
It also adds tests for action_config
Issue #5380
PiperOrigin-RevId: 232681355
Having a 'per_object_debug_data' feature enabled is giving the same signal as having supports_fission enabled. This is a safe change because all crosstools that have supports_fission: true have per_object_debug_info disabled, and with the legacy crosstool fields migration we will migrate this feature to be enabled by default for these crosstools.
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 230701029
This ensures that the generated files will be unique in the package and therefore there won't be action conflict.
RELNOTES: None.
PiperOrigin-RevId: 230514342
While here, Also fix _read_crosstool_or_ctoolchain_proto to actually return the CToolchain found in the CROSSTOOL file, and add some missing \n.
RELNOTES: None.
PiperOrigin-RevId: 229926500
This cl fixes a bug in the migrator where it didn't pass mentioned flags to c++-nodeps-dynamic-library unconditionally (it only passed them as with feature { feature: 'dynamic_linking_mode' }, which is incorrect, the feature doesn't not apply to nodeps-dynamic-library, only to transitive linking actions.
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229692958
When renaming legacy_*_flags to default_*_flags, also rename other fields such as requires.
We're intentionally not replacing the implies line, just removing it, because default_*_features are enabled by default, so they don't need to be implied (Implied field is older than enabled field, so there are uses of it where enabled would work just fine. The only semantic difference is that implied features cannot be disabled, whereas enabled can. But since the standard style of writing crosstools seems to prefer enabled, I'm doing the same here.)
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229518029
