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
Another round of fixes:
* if the toolchain contains legacy_compile_flags or legacy_link_flags, replace the feature with default_compile_flags or default_link_flags. This is to ensure the location of the flags stays intact.
* it fixes the order of compilation flags, the correct order is:
1) compiler_flag
2) compilation_mode_flags.compiler_flag
3) cxx_flag
4) compilation_mode_flags.cxx_flag
* We don't add cxx_flags to assemble and preprocess-assemble actions
* We don't add sysroot to assemble action
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229336027
Our reasoning:
* it only works with gold
* it was broken for the last 3 months (since unknown commit) (silently did
nothing and nobody complained)
* we see almost zero usage of this option
RELNOTES: None.
PiperOrigin-RevId: 228116158
This change adds cc_toolchain.static_runtime_lib and
cc_toolchain.dynamic_runtime_lib attributes and an incompatible flag that
disables deprecated cc_toolchain.static_runtime_libs and
cc_toolchain.dynamic_runtime_libs.
Issue for the incompatible flag: #6942
Tracking issue for legacy crosstool fields removal: #5883
RELNOTES: Added --incompatible_disable_runtimes_filegroups
(https://github.com/bazelbuild/bazel/issues/6942).
PiperOrigin-RevId: 226165743
A quick hack of a tool that will be used for removing runtime filegroups
Issue for the --incompatible_disable_runtimes_filegroups incompatible flag
(which this cl is a step towards to): #6942
Tracking issue for legacy crosstool fields removal: #5883
RELNOTES: None.
PiperOrigin-RevId: 225995150
AFAIK all uses have been migrated to features, so they are not needed anymore.
RELNOTES: CppRules: optional_compiler_flag was removed from CROSSTOOL, use features instead.
PiperOrigin-RevId: 192277764
They are not used anyway. optional_compiler_flag will be removed once internal
migration is finished.
RELNOTES: CppRules: Remove optional_*_flag fields from CROSSTOOL, they are not
used, and could be expressed using features.
PiperOrigin-RevId: 190600731
This allows a flag_set to emit one flag when a feature is enabled, and a
different flag when that feature is disabled.
And while I was in there, I noticed and fixed a couple other issues:
1. env_set didn't actually implement with_feature, despite having the field in
its proto.
2. action_config implemented with_feature as an optional field, instead of
repeated field.
RELNOTES: None
PiperOrigin-RevId: 176510960
rosica