aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/config/BuildOptions.java
Commit message (Collapse)AuthorAge
* Lazily construct Preconditions failure message. Mistake from ↵Gravatar janakr2018-08-02
| | | | | | https://github.com/bazelbuild/bazel/commit/129c3e2fd3dfdfe1cd312826988f0944bdd69236. PiperOrigin-RevId: 207140930
* Automated rollback of commit db01c6f926bcb4774d901797c59f51dd54c05624.Gravatar janakr2018-07-27
| | | | | | | | | | *** Reason for rollback *** Rolling forward with fixes. *** Original change description *** PiperOrigin-RevId: 206339696
* PiperOrigin-RevId: 206181674Gravatar shahan2018-07-26
|
* Read a byte array instead of a certain number of bytes that are indicated by aGravatar mjhalupka2018-07-12
| | | | | | | preceding integer when serializing BuildOptions.DiffForReconstruction. Reorder the cache map inserts due to a subtle race condition that can occur. PiperOrigin-RevId: 204376273
* Move caching to BuildOptions instead of BuildConfigurationValue.Key.Gravatar mjhalupka2018-07-11
| | | | PiperOrigin-RevId: 204154609
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Make BuildOptions$OptionsDiffForReconstruction deterministic in its ↵Gravatar janakr2018-05-23
| | | | | | construction. Also restrict visibility of some test-only OptionsDiff methods, and remove a server-specific part of the ConfiguredTargetKey #toString representation. PiperOrigin-RevId: 197830577
* Pull caching up to BuildConfigurationValue$Key$Codec. Almost all ↵Gravatar janakr2018-05-14
| | | | | | | | BuildOptions$DiffForReconstruction serializations are reached in this way, so we get better efficiency. Also, it was already a custom codec, so less new handrolling. Also use serialization framework for FragmentClassSet, instead of doing serialization directly. Default FragmentClassSet should be a constant, so it will serialize down to a byte or three. Future changes can make all the classes constants as well, if we're getting misses on them. PiperOrigin-RevId: 196546279
* Only use fingerprint and checksum for equality and hashCode in ↵Gravatar janakr2018-05-14
| | | | | | BuildOptions$OptionsDiffForReconstruction. The fingerprint uniquely identifies the "baseline" BuildOptions object and the checksum uniquely identifies the "overlay", so we don't need to incorporate the rest of the data. PiperOrigin-RevId: 196532013
* Add an IdentityHashMap to the BuildOptions.OptionsDiffForReconstruction codec.Gravatar mjhalupka2018-05-11
| | | | PiperOrigin-RevId: 196310244
* Change BuildOptions.DiffForReconstruction.toString() to use MoreObjects insteadGravatar mjhalupka2018-04-12
| | | | | | of a StringBuilder. PiperOrigin-RevId: 192681870
* Add a toString method to BuildOptions and BuildConfigurationValue.KeyGravatar mjhalupka2018-04-11
| | | | PiperOrigin-RevId: 192479952
* Put configuration checksum into BuildOptions$OptionsDiffForReconstruction ↵Gravatar janakr2018-03-28
| | | | | | | | and make it available to ConfiguredTarget. Also give BuildConfigurationValue.Key the same toString() that BuildConfiguration had, so we recover how we used to print out ConfiguredTarget labels in debugging. This may have a tiny bit of overhead in serialization, but we'll cross that bridge when we come to it. Could just make the string a constant. PiperOrigin-RevId: 190787145
* Create a new output formatter for cquery which output transition information ↵Gravatar juliexxia2018-03-23
| | | | | | in either a FULL or LITE version. Trigger new output with the new --transitions cquery flag in the new CqueryOptions class. PiperOrigin-RevId: 190278664
* Add a DefaultBuildOptions specifying default build flags that may differ ↵Gravatar mjhalupka2018-03-22
| | | | | | from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys. PiperOrigin-RevId: 190117455
* RELNOTES[INC]: Remove //tools/defaults:android_jar. Use ↵Gravatar ajmichael2018-03-19
| | | | | | | | | | @bazel_tools//tools/android:android_jar instead. Bazel 0.11 release notes mentioned deprecating //tools/android:android_jar, and Bazel 0.12 has already been cut. So I think Bazel 0.13 is a reasonable time to remove it. Also, delete the machines for configuration fragments adding rules (not labels) to the //tools/defaults package. //tools/defaults:android_jar was the only user. PiperOrigin-RevId: 189628217
* Add the ability to reconstruct a BuildOptions from the diff with another ↵Gravatar janakr2018-03-09
| | | | | | BuildOptions. Motivation is that the diffs are likely to be much smaller than the actual BuildOptions objects themselves, so in places we need a BuildOptions (I'm looking at you, BuildConfigurationValue.Key), we can instead store a diff, reconstructing the BuildOptions object itself on demand when needed. PiperOrigin-RevId: 188511251
* Convert a bunch of non-AutoCodec classes to use @AutoCodec: ↵Gravatar janakr2018-03-06
| | | | | | BuildConfiguration, BuildOptions, CollectTargetsUnderDirectoryValue. PiperOrigin-RevId: 188059815
* Deletes CODEC fields now that they are no longer needed.Gravatar shahan2018-02-28
| | | | PiperOrigin-RevId: 187397314
* Add a new BuildOptions diff method that holds and pretty prints the ↵Gravatar juliexxia2018-02-23
| | | | | | different option values between two BuildOptions PiperOrigin-RevId: 186769975
* Deletes POLYMORPHIC strategy. ObjectCodec now uses runtime type information ↵Gravatar shahan2018-02-20
| | | | | | to select a codec. PiperOrigin-RevId: 186378153
* Add context argument to ObjectCodec.{serialize,deserialize}Gravatar michajlo2018-02-11
| | | | | | | | | | Context implementations are currently empty, just doing the plumbing in this change. Once this is in we can start passing along the ObjectCodecRegistry, which will allow runtime codec resolution for classes not known at compile time. We'll also inevitably add some memoization helpers, allowing us to optimize the serialization process further. PiperOrigin-RevId: 185305674
* Adds ObjectCodecs for FragmentOptions and BuildOptions.Gravatar Googler2017-12-27
| | | | PiperOrigin-RevId: 180211710
* Memoize equals and hashCode operations for BuildOptions. Currently, equality ↵Gravatar janakr2017-12-24
| | | | | | is so slow that if we have to compare many of them, the build can basically never finish. This is needed for a follow-up in which BuildOptions are part of many SkyKeys. PiperOrigin-RevId: 180056834
* Move config transition definitions out of lib.packages.Attribute.Gravatar gregce2017-12-21
| | | | | | | | | | | | | This cleans up a legacy API from Bazel's "static configuration" days, when transition definitions involved deep and complex logic in the analysis code. That was too much cruft to embed into lib.packages. But the modern definitions are way simpler and thus easier to embed. This change only *copies* the existing definitions. Because a lot of references will have to be updated, we'll migrate the move over a few changes. PiperOrigin-RevId: 179859293
* Remove outdated javadoc parameter.Gravatar gregce2017-11-16
| | | | PiperOrigin-RevId: 176006176
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Remove the unused fallback argument from getHost() and the unused method ↵Gravatar lberki2017-09-12
| | | | | | | getPotentialSplitTransitions() from FragmentOptions. RELNOTES: None. PiperOrigin-RevId: 168218102
* Remove --experimental_dynamic_configs=notrim_partial.Gravatar gregce2017-07-26
| | | | | | Part of the static configuration removal cleanup. PiperOrigin-RevId: 163130922
* Remove FragmentOptions' addAllLabels and getAllLabels and friends.Gravatar mstaib2017-07-07
| | | | | | | | These are now dead code - configuration dependencies are loaded by Skyframe and do not need to be listed ahead of time - and were only ever used in tests. PiperOrigin-RevId: 161146721
* Move InvocationPolicy to the options parser package.Gravatar ccalvarin2017-06-09
| | | | | | | | | | | | | | It was originally included in runtime due to external dependencies, and a desire to keep the options parser a general options library. These dependencies have been or will be removed, and there are plenty of other general flag libraries. InvocationPolicy is fundamentally acting on the properties of this specific OptionsParser and needs proper access to it for the proper solution to a number of existing bugs, which means having access to things that should be package private. PiperOrigin-RevId: 158523111
* BuildOptions cleanup:Gravatar gregce2017-05-04
| | | | | | | | | | | | | | | | | | | | | 1) Remove obsolete originalOptions field. This was originally added to support "parent" transitions, which supported config1 -> config2 -> config1 transitions by having config2 store config1's options. The purpose of this feature was to support LIPO (which has a DATA -> TARGET transition). But https://github.com/bazelbuild/bazel/commit/ff29c0b39cf936a2699b05edd54f483f1a037d93 makes this unnecessary. 2) Support the "disable actions" feature of the LIPO context collector configuration. Putting this in BuildOptions make this dynamic config-compatible. This change intentionally doesn't add disableOptions to BuildOptions.equals() or BuildOptions.hashCode(). It'd be great to do that. But that has semantic consequences. And we've run into really tricky bugs in the past with dynamic configurations and BuildOptions.equals / BuildConfiguration.equals. So it's best to experiment with that in its own change. PiperOrigin-RevId: 154999718
* Make a rogue test case honor --experimental_dynamic_configs=notrim_partial ↵Gravatar Greg Estren2016-12-05
| | | | | | | | | | like everywhere else. Unfortunately this doesn't use ConfiguredRuleClassProvider to prepare its configuration's BuildOptions like every other code path does. -- PiperOrigin-RevId: 140873428 MOS_MIGRATED_REVID=140873428
* 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
* When BuildOptions.get(Class<T> optionsClass) fails, include whichGravatar Greg Estren2016-05-23
| | | | | | | | | fragment was requested in the NullPointerException message. This helps diagnose dynamic configuration errors. -- MOS_MIGRATED_REVID=122855814
* Always apply invocation policy when constructing build options.Gravatar Janak Ramakrishnan2016-03-24
| | | | | -- MOS_MIGRATED_REVID=117939121
* 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
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* LipoDataTransition is only meaningful for C++Gravatar Greg Estren2015-11-18
| | | | | | | | | | | | options. If a rule (such as a filegroup) doesn't have C++ options in its transitive closure, then buildOptions.get(CppOptions.class) returns null and crashes. So add a check to just fast-return for these cases. -- MOS_MIGRATED_REVID=108079561
* Provide a looser concept of BuildConfiguration "equality" to accountGravatar Greg Estren2015-11-12
| | | | | | | | | | | | | | | | | for dynamic configurations. In short, as a configuration gets passed down its dependency tree it's likely to lose fragments. For example, when a java_library depends on a cc_library, the former has both JavaConfiguration and CppConfiguration while the latter only has CppConfiguration. It's still the "same" configuration in both cases, it's just that it got trimmed. This cl provides a looser concept of BuildConfiguration equality that accounts for this. -- MOS_MIGRATED_REVID=107598262
* 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
* 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
* Add a mechanism for configuration fragments to add arbitrary rules to the ↵Gravatar Lukacs Berki2015-05-07
| | | | | | | defaults package. -- MOS_MIGRATED_REVID=93023029
* Rollback of commit a4b66fdbe61845fd4d4ebaebec1e25cdcd99809d.Gravatar Marian Lobur2015-04-27
| | | | | | | | | | | | | *** Reason for rollback *** Breaks android targets in our nightly: [] *** Original change description *** Add a mechanism for configuration fragments to add arbitrary rules to the defaults package. -- MOS_MIGRATED_REVID=92144505
* Add a mechanism for configuration fragments to add arbitrary rules to the ↵Gravatar Lukacs Berki2015-04-24
| | | | | | | defaults package. -- MOS_MIGRATED_REVID=91956723
* Some cleanup changes.Gravatar Ulf Adams2015-03-05
| | | | | -- MOS_MIGRATED_REVID=87821306
* 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-07-03 16:29:17 +0000