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
Googler