aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/ConfiguredTargetFactory.java
Commit message (Collapse)AuthorAge
* Remove all callers of ArtifactRoot.asSourcePath from production code besides ↵Gravatar janakr2018-04-11
| | | | | | | | the ones in SkyframeExecutor, called once for each Root in the package path list. This ensures there is a single canonical ArtifactRoot for each source root. It is still the case that every Package loaded has its own Root (https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/packages/Package.java;l=287?q=Package.java), which is a waste of memory, but because of the map inside ArtifactFactory introduced in this change, all Artifacts with the same logical source root share a single ArtifactRoot instance. PiperOrigin-RevId: 192513819
* Move shell executable to its own configuration fragment.Gravatar lberki2018-04-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 191861074
* 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
* Replace ConfiguredTargetAndData#getConfiguredTarget()#getConfiguration() ↵Gravatar janakr2018-03-10
| | | | | | with ConfiguredTargetAndData#getConfiguration(). Done using intellij structural replace. PiperOrigin-RevId: 188618282
* Add BuildConfiguration to ConfiguredTargetAndTarget and rename it to ↵Gravatar janakr2018-03-10
| | | | | | ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized. PiperOrigin-RevId: 188600002
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint. Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon. RELNOTES: None. PiperOrigin-RevId: 188098079
* @AutoCodec all the *ConfiguredTarget classes except for ↵Gravatar janakr2018-02-23
| | | | | | | | | | RuleConfiguredTarget. RuleConfiguredTarget is harder, and will be handled in a follow-up. Also remove duplicate field from InputFileConfiguredTarget and unused parameter in EnvironmentGroupConfiguredTarget constructor. Largely punt on FilesetOutputConfiguredTarget for now, but will handle soon. PiperOrigin-RevId: 186829768
* Change ConfiguredAspectFactory.create signature to take in aGravatar mjhalupka2018-01-31
| | | | | | | ConfiguredTargetAndTarget instead of a ConfiguredTarget. This is to assist in deprecating ConfiguredTarget.getTarget(). PiperOrigin-RevId: 184043491
* Add alternative interface for LIPO data transitions, opt in native rules.Gravatar gregce2018-01-29
| | | | | | | | | | | This removes the need for ConfigurationTransitionProxy.DATA by providing a way for the C++ rule defs to directly inject the transition for all rules to use. Skylark attributes work differently, so they'll be addressed in another change. PiperOrigin-RevId: 183721293
* Start the process of getting Target out of ConfiguredTarget: add a new ↵Gravatar janakr2018-01-18
| | | | | | | | | | | | container, ConfiguredTargetAndTarget, that can be used to access Targets, and deprecate ConfiguredTarget#getTarget. ConfiguredAndTargetObjects are intended to be limited in scope, not being persisted to Skyframe. The eventual plan is to remove the target field from ConfiguredTarget. This CL is mostly straightforward, except for dealing with AliasConfiguredTargets, which cause some complications. A significant cleanup is still needed before #getTarget can be removed, but I don't see any impossible blockers. We will may still need to store a Target-like object in ConfiguredTarget (that has the RuleClass, or at least a string representation of it, for instance), but that will let us avoid storing a full Target together with its associated Package. PiperOrigin-RevId: 182371566
* Rename Root to ArtifactRoot.Gravatar tomlu2018-01-16
| | | | | | This is slightly more descriptive, and we will potentially want to use the name Root for a broader concept shared between ArtifactRoot and RootedPath. PiperOrigin-RevId: 182082367
* Remove isMainRepo from Root.Gravatar tomlu2018-01-12
| | | | | | This is no longer used. PiperOrigin-RevId: 181754475
* Convert ActionLookupKey implementations to directly implement SkyKey, ↵Gravatar janakr2018-01-11
| | | | | | removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason. PiperOrigin-RevId: 181658615
* Move PatchTransition and kin to analysis.config.transitions.Gravatar gregce2018-01-04
| | | | | | | HostTransition can't be migrated yet because it depends on BuildConfiguration. PiperOrigin-RevId: 180842784
* Aspects-on-aspect see and propagate over aspect attributes.Gravatar dslomov2017-12-20
| | | | | | | | | | | If an aspect is applied to a rule+aspect node, all attributes are merged into ctx.rule.attr collection, and the first one with the same name wins (in particular, rule attribute will always win over aspect attribute). This is backwards-compatible, and unlikely to cause problems in practice. RELNOTES: Aspects-on-aspect see and propagate over aspect attributes. PiperOrigin-RevId: 179675660
* Added new RuleClass flag to turn off platform support, to stop dependency ↵Gravatar John Cater2017-11-21
| | | | | | | | | cycles when loading platforms. Part of #4128. Change-Id: Ie55a91aaaec15d8eb537f59131fc2e69a8f9c251 PiperOrigin-RevId: 176509311
* Refactor the representation of a collection of package specificationsGravatar cushon2017-11-15
| | | | PiperOrigin-RevId: 175832159
* 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
* Add memory profiler.Gravatar tomlu2017-10-18
| | | | | | | | | | | This adds two dump command, bazel dump --rules and bazel dump --skylark_memory. dump --rules outputs a summary of the count, action count, and memory consumption of each rule and aspect class. dump --skylark_memory outputs a pprof-compatible file with all Skylark analysis allocations. Users can then use pprof as per normal to analyse their builds. RELNOTES: Add memory profiler. PiperOrigin-RevId: 172558600
* Project reorg: move *ConfiguredTarget to new configuredtargets/ pathGravatar gregce2017-09-18
| | | | | | | Exempt RuleConfiguredTarget in this change because that's liable to touch a billion files. PiperOrigin-RevId: 168929827
* Remove ConfigurationCollection{Function,Value}, ↵Gravatar gregce2017-08-18
| | | | | | | | BuildConfigurationCollection.Transitions. Part of the static config cleanup effort. PiperOrigin-RevId: 165607492
* Move FilesetProvider to lib.analysis.filesetGravatar ulfjack2017-08-09
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164701931
* Move the Skylark rule infrastructure from lib.rules to lib.analysis.skylarkGravatar ulfjack2017-08-09
| | | | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. Unfortunately, there are a number of reverse deps from analysis code to Skylark classes, so moving these is the only way to make progress. PiperOrigin-RevId: 164612957
* Use toolchain resolution in rule creation.Gravatar John Cater2017-07-21
| | | | | | | Part of #2219. Change-Id: Id4929d5ddcd57b4635af5e513eb9a09f16a78e71 PiperOrigin-RevId: 162634398
* Fix declared providers behaviorGravatar vladmos2017-07-14
| | | | | | | | | DefaultInfo used to not be used when old-style and declared providers were mixed (struct=(custom='key', providers=[DefaultInfo(...)])). Also when a single declared provider was returned it used to be treated as an old-style struct. PiperOrigin-RevId: 161796415
* Use the same data structure for native and Skylark providers.Gravatar dslomov2017-07-05
| | | | | | | | | The memory cost of adding Skylark provider is now the same as native. Skylark providers (declared and legacy) benefit from the same shape-sharing optimization as native providers. RELNOTES: None. PiperOrigin-RevId: 160944263
* 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
* Add toolchains attribute to aspect.Gravatar John Cater2017-05-26
| | | | | | | Part of #2219. Change-Id: I39ced1f3e2605154771df9424d6ed2f971820baf PiperOrigin-RevId: 157002268
* 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
* 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
* Do not put OutputGroupProvider into SkylarkProviders.Gravatar dslomov2017-05-03
| | | | | | | | | Almost every target has an OutputGroupProvider. Putting an ("output_groups", value) pair into SkylarkProviders creates an unneccessary map. This CL removes it. RELNOTES: None. PiperOrigin-RevId: 154940624
* Make Skylark interpreter read Skylark command-line flagsGravatar brandjon2017-04-30
| | | | | | | | | | | This is the second of two CLs for making command line options able to affect the Skylark interpreter. For the main kinds of evaluation contexts -- package loading, .bzl loading, rule analysis, aspect analysis, and computed defaults -- the SkylarkSemanticsOptions object is retrieved from Skyframe and passed along to the Environment builder. For other contexts such as tests, default values of builtin functions, and standalone Skylark, flags are currently not processed. In the future, we may want to split into separate files the options that affect "pure" Skylark vs the options that affect Bazel-flavored Skylark. One possibility is to subclass SkylarkSemanticsOptions into SkylarkBazelSemanticsOptions, and go through an indirection in SkylarkUtils. We could also pass SkylarkSemanticsOptions to the parser, to support --incompatible_* changes that alter Skylark's syntax. I don't think that's needed at the moment. RELNOTES: None PiperOrigin-RevId: 154628391
* Aspect propagation should not lose transitively-visible aspects.Gravatar dslomov2017-04-11
| | | | | | | | If aspect a3 sees aspect a2, and aspect a2 sees aspect a1, propagation of the aspect list [a1,a2,a3] should not lose any aspects. RELNOTES: None. PiperOrigin-RevId: 152786900
* Support declared providers in AdvertisedProviderSet.Gravatar Dmitry Lomov2017-03-06
| | | | | | -- PiperOrigin-RevId: 149165836 MOS_MIGRATED_REVID=149165836
* Rollback of commit 4b73e972d909bcd533f2f9940f95a00b9b73bdde.Gravatar Dmitry Lomov2017-02-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Broke tests on CI: http://ci.bazel.io/job/bazel-tests/570/ *** Original change description *** Roll forward execroot change RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Cust... -- PiperOrigin-RevId: 147833177 MOS_MIGRATED_REVID=147833177
* Roll forward execroot changeGravatar Kristina Chodorow2017-02-16
| | | | | | | | | | | | | | | | | RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Custom crosstools that hardcode external/<repo> paths will have to be updated. Issue #1262. -- PiperOrigin-RevId: 147726370 MOS_MIGRATED_REVID=147726370
* Allow aspects to adveritise providers they provide.Gravatar Dmitry Lomov2017-02-07
| | | | | | -- PiperOrigin-RevId: 146794883 MOS_MIGRATED_REVID=146794883
* Names of extra-action protos now take into account all aspect names.Gravatar Dmitry Lomov2016-12-16
| | | | | | | | | | | | | If an Aspect registered an action that an extra-action is shadowing, its name is used when creating the extra-action's ID and name. Since recently, an aspect can see other aspects applied to the same target. This CL record the names of other aspects applied to the target as well, disambiguating the action owners. -- PiperOrigin-RevId: 142264153 MOS_MIGRATED_REVID=142264153
* Aspects-on-aspects implementation.Gravatar Dmitry Lomov2016-11-15
| | | | | -- MOS_MIGRATED_REVID=139189444
* Expose aspect-related information in the extra-action proto that Bazel hands ↵Gravatar Carmi Grushko2016-11-11
| | | | | | | | | to action_listener() rules. RELNOTES: Extra actions now contain aspect-related information. -- MOS_MIGRATED_REVID=138832922
* Rollback of commit 82d43279f93d95e4c41b4bc598a3cc05ddd1ae1a.Gravatar Laszlo Csomor2016-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks TensorFlow and other Bazel jobs on ci.bazel.io *** Original change description *** Change execution root for external repositories to be ../repo Some of the important aspect of this change: * Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name). * Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository). * Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl. Fixes #1262. RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Roll forward of bdfd58a. -- MOS_MIGRATED_REVID=133709658
* Change execution root for external repositories to be ../repoGravatar Kristina Chodorow2016-09-20
| | | | | | | | | | | | | | | | | | | | | | | Some of the important aspect of this change: * Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name). * Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository). * Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl. Fixes #1262. RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Roll forward of bdfd58a. -- MOS_MIGRATED_REVID=133606309
* Add an "is main repo" field to RootsGravatar Kristina Chodorow2016-09-09
| | | | | | | This is part of prepping for #1262. -- MOS_MIGRATED_REVID=132553178
* Changes DependencyResolver <Attribute, Dep> map from a ListMultimap to new classGravatar Greg Estren2016-08-12
| | | | | | | | | | | | | | | | | | | | | | OrderedSetMultimap. This maintains insertion order while eliminating duplicates. Certain rules, in particular, otherwise break this invariant: https://github.com/bazelbuild/bazel/blo[]e3e28274cca5b87f48abe33884edb84016dd3/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L403 There's no reason (to my knowledge) to need multiple instances of the same <Attribute, Dependency> pair. More context from Google code review: (Michael Staib): > There are many things which pass around a dependentNodeMap or help construct one or modify one. We want an interface which has the right guarantees. > ListMultimap is not the right interface because it has no guarantee of unique elements, which we want - we don't want the problem that this CL ran into, and there's no reason (that we know of, to be confirmed) that anyone would want multiple identical Dependencies. > SetMultimap is not the right interface because it has no guarantee of deterministic iteration order or efficient iteration, which we want - dependency order sometimes matters (e.g., Java classpath or C++ link order). > We agreed that the best way to get what we want is to define our own interface with its own simultaneous uniqueness and iterability guarantees. Unspoken in the discussion was why we wouldn't just use LinkedHashMultimap as the thing we pass around. IMO the reason for that is that we don't care that it be a LinkedHashMultimap specifically; if tomorrow Guava comes out with a faster cooler map that has deterministic and efficient iteration and guarantees element uniqueness, we want it. > In this case we're going to make the "interface" be a (final?) class: OrderedSetMultimap, an extension of ForwardingSetMultimap which delegates to LinkedHashMultimap, an implementation which does support both of those guarantees. > I had mentioned in the conversation that none of the Multimap implementations make guarantees about key iteration order, but this is not true - LinkedHashMultimap preserves key insertion order. We should perhaps declare this as part of the OrderedSetMultimap contract as well. -- MOS_MIGRATED_REVID=130037643
* Add the repository name as a parameter to the output path functionsGravatar Kristina Chodorow2016-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This doesn't do anything yet, it's in preparation for the execroot rearranging change. The execroot will have one bazel-out per repo, so it'll look like: execroot/ repo1/ bazel-out/ local-fastbuild/ bin/ repo2/ bazel-out/ local-fastbuild/ bin/ genfiles/ repo3/ bazel-out/ local-fastbuild/ testlogs/ and so on. Thus, any output path (getBinDirectory() & friends) needs to know what the repo name is. This changes so many places in the code I thought it would be good to do separately, then just flip the functionality in the execroot-rearranging commit. While I was poking around, I changed all of the refs I could from getPackageRelativeArtifact() to getBin/GenfilesArtifact(), so that 1) rule implementation don't have to know as much about roots and 2) they'll be more isolated from other output dir changes. `bazel info` and similar just return roots for the main repository. The only "change" is passing around a target label in the Java rules. Continues work on #1262. -- MOS_MIGRATED_REVID=129985336
* Rename some PackageId and RepositoryName fields/methods in prep for deep ↵Gravatar Kristina Chodorow2016-07-28
| | | | | | | | | | | | | execroot change This is in prep for making the execution root path for external repositories ../repo_name (instead of external/repo_name). Right now, the getRunfilesPath() returns that path, so that is renamed getExecRoot() (since the runfiles are really just a reflection of the execRoot structure). getSourceRoot() replaces getPathFragment, which has always been a confusing name (it's not clear from the name what the difference is between it and getPackageFragment()). It returns the relative path to source files for external repositories (external/repo_name). Also renamed/moved to more sensible class a few static RepositoryName fields. -- MOS_MIGRATED_REVID=128594419
* Bring PackageSpecification docs up-to-date, clean up its interfaceGravatar Mark Schaller2016-07-22
| | | | | | | | Focuses on documenting the Strings that PackageSpecifications can be translated from and to. -- MOS_MIGRATED_REVID=128195540
* Make skylark repository rules accept basic rule attributesGravatar Kristina Chodorow2016-06-21
| | | | | | | Fixes #1314. -- MOS_MIGRATED_REVID=125340361
* Allow use of Exceptions to exit early out of configured-target creation, ↵Gravatar Chris Parsons2016-05-24
| | | | | | | | | | instead of passing and checking null in all helpers. Demonstrates this pattern usage in a few select rules (e.g. AndroidBinary) where this was particularly egregious. There are many places which can benefit from this pattern -- this change doesn't try to fix them all at once. -- MOS_MIGRATED_REVID=123012378
* Always restrict aspects to only access requested configuration fragments.Gravatar Michael Staib2016-05-19
| | | | | | | | | | | This completes the introduction of aspect configuration fragment enforcement for static configuration builds; as of this change, it is no longer possible to fall back to the base rule's set of requested configuration fragments. This sort of fallback may become possible later, likely in a more controlled way. -- MOS_MIGRATED_REVID=122638152
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 07:41:39 +0000