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_disable_legacy_crosstool_fields: Disable legacy crosstool fields #6861

Open
hlopko opened this Issue Dec 7, 2018 · 1 comment

Comments

Projects
None yet
1 participant
@hlopko
Copy link
Contributor

hlopko commented Dec 7, 2018

Flag: --incompatible_disable_legacy_crosstool_fields
Available since: 0.22 (January 2019 release)
Will be flipped in: 0.24 (March 2019 release)
Tracking issue: #5883
Rollout doc: https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#

Motivation

CROSSTOOL grew much bigger than it was expected in 2011 when it was first introduced. There are many fields that are no longer used (e.g. mao_plugin_header_directory), or there are fields that are superseded by features (e.g. compiler_flag). There are fields that specify toolchain capabilities (e.g. supports_embedded_runtimes) but cannot participate in the feature configuration (and there are user requests for these). All in all, CROSSTOOL needs a revamp, and this change achieves that.

Caveats

This is a big incompatible change, and #5380 will be comparably big one. We advice users to use the migration tool provided for --incompatible_disable_legacy_crosstool_fields as the final step of their CROSSTOOL generating pipeline, and wait with hand-tweaking for the migration tool that will be provided for #5380. --incompatible_disable_legacy_crosstool_fields will not be flipped before #5380 is fixed.

Migration

