aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/extra
Commit message (Collapse)AuthorAge
* Replace instances of Blaze with Bazel.Gravatar Dan Fabulich2018-07-05
| | | | | | | PiperOrigin-RevId: 203300374 Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856 PiperOrigin-RevId: 203407392
* CommandHelper: do not look up shell's pathGravatar Laszlo Csomor2018-05-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This change will allow incrementally migrating rules that use CommandHelper to start depending on the shell toolchain. Shell-using rules today only use the ShellConfiguration config fragment to look up the shell's path. In the future, more and more rules will also retrieve the active shell toolchain, and be able to: 1. use the auto-detected local shell interpreter's location, especially when it's not the default /bin/bash 2. use define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I4da4e77e7d1fe57e8e4f5eb8820d03a840915e20 Closes #5283. Change-Id: I4da4e77e7d1fe57e8e4f5eb8820d03a840915e20 PiperOrigin-RevId: 198298315
* Remove attribute read checks expecting a DATA transition.Gravatar gregce2018-05-25
| | | | | | | | | | | | | | This is a precursor to removing the DATA transition outright. While we could also have changed the Mode.DATA instances to Mode.TARGET (which would declare that we expect the attribute not to apply any transition), that would break existing definitions and make depot cleanup more delicate. Plus, these checks weren't being consistently applied across attributes anyway so they don't really offer much. A lot of this logic is really just leftover legacy from the pre-dynamic configuration days. PiperOrigin-RevId: 198085059
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-01
| | | | PiperOrigin-RevId: 194985157
* 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
* Fix filename in docGravatar brandjon2018-02-26
| | | | | RELNOTES: None PiperOrigin-RevId: 187018017
* Change cfg(HOST) to cfg(HostTransition.INSTANCE).Gravatar gregce2017-12-21
| | | | | | Preparatory step for removing ConfigurationTransition.HOST. PiperOrigin-RevId: 179838374
* Switch ExtraActionFactory to the Expander APIGravatar ulfjack2017-11-30
| | | | | | | This is a partial roll-forward of https://github.com/bazelbuild/bazel/commit/e8d32b7c922f65539b74357711d5ad6b70934115, which was rolled back due to genrule breakages - this part doesn't affect genrules, so it should be safe. PiperOrigin-RevId: 177450542
* Rollback "Switch ExtraActionFactory and GenRuleBase to the Expander API" due ↵Gravatar cparsons2017-11-09
| | | | | | | to breaking some existing genrules. RELNOTES: None. PiperOrigin-RevId: 175034625
* Switch ExtraActionFactory and GenRuleBase to the Expander APIGravatar ulfjack2017-11-06
| | | | | | | This changes the order in which expansions happen, which could change the semantics in subtle ways. PiperOrigin-RevId: 174518778
* LocationExpander: always require options to be passed inGravatar ulfjack2017-10-02
| | | | | | | | | Also update CommandHelper to split the heuristic label expansion code path from the normal code path. Progress on #2475. PiperOrigin-RevId: 170675702
* Switch ExtraActionFactory over to the new Expander interfaceGravatar ulfjack2017-09-29
| | | | PiperOrigin-RevId: 170494940
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Move extra action stuff to analysis.extraGravatar ulfjack2017-08-10
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164835678
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Compute progress message lazily in spawn action.Gravatar tomlu2017-08-03
| | | | | | | | | | Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats. This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels). Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal. PiperOrigin-RevId: 164068816
* Add a toolchains= attribute to *_binary, *_test, cc_library and extra_action ↵Gravatar lberki2017-07-14
| | | | | | | | | rules to declare which Make variables they need. The idea is that they would depend on the future java_runtime_alias / cc_toolchain_alias and similar rules and thus Bazel will know which Make variables they actually need instead of pulling in the whole BuildConfiguration and also making it possible to compute these Make variables during analysis instead of configuration creation. RELNOTES: None. PiperOrigin-RevId: 161785868
* Do not override Spawn methods from ExtraAction.Gravatar tomlu2017-07-12
| | | | | | | | | | As far as I can tell this is largely equivalent to the current behaviour: * Instead of discovering inputs in ExtraAction and adding its own runfiles supplier, just pass the composite one in the first place and let the normal thing happen * The mnemonic returned by the override seems to be equivalent to the one from the extra action anyway, which is what the base class does * The extra action key will change slightly as it will now include the composite runfiles supplier, but I can't see how that would be a problem. PiperOrigin-RevId: 161608100
* Update SpawnAction to take an ActionEnvironmentGravatar ulfjack2017-07-05
| | | | | | | | | | Some of the callers are not using the proper one from the configuration, and are thus ignoring --action_env. Some are only using part of the configuration's action environment. I tried to carefully not change the semantics in any case. Semantic-changing changes come later. PiperOrigin-RevId: 160891204
* Add a #getBytes() method to DeterministicWriter that returns a ByteString. ↵Gravatar janakr2017-06-30
| | | | | | | | By default it just delegates to the existing #writeOutputFile, but implementations may choose to override if they have easy access to a ByteString. Also change some DeterministicWriter implementations that do have easy access to the ByteString. PiperOrigin-RevId: 160550028
* Remove methods from CommandLine, making it a simple argument list interface.Gravatar Googler2017-05-15
| | | | | | | * isShellCommand is now passed directly to SpawnAction * Getting the associated params file action was a test-only thing. We can pull this out of the action graph instead. PiperOrigin-RevId: 156060366
* Give RuleContext the ability to add make variables.Gravatar lberki2017-05-05
| | | | | | This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS. PiperOrigin-RevId: 155171725
* Automated g4 rollback of commit ce33ab7a49126a513d7d5a6bc16f86154d9a85b6.Gravatar plf2017-05-03
| | | | PiperOrigin-RevId: 154931201
* Give RuleContext the ability to add Make VariablesGravatar Googler2017-04-27
| | | | | | This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS. PiperOrigin-RevId: 154329746
* 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
* A partial, manual rollback of commit 7af14dfdbd6addb779226c0a103b2a8dc72c16b1.Gravatar Lukacs Berki2017-03-14
| | | | | | | | This became necessary because extra actions for C++ compile actions require .h files, but the compiler only returns the .pcm files in the .d file for headers that it reads from the .pcm file. This is not a problem for correctness because the .pcm files depend on the headers, but that doesn't help the extra actions that would then only get the .pcm files. -- PiperOrigin-RevId: 150052839 MOS_MIGRATED_REVID=150052839
* Clean up the semantics of input discovering actions a bit by making ↵Gravatar Lukacs Berki2017-02-28
| | | | | | | | | | | | updateInputs() and inputsKnown() non-overridable and removing setInputs(). This comes at the cost of adding a flag to every action instance that's not used for non-input-discovering actions, but I think that's a deal. Simpler APIs are good, mmmmkay? Also fixed a few pre-existing issues in TestAction and ObjcCompileAction. -- PiperOrigin-RevId: 148749734 MOS_MIGRATED_REVID=148749734
* Remove AbtractAction#getInputsForExtraAction() (the third time).Gravatar Lukacs Berki2017-02-27
| | | | | | | | | | This time, if the action discovers inputs, the extra action is made to depend on the outputs of the action so that by the time the extra action runs, the inputs of the original action are discovered. This avoids us having to think about the state the shadowed action may keep. Yes, actions should not keep state, but they do. Such is life. -- PiperOrigin-RevId: 148627715 MOS_MIGRATED_REVID=148627715
* Rollback of commit e716ae46f359dc1361574f44569811ff80a758ac.Gravatar Ulf Adams2017-02-24
| | | | | | -- PiperOrigin-RevId: 148445872 MOS_MIGRATED_REVID=148445872
* Encore of commit 41c2a26eef89167e807cbc9f33487dc66bb757d3 that removed ↵Gravatar Lukacs Berki2017-02-24
| | | | | | | | | | | | | | | | | | | AbstractAction#getInputFilesForExtraAction(). Turns out, we didn't add *mandatory* inputs of the shadowed action to the extra action, thus, breakage. Original description: Remove AbstractAction#getInputFilesForExtraAction(). This method was used to return the discovered inputs for extra actions, but it turns out that we can use #discoverInputs() just as well. Note that this makes it possible for #discoverInputs() to be called more than once per action instance (once for the action and once for each extra action), but this appears to work. A followup change may be able to dispense with that, but let's take baby steps for now. Also note that this introduces synchronization between an action and its associated extra action. -- PiperOrigin-RevId: 148429641 MOS_MIGRATED_REVID=148429641
* Rollback of commit 41c2a26eef89167e807cbc9f33487dc66bb757d3.Gravatar Carmi Grushko2017-02-20
| | | | | | | | | | This is not a clean rollback: I had to change CppCompileAction on line 1278 and pass cppSemantics.getIncludeProcessing(). Please flag this if it doesn't make sense :) -- PiperOrigin-RevId: 147868235 MOS_MIGRATED_REVID=147868235
* Remove AbstractAction#getInputFilesForExtraAction().Gravatar Lukacs Berki2017-02-03
| | | | | | | | | | | | This method was used to return the discovered inputs for extra actions, but it turns out that we can use #discoverInputs() just as well. Note that this makes it possible for #discoverInputs() to be called more than once per action instance (once for the action and once for each extra action), but this appears to work. A followup change may be able to dispense with that, but let's take baby steps for now. Also note that this introduces synchronization between an action and its associated extra action. -- PiperOrigin-RevId: 146450132 MOS_MIGRATED_REVID=146450132
* Simplify the Action interface by asking it a set of allowed inputs instead ↵Gravatar Lukacs Berki2017-02-02
| | | | | | | | | | of to resolve exec paths found in the action cache. The resolution algorithm was the same in all cases where it was implemented. -- PiperOrigin-RevId: 146344672 MOS_MIGRATED_REVID=146344672
* Switch to RunfilesSuppliers for communicating runfilesGravatar Michajlo Matijkiw2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | ActionSpawn/SpawnAction now deal exclusively in RunfilesSuppliers, manifests maps are no more. There is some lingering awkwardness, in particular: - Manifests still need to be tracked in some places, we can work out if this is still necessary on a case by case basis. - Skylark makes actions' runfiles available via 'resolve_command' where they are consumed by 'action'. I've updated the documentation, though the name isn't entirely accurate anymore. That being said these interfaces _are_ marked as experimental, so we _should_ be able to be flexible here. Overall, I think the benefits consolidating runfiles into suppliers, from both code cleanliness and performance perspectives (no longer needing to parse manifests), outweights the awkwardnesses. RELNOTES: resolve_command/action's input_manifest return/parameter is now list -- PiperOrigin-RevId: 145817429 MOS_MIGRATED_REVID=145817429
* 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
* Names of extra-action protos now take into account aspect names.Gravatar Carmi Grushko2016-12-12
| | | | | | | | | | That is, if an Aspect registered an action that an extra-action is shadowing, its name will be used when creating the extra-action's ID and name. Without this change, it's impossible to analyze extra-actions when there's more than one aspected rule that acts on the same rule (e.g., java_proto_library and java_lite_proto_library on the same proto_library). -- PiperOrigin-RevId: 141587608 MOS_MIGRATED_REVID=141587608
* Move Bazel{ActionListener,ExtraAction} rule to rules.extra and drop prefix.Gravatar Ulf Adams2016-10-31
| | | | | -- MOS_MIGRATED_REVID=137694143
* Make SpawnActions honor the client environmentGravatar Klaus Aehlig2016-08-26
| | | | | | | | | | | | | | | ...for the variables that supposed to be inherited from it. Note That with this patch, we take the correct variables, but do not yet track the dependency on changes to the client environment; this will happen in a follow up patches. Also add a test that demonstrates that the client environment rather than that at startup is taken. -- Change-Id: I4d33efa8eaf4f8b689c9b7f2130f71309f3343f0 Reviewed-on: https://bazel-review.googlesource.com/#/c/5392 MOS_MIGRATED_REVID=131406356
* Action#discoverInputs returns an Iterable<Artifact> instead of aGravatar Cal Peyser2016-08-25
| | | | | | | Collection<Artifact> -- MOS_MIGRATED_REVID=131285541
* Extend Action interface by client variablesGravatar Klaus Aehlig2016-08-24
| | | | | | | | | | | | | | | | As per our design on [Specifying environment variables](http://bazel.io/designs/2016/06/21/environment.html), actions may depend, in a controlled way, on the environment in which the Bazel client is invoked. Those environment variables are considered essential for the action, in the sense that it was to be repeated if either of them changes their value (note that other variables in client environment may well change without invalidating actions). Therefore, make the variables that need to be taken from the client environment part of the meta data for actions. -- Change-Id: I2ff6cf40b4ce8e0fea5c7e464f5f3b3e693025ac Reviewed-on: https://bazel-review.googlesource.com/#/c/5390 MOS_MIGRATED_REVID=131150211
* 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
* 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
* Rewrite the extra action info files if the data within them changes.Gravatar Lukacs Berki2016-07-27
| | | | | -- MOS_MIGRATED_REVID=128468615
* 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
* Review a number of action subclasses and update them according to the spec.Gravatar Ulf Adams2016-04-19
| | | | | | | | Consists of adding @Immutable annotations, adding final modifiers, and changing the types of fields to immutable types. -- MOS_MIGRATED_REVID=120221067
* Simplifies AbstractWriteFileAction to pass the ActionExecutionContext ↵Gravatar Alex Humesky2016-02-26
| | | | | | | directly to newDeterministicWriter. -- MOS_MIGRATED_REVID=115626619
* Rollback of commit a9b84575a32476a5faf991da22b44661d75c19b6.Gravatar Cal Peyser2016-02-05
| | | | | | | | | | | | | *** Reason for rollback *** Mutability violates the Action contract: this change breaks incremental builds. *** Original change description *** Propogate BAZEL_VERBOSE_FAILURES and BAZEL_SUBCOMMANDS to the execution environments of runtime tools. -- MOS_MIGRATED_REVID=113958481
* Fix extra_actions with sandboxing.Gravatar Brian Silverman2016-01-21
| | | | | | | | | | | | | | | The ExtraAction code assumed that it didn't need to list the runfiles of its tools when running locally, but this isn't true with sandboxing. I don't think fixing this will negatively affect anybody's performance because they probably don't have any runfiles because they currently can't use them, unless they're running actions remotely in which case this change has no effect. -- Change-Id: Ibeb3db9d31321912a7163d1bce0edf5f6288ea3e Reviewed-on: https://bazel-review.googlesource.com/#/c/2520/ MOS_MIGRATED_REVID=112670586
* Rename defaultShellEnvironment to localShellEnvironment and clarifyGravatar Han-Wen Nienhuys2016-01-21
| | | | | | | its intended use. -- MOS_MIGRATED_REVID=112598772
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-20 03:00:19 +0000