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
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
Add flag --convert_lipo_to_thinlto, which allows builds with LLVM to use
ThinLTO when the user specifies LIPO + FDO flags; if that flag is not set, and
the user requests a build with LLVM, the compile will now fail.
Add an attribute supports_lipo to the DefaultCpuToolchain crosstool proto and
skip default toolchains that do not support LIPO when the user has specified
LIPO flags in the toolchain selection; this enables CROSSTOOL files to cause
an implicit fallback to a hybrid / LIPO toolchain when using an LLVM toolchain
as the default.
Add a CrosstoolBuilder to MockCcSupport and add a new method
setupCrosstoolFromScratch that allows unit tests to fully control the setup.
The other methods available in MockCcSupport will always load in a default
CROSSTOOL file and may show different unit test results depending on the
content of that file.
RELNOTES: None.
PiperOrigin-RevId: 163819246
*** Reason for rollback ***
b/37401971
*** Original change description ***
Make C++ archiving use action_configs instead of hardcoded flags
RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag.
PiperOrigin-RevId: 153344597
This enables us to configure default features for each toolchain without having
to hard-code anything in class such as CcCommon.
PiperOrigin-RevId: 146904287
This flag is not meant to be set on the commandline but to be readable from a Crosstool. This makes it so //tool/cc_target_os:android and friends don't require a hardcoded Crosstool top
PiperOrigin-RevId: 144983864
This feature allows us to expand a flag_group when a build variable is not
available. This is helpful when migrating crosstools in a backward compatible
way (that works with released bazel as well as with bazel at HEAD).
RELNOTES: NONE.
PiperOrigin-RevId: 143955333
This cl adds support for expand_if_true and expand_if_false messages
to the flag_group, allowing more elegant design of build variables.
This cl also adds IntegerValue VariableValue subclass.
RELNOTES: NONE.
PiperOrigin-RevId: 140849578
With the recent addition of structured variables to CROSSTOOL we now need a way
how to conditionally expand various flag_groups depending on the presence of
particular build variable or its fields. This cl adds this support to flag
groups.
RELNOTES: NONE.
PiperOrigin-RevId: 139466070
This cl adds a 3rd type of build variable - structs. Structs have fields, which
can hold any build variable type (including structs). In the CROSSTOOl, the
fields are accessed by the dot-notation, e.g.:
flag_group {
iterate_over: "libraries_to_link
flag_group {
iterate_over: "libraries_to_link.libraries"
flag: "-L%{libraries_to_link.libraries.directory}"
}
}
As a memory optimization, we also add StructureSequences. These save us from
the overhead of individual StructureValue objects.
RELNOTES: NONE
PiperOrigin-RevId: 138851774
Now flag_group can be marked with iterate_over field, that denotes for which
sequence variable the flag_group will be expanded repeatedly. This cl does that
in backwards compatible way as before, the iteration happened implicitly when the
used variable was found to be sequence at runtime. Because of that it adds some
extra code that will be removed once all the crosstools are migrated to the
explicit iteration.
RELNOTES: NONE
PiperOrigin-RevId: 138501033
1) Introducing the action_config message in the crosstool protobuf definition. The only part of that definition that are implemented in this CL is the "tool" section, other parts will be implemented in future CLs. The proto fields are here now to avoid being delayed by release cycles at each step of the implementation.
2) Refactoring the implementation of the "feature algebra" that computes the enabled features for a given toolchain. An interface called "CrosstoolActivatable" is used to represent any participant int the feature algebra, and can be either a feature or an action_config.
PiperOrigin-RevId: 118943663
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
PiperOrigin-RevId: 103938715
This allows to prevent expansion of flag sets based on whether build variables
are available. If required_variables is not set, and a variable that is
referenced in the flag_set's flags is not available, the build will fail.
We need the new behavior when some input files (for example profile data in
FDO enabled builds) are only available for a subset of the translation units of
a given target.
RELNOTES: None.
PiperOrigin-RevId: 100028996
hlopko