Please use the legacy_fields_migrator tool provided at rules_cc repository. To verify the correctness of your build, use the command line diffing tool provided at tools/cmd_line_differ (bazel aquery, that the differ uses, is being improved daily as of January 2019, e.g. 1, so if you don't use bazel > 0.23, we advice to build your own bazel from HEAD for testing the migrated crosstool). As mentioned above, we advice not to hand-tune the CROSSTOOL without also migrating for #5380 (automated migrator to starlark will be provided).

Detailed change description

This list contains all the legacy fields and how they will be migrated:

  • static_runtimes_filegroup will not be used once #6942 is flipped. Use cc_toolchain.static_runtime_lib instead.
  • dynamic_runtimes_filegroup will not be used once #6942 is flipped. Use cc_toolchain.dynamic_runtime_lib instead.
  • compiler_flag is replaced by features. Flags from compiler_flag should appear before any other legacy field, and should be passed to all compilation actions.
  • optional_compiler_flag is not used.
  • cxx_flag is replaced by features. Flags from cxx_flag should appear after compiler_flags, and should be passed to all compilation actions except c-compile.
  • optional_cxx_flag is not used.
  • unfiltered_cxx_flag is replaced by features. Flags from feature named unfiltered_compile_flags are not subject to nocopts filtering.
  • optional_unfiltered_cxx_flag is not used.
  • linker_flag is replaced by features. Flags from linker_flag should appear before any other legacy field, and should be passed to all linking actions (except the misnamed archiving action c++-link-static-library)
  • optional_linker_flag is not used.
  • dynamic_library_linker_flag is replaced by features. Flags from dynamic_library_linker_flag should appear after linker_flag fields from linking_mode_flags, and should be only present when linking dynamic libraries.
  • optional_dynamic_library_linker_flag is not used.
  • test_only_linker_flag is replaced by features. test_only_linker_flag should appear after dynamic_library_linker_flag, and only for tests.
  • objcopy_embed_flag is replaced by features.
  • ld_embed_flag is replaced by features.
  • ar_flag is not used.
  • ar_thin_archives_flag is not used.
  • gcc_plugin_compiler_flag is not used.
  • compilation_mode_flags are replaced by features. Features named opt, dbg, and fastbuild are automatically enabled for given compilation mode. Flags from inner compiler_flag should appear after top-level cxx_flags. Flags from inner cxx_flag should appear after inner compiler_flag. Flags from linker_flag should appear after top-level linker_flag fields, before flags from linking_mode_flags.
  • lipo_mode_flags is not used.
  • linking_mode_flags are replaced by features. Mode COVERAGE is not used. Mode FULLY_STATIC has been replaced by fully_static_link feature and therefore unused. Mode MOSTLY_STATIC is replaced by static_linking_mode feature and mode DYNAMIC is replaced by dynamic_linking_mode feature. Both are enabled by rules explicitly.
  • gcc_plugin_header_directory is not used.
  • mao_plugin_header_directory is not used.
  • default_python_top is not used.
  • default_python_version is not used.
  • python_preload_swigdeps is not used.
  • supports_gold_linker is only used for --symbol_counts and will be removed.
  • supports_thin_archives is not used or user.
  • supports_start_end_lib is replaced by feature named supports_start_end_lib that should be enabled by the toolchain or user.
  • supports_interface_shared_objects is replaced by feature named supports_interface_shared_libraries that should be enabled by the toolchain or user.
  • supports_embedded_runtimes is replaced by feature named static_link_cpp_runtimes that should be enabled by the toolchain or user.
  • supports_incremental_linker is not used.
  • supports_normalizing_ar is not used.
  • supports_fission is replaced by feature named per_object_debug_info that should be enabled by the toolchain or user.
  • supports_dsym is not used.
  • needsPic is replaced by feature named supports_pic that should be enabled by the toolchain or user. Before Bazel always requrested pic feature, and verified that pic feature is enabled when needsPic was true or when --force_pic option was passed. With this change, Bazel will only request supports_pic when --force_pic is passed, and it verify that supports_pic is enabled only when --force_pic is passed. When --force_pic is not passed, Bazel will not request supports_pic explicitly, and it will assume that when supports_pic is enabled by the toolchain or user, it means PIC is needed for shared libraries. pic and force_pic build variables are still passed in their corresponding configurations.

A really good place to see exactly what is migrated and how is to see the tests for legacy_fields_migrator.

Changelog

  • January 3rd: Implemented cmd_line_differ
  • January 7th: Bazel 0.22, which contains this flag, was cut
  • January 7th: Fixed broken interface library input detection (a4529db), this is unlikely to affect Bazel users.
  • January 7th: Discovered the issue where $EXEC_ORIGIN is not used when static_link_cpp_runtimes is disabled, this is unlikely to affect Bazel users. If it does affect you, the fix was to add runtime_library_search_directories to the crosstool and not relying on Bazel to patch it in.
  • January 11th: Open-sourced legacy_fields_migrator
  • January 15th: Bazel fix to move default_compile_flags feature to the top of the crosstool, to stay backwards compatible. This fix does affect every user that doesn't specify no_legacy_features feature. Migrator fixed accordingly.
  • January 17th: Migrator fix for nodeps_dynamic_library.
@hlopko

This comment has been minimized.

Copy link
Contributor

hlopko commented Dec 7, 2018

bazel-io pushed a commit that referenced this issue Dec 20, 2018

Allow setting supports_start_end_lib crosstool field using feature
This cl allows toolchain owners to express that toolchain supports --start-lib/--end-lib using enabled feature "supports_start_end_lib".

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 226292303

bazel-io pushed a commit that referenced this issue Dec 20, 2018

Allow setting supports_interface_shared_objects crosstool field using…
… feature

This cl allows toolchain owners to express that toolchain supports creating interface shared libraries.

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 226302378

bazel-io pushed a commit that referenced this issue Dec 22, 2018

Allow setting supports_dynamic_linker crosstool capability using feature
This cl allows toolchain owners to express that toolchain supports creating dynamic libraries.

This is in theory a breaking change, for the crosstools that don't use `dynamic_library_linker_flag`, and don't specify `linking_mode_flags { mode: DYNAMIC }`, and they do specify feature { name: 'dynamic_linking_mode' }. This currently means the toolchain will generate shared libraries, but with this change it will not.

But since this only happens to toolchains that don't use legacy fields, and I don't think there are such toolchains in the wild, I'll go ahead and do this change without following the incompatible change process.

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 226631573

bazel-io pushed a commit that referenced this issue Dec 26, 2018

Allow setting supports_fission crosstool capability using feature
`supports_fission` can now be expressed using 'per_object_debug_info' feature (should be enabled for it to take effect).

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 226950450

bazel-io pushed a commit that referenced this issue Dec 27, 2018

Allow setting supports_embedded_runtimes crosstool capability using f…
…eature

`supports_embedded_runtimes` can now be expressed using 'static_link_cpp_runtimes' feature (should be enabled for it to take effect).

This cl allows toolchain owners to express that toolchain supports embedded runtimes in the same way as other crosstool capabilities are expressed.

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 227024509

bazel-io pushed a commit that referenced this issue Dec 28, 2018

Add --incompatible_disable_legacy_crosstool_fields
Incompatible flag issue: #6861
Tracking issue: #5883

RELNOTES: Added --incompatible_disable_legacy_crosstool_fields. See the
migration notes at #6861.
PiperOrigin-RevId: 227104932

bazel-io pushed a commit that referenced this issue Dec 28, 2018

Do not enable random features in cc_common.configure_features
This change removes some hardcoded feature names when #6861 is flipped.

RELNOTES: None.
PiperOrigin-RevId: 227110386

bazel-io pushed a commit that referenced this issue Dec 28, 2018

Allow setting needsPic crosstool capability using feature
`needsPic` can now be expressed using 'pic' feature (should be enabled for it to take effect).

This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 227134726

bazel-io pushed a commit that referenced this issue Jan 2, 2019

Do not require passing legacy fields to CppActionConfigs
This cl is a step towards #5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is #6861

RELNOTES: None.
PiperOrigin-RevId: 227491541

@meteorcloudy meteorcloudy changed the title --incompatible_disable_legacy_crosstool_fields: Disable legacy crosstool fields incompatible_disable_legacy_crosstool_fields: Disable legacy crosstool fields Jan 3, 2019

bazel-io pushed a commit that referenced this issue Jan 7, 2019

Don't rely on supports_interface_shared_objects for toolchain inputs
Progress towards:
#6861
#5883

RELNOTES: None.
PiperOrigin-RevId: 228175730

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

Move legacy_fields_migrator to rules_cc
Needed for --incompatible_disable_legacy_crosstool_fields migration: bazelbuild/bazel#6861
Tracking issue: bazelbuild/bazel#5883

RELNOTES: None.
PiperOrigin-RevId: 225956311

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

Allow setting supports_fission crosstool capability using feature
`supports_fission` can now be expressed using 'per_object_debug_info' feature (should be enabled for it to take effect).

This cl is a step towards bazelbuild/bazel#5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is bazelbuild/bazel#6861

RELNOTES: None.
PiperOrigin-RevId: 226950450

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

Allow setting supports_embedded_runtimes crosstool capability using f…
…eature

`supports_embedded_runtimes` can now be expressed using 'static_link_cpp_runtimes' feature (should be enabled for it to take effect).

This cl allows toolchain owners to express that toolchain supports embedded runtimes in the same way as other crosstool capabilities are expressed.

This cl is a step towards bazelbuild/bazel#5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is bazelbuild/bazel#6861

RELNOTES: None.
PiperOrigin-RevId: 227024509

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

Allow setting needsPic crosstool capability using feature
`needsPic` can now be expressed using 'pic' feature (should be enabled for it to take effect).

This cl is a step towards bazelbuild/bazel#5883. Also
see the rollout doc here:
https://docs.google.com/document/d/1uv4c1zag6KvdI31qdx8C6jiTognXPQrxgsUpVefm9fM/edit#.

Flag removing legacy behavior is bazelbuild/bazel#6861

RELNOTES: None.
PiperOrigin-RevId: 227134726

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

Fix legacy_fields_migrator
This cl fixes:

* clears 'supports_embedded_runtimes'
* adds user_compile_flags and sysroot feature
  * these are needed to appear before unfiltered_compile_flags

Progress towards:
bazelbuild/bazel#6861
bazelbuild/bazel#5883

RELNOTES: None.
PiperOrigin-RevId: 228299172

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 11, 2019

bazel-io pushed a commit that referenced this issue Jan 14, 2019

Do not disable static_link_cpp_runtimes when toolchain.supportsEmbedd…
…edRuntimes is not set

Before, Bazel explicitly added static_link_cpp_runtimes to disabled features, when toolchain didn't set supportsEmbeddedRuntimes. This is unnecessary (if the toolchain doesn't support embeddded runtimes, it can just not create/enable the feature), and it makes migration for #5883 harder. Let's remove it.

