This change adds an optional field to the C++ crosstool proto that
allows configuring the origin tool_path is relative to.
For now, the origin can be one of the following:
- CROSSTOOL_PACKAGE: If tool_path is a relative path, it's assumed to
be relative to the package of the crosstool top.
- FILESYSTEM_ROOT: tool_path is an absolute path. This is checked by
Bazel.
- WORKSPACE_ROOT: tool_path must be a relative path and is assumed to
be relative to the exec-root of the workspace (similar to other
executables).
Updates bazelbuild/bazel#8438
Closes #10967.
PiperOrigin-RevId: 310142352
Change-Id: If6316ffa5d7d2713b197840b4aafb2f0cdbb0b96
For now we will restrict allowed exports to the same package. At the same time
static_deps should be used to take into account what should be linked into a
shared library.
RELNOTES:none
PiperOrigin-RevId: 294668451
Change-Id: Ia087519106983bfa9a980e471d3102ab391a53eb
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
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
FlagSets in the CROSSTOOL no longer accept expand_if_all_available field
Fixes #7008
RELNOTES: `--incompatible_disable_expand_if_all_available_in_flag_set` has been flipped (https://github.com/bazelbuild/bazel/issues/7008)
PiperOrigin-RevId: 234466411
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
Googler