aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/rules/cpp/CcToolchainFeaturesTest.java
Commit message (Collapse)AuthorAge
* Migrate most of the assertions to Truth that the auto-migration tool did not ↵Gravatar lberki2017-05-31
| | | | | | | | | catch. IntelliJ's "replace structurally" command was surprisingly useful. RELNOTES: None. PiperOrigin-RevId: 157463734
* Add FeatureSpecification.Gravatar hlopko2017-05-30
| | | | | RELNOTES: None. PiperOrigin-RevId: 157450873
* Migrate tests to Truth.Gravatar lberki2017-05-29
| | | | | | RELNOTES: None. PiperOrigin-RevId: 157374805
* Implement 'provides' for crosstool.Gravatar cpeyser2017-05-15
| | | | PiperOrigin-RevId: 156086443
* Do not wrap dynamic libraries with --whole-archive blockGravatar hlopko2017-04-10
| | | | | | | It doesn't make sense, and is ignored anyway. RELNOTES: None. PiperOrigin-RevId: 152667088
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* FlagSet.with_feature can be used to condition the application of the FlagSet ↵Gravatar Cal Peyser2017-03-24
| | | | | | | | on the presence of features. -- PiperOrigin-RevId: 151038811 MOS_MIGRATED_REVID=151038811
* Add a boolean flag to a Feature to specify whether it is enabled by default.Gravatar Googler2017-02-08
| | | | | | | | | This enables us to configure default features for each toolchain without having to hard-code anything in class such as CcCommon. -- PiperOrigin-RevId: 146904287 MOS_MIGRATED_REVID=146904287
* Expose type of library_to_link in CROSSTOOLGravatar Marcel Hlopko2017-01-23
| | | | | | | | | | This cl relieves us from hard-coding -l and -l: flags in Bazel. To be able to express the behavior in CROSSTOOL, we need to know what type of library are we dealing with. -- PiperOrigin-RevId: 145271426 MOS_MIGRATED_REVID=145271426
* Introduce expand_if_none_available to crosstoolGravatar Marcel Hlopko2017-01-10
| | | | | | | | | | 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). -- PiperOrigin-RevId: 143955333 MOS_MIGRATED_REVID=143955333
* Do not expand flag_groups guarded by expand_if_true/false if variable is missingGravatar Marcel Hlopko2017-01-03
| | | | | | -- PiperOrigin-RevId: 143443361 MOS_MIGRATED_REVID=143443361
* Add expand_if_equal crosstool.proto messageGravatar Marcel Hlopko2017-01-03
| | | | | | | | | This will be used by LibrariesToLinkValue to switch on many different types of libraries. -- PiperOrigin-RevId: 143438434 MOS_MIGRATED_REVID=143438434
* Introduce FlagGroup.expandIfTrue, expandIfFalseGravatar Marcel Hlopko2016-12-02
| | | | | | | | | | 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. -- PiperOrigin-RevId: 140849578 MOS_MIGRATED_REVID=140849578
* Introduce support for 'expand_if_all_available' for flag_groups in CROSSTOOLGravatar Marcel Hlopko2016-11-17
| | | | | | | | | | 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. -- MOS_MIGRATED_REVID=139466070
* Simplify Crosstool Build Variables contextGravatar Marcel Hlopko2016-11-16
| | | | | | | | | | | | | | This cl merges two classes used to hold build variables context into one. Those classes are (previously top-level) jcgd.build.lib.rules.cpp.Variables, and its inner class View. Both represent a collection of build variables and imo it makes sense to merge them to make the code simpler. Also, I cleaned up the build variables api to use primitive strings or instances of VariableValueBuilders, and I've hidden subclasses of VariableValues. Last but not least, I refactored the code to use immutable collections exclusively. That revealed that 'module_files' variable is sometimes registered twice. I want to clean this eventually ([]). -- MOS_MIGRATED_REVID=139329823
* Introduce structured build variables in CrosstoolGravatar Marcel Hlopko2016-11-11
| | | | | | | | | | | | | | | | | | | | 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. -- MOS_MIGRATED_REVID=138851774
* Introduce explicit iterate_over field for flag_group in CrosstoolGravatar Marcel Hlopko2016-11-08
| | | | | | | | | | | | 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. -- MOS_MIGRATED_REVID=138501033
* Allow flags to be applied to an action using an action_config. A flag set onGravatar Cal Peyser2016-06-07
| | | | | | | | an action_config specifies no action, and is automatically applied to the action being configured. -- MOS_MIGRATED_REVID=124240929
* The link command line API can consume a feature configuration to configure ↵Gravatar Cal Peyser2016-05-19
| | | | | | | flags and environment variables. -- MOS_MIGRATED_REVID=122735641
* Action configs are activated like features (instead of being activated by ↵Gravatar Cal Peyser2016-05-11
| | | | | | | default). Action configs can imply features. -- MOS_MIGRATED_REVID=122032003
* Add mechanism to crosstool language to specify action-specific execution ↵Gravatar Cal Peyser2016-04-25
| | | | | | | requirements. Uses this mechanism to configure c/c++ compilation and linking for darwin execution from the crosstool. -- MOS_MIGRATED_REVID=120701108
* --Gravatar Michael Staib2016-04-21
| | | | MOS_MIGRATED_REVID=120353718
* Add mechanism to crosstool language to specify action-specific execution ↵Gravatar Cal Peyser2016-04-19
| | | | | | | requirements. Uses this mechanism to configure c/c++ compilation and linking for darwin execution from the crosstool. -- MOS_MIGRATED_REVID=120218079
* Introduces action_config. Does this by:Gravatar Cal Peyser2016-04-05
| | | | | | | | | 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. -- MOS_MIGRATED_REVID=118943663
* Reduce memory use of feature values by introducing a ValueSequence class ↵Gravatar Manuel Klimek2016-03-24
| | | | | | | that keeps the Strings and creates the corresponding Value objects only at expansion time. -- MOS_MIGRATED_REVID=117947058
* Extend crosstool configuration to allow features to specify (expandable) ↵Gravatar Chris Parsons2016-01-07
| | | | | | | environment variables to pass to actions -- MOS_MIGRATED_REVID=111608329
* Open-source some tests for cpp rules.Gravatar Dmitry Lomov2015-11-30
-- MOS_MIGRATED_REVID=108794003
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-11 12:19:34 +0000