#5883
#6861

RELNOTES: None.
PiperOrigin-RevId: 229188252

bazel-io pushed a commit that referenced this issue Jan 15, 2019

Also move default_compile_flags to the top of the crosstool
Currently we move legacy_compile_flags to the top of the crosstool, and the same behavior is needed for migrated crosstools in case of default_compile_flags.

#6861
#5883

RELNOTES: None.
PiperOrigin-RevId: 229339668

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 15, 2019

Fix legacy_fields_migrator
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

bazelbuild/bazel#6861
bazelbuild/bazel#5883

RELNOTES: None.
PiperOrigin-RevId: 229336027

hlopko added a commit to hlopko/bazel that referenced this issue Jan 15, 2019

Add --disable_legacy_crosstool_fields to host configuration
bazelbuild#6861
bazelbuild#5883

RELNOTES: None
PiperOrigin-RevId: 227481086
Change-Id: I7223a4c334074642087ea3d915970aa94720dd78

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 16, 2019

Rename/remove fields referencing legacy features in legacy_fields_mig…
…rator

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.)

bazelbuild/bazel#6861
bazelbuild/bazel#5883

RELNOTES: None.
PiperOrigin-RevId: 229518029

bazel-io pushed a commit to bazelbuild/rules_cc that referenced this issue Jan 17, 2019

Always put linker_flags from linking_mode_flags.DYNAMIC to nodeps-dyn…
…amic-library

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.

bazelbuild/bazel#6861
bazelbuild/bazel#5883

RELNOTES: None.
PiperOrigin-RevId: 229692958

katre pushed a commit to katre/bazel that referenced this issue Jan 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment