aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CppConfigurationLoader.java
Commit message (Collapse)AuthorAge
* Pass cc_toolchain location to FeatureConfigurationGravatar rosica2018-08-07
| | | | | | | Paths to tools in CROSSTOOL are either absolute or relative to the CROSSTOOL location (which is the same as cc_toolchain location). As in the future CROSSTOOL will be gone, and the new skylark rule that will replace CROSSTOOL will not have to be in the same location as cc_toolchain, we need to pass information to FeatureConfiguration about the location of the cc_toolchain in use, so we can calculate the workspace relative paths to the tools. RELNOTES: None. PiperOrigin-RevId: 207695703
* Add --experimental_enable_cc_toolchain_label_from_crosstool_proto flag for ↵Gravatar rosica2018-07-23
| | | | | | | | | disabling relying on CROSSTOOL file in order to select the cc_toolchain label CROSSTOOL file should not have any influence over selection of the cc_toolchain label. Ultimately the information that CROSSTOOL offers will be rerouted through an attribute of cc_toolchain. RELNOTES: None. PiperOrigin-RevId: 205651369
* Rename CrosstoolInfo.java to CcToolchainConfigInfo.javaGravatar rosica2018-07-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 205060182
* Automated refactor of Label.parseAbsolute() to always pass a repository mappingGravatar dannark2018-06-27
| | | | | RELNOTES: None PiperOrigin-RevId: 202360925
* Extract logic from CROSSTOOL in CrosstoolInfo providerGravatar rosica2018-06-21
| | | | | | | | | CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201491207
* Add "toolchain-identifier" attribute to cc_toolchain ruleGravatar rosica2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the selection of C++ toolchain configuration depends on 2 different things: 1. CROSSTOOL file: a proto text file that contains multiple CrosstoolConfig.CToolchain messages, out of which we want to select the appropriate CToolchain; 2. cc_toolchain_suite rule, specified by --crosstool_top option: this rule contains "toolchains" map attribute. The map's keys are of type <cpu>|<compiler>, or just <cpu>, and the values are labels of cc_toolchain rules (which contain additional C++ information). If there is an entry in cc_toolchain_suite.toolchains that corresponds to the --cpu and --compiler options, we use it, otherwise we loop through all the CToolchains in the CROSSTOOL file, select the one that corresponds to the --cpu and --compiler options, and then get the cc_toolchain label from cc_toolchain_suite.toolchains[toolchain.targetCpu|toolchain.compiler]. In both cases we read the CROSSTOOL file and pass all its information forward, to be used in creation of CppConfiguration and CcToolchainProvider creation. As part of the efforts of rewriting CROSSTOOL in Skylark, we need to make obtaining the cc_toolchain label independent of the CROSSTOOL file and toolchain selection. As a step towards that goal, we add a new "toolchain_identifier" attribute to cc_toolchain, which uniquely identifies a CToolchain in the CROSSTOOL file. Now the process of getting the CToolchain goes as follows: Check for existence of cc_toolchain_suite.toolchains[<cpu>|<compiler>], if --compiler is specified, otherwise check for cc_toolchain_suite.toolchains[<cpu>]. 1. if a value is found, load the cc_toolchain rule and look for the toolchain_identifier attribute. 1.a if the attribute exists, loop through all the CToolchains in CROSSTOOL and select the one with the matching toolchain identifier. 1.b otherwise fall back to selecting the CToolchain from CROSSTOOL by matching the --cpu and --compiler values. 2. If a value is not found, select the CToolchain from CROSSTOOL by matching the --cpu and --compiler values, and construct the key as follows: <toolchain.cpu>|<toolchain.compiler>. In the future we will get rid of 2. by making sure that cc_toolchain_suite.toolchains[<cpu>|<compiler>] and cc_toolchain_suite.toolchains[<cpu>] are always defined. 1.b will be removed by making the cc_toolchain.toolchain_identifier attribute mandatory After this deriving the cc_toolchain label will be independent of the CROSSTOOL file 1.a will ultimately be replaced by an attribute that points to a skylark_crosstool rule, that will contain all the information that CROSSTOOL contains, allowing us to remove CROSSTOOL altogether. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 200388550
* Modify cc_toolchain_suite rule to allow selection of cc_toolchain label ↵Gravatar rosica2018-05-30
| | | | | | | | | | | | | | | | without reading the CROSSTOOL file. As we want to reroute selecting the toolchain from CROSSTOOL through cc_toolchain, cc_toolchain_suite should have all the necesarry information for obtaining the cc_toolchain label without accessing the CROSSTOOL file. In order to do that, besides the existing <toolchain.targetCpu>|<toolchain.compiler>, we add <cpu> type of key in 'toolchains' attribute of cc_toolchain_suite. Now the selection of cc_toolchain label goes as follows: 1. Return toolchains[<cpu>|<compiler> if it exists 2. Return toolchains[<cpu>] if it exists 3. Fall back to the previous state: return toolchains[<toolchain.targetCpu>|<toolchain.compiler>] RELNOTES: None. PiperOrigin-RevId: 198588849
* Simplify config fragment creation.Gravatar gregce2018-05-02
| | | | | | | | | Remove all unnecessesary accesses to ConfigurationEnvironment and deprecate the accesses that actually need ConfigurationEnvironment. For review, check out ConfigurationFragmentFactory first. PiperOrigin-RevId: 195099768
* Make --fdo_optimize paths be PathFragment instead of Path, and remove the ↵Gravatar Googler2018-04-11
| | | | | | now unused ConfigurationEnvironment#getBlazeDirectories() PiperOrigin-RevId: 192443323
* Implement fdo_profile rule for architecture-sensitive fdo profile specificationGravatar Googler2018-04-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fdo_profile rule allows specifying architecture-sensitive fdo profiles. This is especially important in multi-architecture builds. Currently the profiles can only be labels of input files, but later on a way to support absolute files for profiles will be added. Example: fdo_profile( name = "profile", profile = select({ ":k8" : "//path/to/some/profile.zip", ":ppc": "//path/to/some/other/profile.afdo", }), ) config_setting( name = "k8", values = { "cpu": "k8", }, ) config_setting( name = "ppc", values = { "cpu": "ppc", }, ) RELNOTES: Introduce fdo_profile rule that allows architecture-sensitive specification of fdo profiles. PiperOrigin-RevId: 192125371
* Route --fdo_optimize information through an implicit dependency instead of ↵Gravatar Googler2018-02-13
| | | | | | | CppConfiguration RELNOTES: None. PiperOrigin-RevId: 185527875
* Adds a CODEC for CppConfiguration.Gravatar shahan2018-01-10
| | | | | | | * Creates an enum for cpu transformer, which is easier to serialize than an opaque function. This also means moving FakeCPU to avoid introducing a circular dependency. * Adds a CODEC to Path using InjectingObjectCodec. PiperOrigin-RevId: 181445911
* Add 'compiler' and 'libc' attributes to cc_toolchain. If platform/toolchainGravatar cpeyser2017-09-28
| | | | | | | resolution is used, use these attribute values to choose a CToolchain from --crosstool_top instead of --compiler and --glibc. PiperOrigin-RevId: 170217186
* Introduce --enabled_toolchain_types, which when set to the cpp toolchain ↵Gravatar cpeyser2017-09-20
| | | | | | causes the cc_toolchain dependency of cc targets to be selected using the platforms/toolchains constraint solving system. PiperOrigin-RevId: 169250621
* Automated g4 rollforward of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar gregce2017-06-05
| | | | | | | | | | | | | | | | | | | | | | | | (Automated g4 rollback of commit de92f9d8ea093416fae999073bbfcf3cf501ab55). *** Reason for rollback *** The problems that forced commit de92f9d8ea093416fae999073bbfcf3cf501ab55 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc . *** Original change description being rolled forward *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely.... *** ROLLBACK_OF=156180015 PiperOrigin-RevId: 157865224
* Automated g4 rollback of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar mstaib2017-05-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causes crash bug in certain circumstances. *** Original change description *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic... PiperOrigin-RevId: 156180015
* Automated g4 rollback of commit 6879d7ceff0e118fdecb0cabe5134979030b7cb8.Gravatar Googler2017-05-11
| | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Fixes memory issue that caused this CL to be rolled back. *** Original change description *** Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999. *** Reason for rollback *** Need to roll this back as part of http://b/38171368 *** Original change description *** RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements. PiperOrigin-RevId: 155651879
* Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999.Gravatar Googler2017-05-10
| | | | | | | | | | | *** Reason for rollback *** Need to roll this back as part of http://b/38171368 *** Original change description *** RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements. PiperOrigin-RevId: 155547813
* RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to ↵Gravatar Googler2017-05-09
| | | | | | use select statements. PiperOrigin-RevId: 155480011
* Implement dynamically configured LIPO builds.Gravatar gregce2017-05-04
| | | | | | | | | | | | | | | Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic LIPO can be triggered with --experimental_dynamic_configs=notrim. PiperOrigin-RevId: 155096056
* Change Bazel's LIPO model to support dynamic configurations.Gravatar gregce2017-04-19
| | | | | | | | | | The key change is to eliminate the need to transition from the data to the target configuration by relying on out-of-band configuration state. Specifically, the old model drops LIPO options from the data configuration. In the cases when we have to switch back (i.e. TARGET_CONFIG_FOR_LIPO), those options have to get re-injected somehow. Static configurations achieve this with the global configuration transitions table. But dynamic configs have no comparable source (and they consciously eschew global state). This cl changes the model to *keep* LIPO settings in the data config, then use a new "enableOrDisable" flag to determine whether or not to actually use them. With this model, the data -> target transition is now as simple as toggling that flag. This change doesn't actually add dynamic config LIPO support. It's doing enough as it is, and we need to make sure it doesn't break existing LIPO semantics. Dynamic support will come as a followup. PiperOrigin-RevId: 153504240
* RELNOTES[NEW]: If grte_top is a label, it can now follow non-configurable ↵Gravatar Googler2017-03-21
| | | | | | | | redirects. -- PiperOrigin-RevId: 150647389 MOS_MIGRATED_REVID=150647389
* Support aliases in the --experimental_stl attribute.Gravatar Lukacs Berki2017-03-20
| | | | | | -- PiperOrigin-RevId: 150610613 MOS_MIGRATED_REVID=150610613
* Add option to disable dynamic configs with LIPO.Gravatar Greg Estren2016-12-02
| | | | | | | | | | | | New option --experimental_dynamic_configs=notrim_partial automatically switches to --experimental_dynamic_configs=off if any BuildOptions fragment sets useStaticConfigurationsOverride(). CppOptions implements this override for FDO/LIPO. -- PiperOrigin-RevId: 140864317 MOS_MIGRATED_REVID=140864317
* Split dynamic configurations mode into:Gravatar Greg Estren2016-09-22
| | | | | | | | | | | | | | | --experimental_dynamic_configs=off - don't use dynamic configs --experimental_dynamic_configs=on - use dynamic configs with trimmed fragments --experimental_dynamic_configs=notrim - use dynamic configs with all fragments This lets us decouple two independent dimensions of dynamic configurations: 1) being able to trigger new configurations and transitions anywhere and 2) only including the fragments needed by a target's transitive closure. 2) is likely to take much more time and effort to properly finesse (three notable challenges: late-bound attributes, aspects, and dynamic shedding of output path names). But 1) by itself already yields significant benefits. So in the name of starting to shift the config work from backend theory to stuff real builds actually use, this change lets us focus on productionizing 1) without blocking on getting all of 2) working first. tl;dr: iterable deployment and all that. -- MOS_MIGRATED_REVID=133874661
* Remove support for filegroup-based C++ toolchains:Gravatar Lukacs Berki2016-09-07
| | | | | | | RELNOTES[INC]: filegroup-based C++ toolchains are not supported anymore. --*_crosstool_top options must always point to a cc_toolchain_suite rule (or an alias of one). -- MOS_MIGRATED_REVID=132410829
* Allow Skyframe graph lookups and value retrievals to throw InterruptedException.Gravatar Janak Ramakrishnan2016-08-16
| | | | | | | The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer. -- MOS_MIGRATED_REVID=130327770
* Remove the unused field CppConfiguration.execRoot.Gravatar Lukacs Berki2016-05-19
| | | | | -- MOS_MIGRATED_REVID=122727524
* Adds the compiler to the key for selecting the cc_toolchain label inGravatar Alex Humesky2016-05-04
| | | | | | | | | | | cc_toolchain_suite. This will allow selecting the correct toolchain based on --compiler / --android_compiler. RELNOTES: The key for the map to cc_toolchain_suite.toolchains is now a string of the form "cpu|compiler" (previously, it was just "cpu"). -- MOS_MIGRATED_REVID=121418076
* Introduces apple_cc_toolchain.Gravatar Cal Peyser2016-03-17
| | | | | -- MOS_MIGRATED_REVID=117361388
* Properly report loading errors during configuration creation.Gravatar Ulf Adams2016-02-10
| | | | | | | | | | | | | | | | | This only applies to interleaved loading and analysis - the production code is fine. Add tests for the RedirectChaser, the fdoOptimize code path, the XcodeConfig, and the Jvm loader. Unfortunately, the configuration factory we internally create by default contains a mock Jvm loader implementation. Since that is one Yak too many right now, I'm adding a temporary method to the AnalysisMock. I added the tests to BuildViewTest for now; technically, they ought to go into the language-specific test cases, but that would require more refactoring as those don't currently run with interleaved loading and analysis. -- MOS_MIGRATED_REVID=114221476
* Clean up the configuration-related code paths a bit.Gravatar Ulf Adams2015-12-11
| | | | | | | | | - If we have a class object available, we can use .cast(Object) - Only store the required options objects in CppConfigurationParameters rather than keeping the entire BuildOptions -- MOS_MIGRATED_REVID=109981236
* Add a custom converter to --crosstool_top so that select() works.Gravatar Lukacs Berki2015-10-08
| | | | | -- MOS_MIGRATED_REVID=104845397
* Add a Constants.TOOLS_PREFIX constant that will serve to redirect the Bazel ↵Gravatar Lukacs Berki2015-10-05
| | | | | | | | | | | tools repository. This is a no-op refactoring CL. The actual switch will be made once everything passes with the new setup. As a side cleanup, change the awkward realAndroidSdk() / realAndroidCrosstoolTop() mechanism to a converter. -- MOS_MIGRATED_REVID=104649067
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | 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. -- MOS_MIGRATED_REVID=103938715
* Move Label from the lib.syntax to the lib.cmdline package so that:Gravatar Lukacs Berki2015-09-21
| | | | | | | | | | - Label parsing can be simplified - lib.syntax is only contains the code for Skylark and is reasonably independent from the problem domain of building things This change is mostly only changes to imports declarations. The rest is reversing the dependency between :cmdline and :syntax and moving a tiny amount of code between Printer and FilesetEntry and the addition of SkylarkPrintableValue that I couldn't be bothered to separate out into its own change. -- MOS_MIGRATED_REVID=103527877
* Separate build-specific types and types inherent to Skylark.Gravatar Lukacs Berki2015-09-21
| | | | | -- MOS_MIGRATED_REVID=103374106
* Parse the label syntax "@//a:b" so that eventually we can make that the ↵Gravatar Lukacs Berki2015-09-15
| | | | | | | | | syntax that means "refer to the main repository". There isn't an overarching plan for what we are going to do with the cmdline package, which seems to be separated from the .syntax one in all sorts of awkward ways. -- MOS_MIGRATED_REVID=103088960
* Implement the core structure for dynamic configurations.Gravatar Greg Estren2015-08-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a big change, so let me walk you through the key pieces: 1) This cl provides an alternative mechanism for creating configurations and doing configuration transitions that's "dynamic" in that the configurations can be created on the fly and the transitions are arbitrary mappings from BuildOptions --> BuildOptions that can also be created on the fly. It also integrates this with ConfiguredTargetFunction, so the configured target graph automatically uses this framework. 2) It does *not* replace old-style (which we'll call "static") configurations. For a number of important reasons: It's not yet at feature parity (particularly: no LIPO). It's not remotely tested across real projects enough to have confidence that it's battle-ready. It doesn't yet handle certain "special" functions like BuildConfiguration.prepareToBuild() and BuildConfiguration.getRoots(). It still relies on the old static transition logic to determine what transitions to apply (eventually we'll distribute that logic out, but that's too much for a single cl). We need the option to toggle it on and off until we have enough confidence in it. So with this cl, builds can be done in either mode. 3) The new flag --experimental_dynamic_configs toggles use of dynamic configurations. 4) Dynamic configurations are created with the Skyframe function BuildConfigurationFunction (this was already created in an earlier change). This consumes a BuildOptions and a set of configuration fragments to produce a BuildConfiguration. 5) Dynamic transitions are instances of the new class PatchTransition, which simply maps an input BuildOptions to an output BuildOptions. 6) Since static and dynamic configurations have to co-exist (for now), this cl tries hard to keep today's transition logic defined in a single place (vs. forking a dedicated copy for each configuration style). This is done via the new interface BuildConfiguration.TransitionApplier. BuildConfiguration.evaluateTransition is modified to feed its transition logic into TransitionApplier's common API. Both dynamic and static configurations have their own implementations that "do the right thing" with the results. 7) The transition applier for dynamic configurations basically stores the Transition, then allows DependencyResolver (which calls BuildConfiguration.evaluateTransition) to return Dependency instances containing that Transition (vs. a BuildConfiguration, which they traditionally contain). 7.5) An earlier variation of the dynamic transition applier retained BuildOptions (e.g. when it got a Transition it immediately applied it to get its output BuildOptions, then stored that). This had the advantage of making composing of transitions easier, especially within BuildConfiguration.evaluateTransition (which can theoretically apply multiple transitions to the input configuration). But it turns out that applying transitions has a cost, and it's simply more performant to pass them through until they're really needed. 8) In dynamic configuration mode, after ConfiguredTargetFunction gets its deps (e.g. an <Attribute, Dependency> multimap), it "trims" the configurations for its dependencies by a) only including config fragments required by the deps' subtrees and b) applying the transitions that came from 7). This all happens in the new method ConfiguredTargetFunction.trimConfigurations. 9) trimConfigurations is heavily performance-optimized based on a lot of experience running this through a large project within Google. As it turns out, the cost of host transitions can be atrocious (because there are a lot of them). Also, BuildOptions.clone() is expensive. And just creating BuildConfiguration SkyKeys also has a cost (largely because of BuildOptions cloning), so that shouldn't be done except when really necessary. My experience with this convinced me it's worth making this method complicated for the sake of making it fast. Since it basically visits every edge in the configured target graph (at least), it really needs to be slick. 10) Since host transitions in particular are problematic w.r.t. speed, I compute the host *once* in ConfigurationCollectionFunction.getHostConfiguration() and expose that reference to ConfiguredTargetFunction and other Skyframe functions. This limits recomputation to just when the fragments are trimmed. 11) Since options cloning is expensive, I'm doing something scary: exposing a BuildConfiguration.getOptions() method that returns a direct reference. Since BuildOptions is mutable, this is dangerous in the wrong hands. I can experiment with going back to cloning (with the caching of host transitions it may not matter as much), but we may ultimately have to put up with this risk for the sake of performant analysis time. What would be *really* awesome would be to make BuildOptions immutable. But that's not going to happen in this cl. So in short, the key abstractions in this cl are: - PatchTransition - BuildConfiguration.TransitionApplier - ConfiguredTargetFunction.trimConfigurations The current implementation imposes no analysis time penalty -- MOS_MIGRATED_REVID=101474620
* Tolerate "..." as the base filename for the fdo profile.Gravatar Janak Ramakrishnan2015-07-10
| | | | | | | This is fragile, and there might be other places in the codebase this issue occurs. -- MOS_MIGRATED_REVID=97784977
* Make it possible to put the Crosstool proto in BUILD files.Gravatar Lukacs Berki2015-06-09
| | | | | | | This is needed so that Bazel can access Android NDK if it's outside of the workspace. The current limitation is that we Bazel can pretend that there is a BUILD file there, but cannot do the same with a CROSSTOOL file. We could fix that limitation, but given that Crosstool is the only conceivable use case, let's fix it by changing the Blaze-Crosstool interface. -- MOS_MIGRATED_REVID=95517408
* Have ConfiguredTargetFactory subclasses declare which FragmentOptionsGravatar Greg Estren2015-05-21
| | | | | | | | | | | | | | | | | | | | | | they need to create their fragments. This is prerequisite work for fragment-limited configurations (configurations that only include the fragments needed by their rules' transitive closures). Given a set of desired fragment classes, we need to know which FragmentOptions are needed to instantiate those fragments. Note that we can't map this relationship the other way (given a set of FragmentOptions, which fragment classes do they load?). That's because different fragment loaders may consume overlapping options. A good example is CppOptions, which is, e.g., used by both the C++ and Python configuration loaders. At some point, we're probably going to want to force configuration loaders to only understand options from their own "domain" (or have well-defined hierarchies). But that's not the reality of today. -- MOS_MIGRATED_REVID=94091093
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-15 00:04:12 +0000