aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/actions/LauncherFileWriteAction.java
Commit message (Collapse)AuthorAge
* Cleanup Artifact.getPath() usage surrounding Fingerprint.Gravatar shahan2018-04-16
| | | | PiperOrigin-RevId: 193130164
* Begins cleanup to allow ActionFS to be injected into all action executions.Gravatar shahan2018-03-15
| | | | PiperOrigin-RevId: 189244665
* Refactor the AbstractAction computeKey method to be easier to add invariantsGravatar jcater2018-02-28
| | | | | | for every type of action. PiperOrigin-RevId: 187368369
* Add ActionKeyContext to Action#getKey.Gravatar tomlu2017-11-29
| | | | | | | This key context can be used by actions to share partial key computations, for instance when computing MD5s for nested sets. RELNOTES: None PiperOrigin-RevId: 177359607
* 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
* Windows,launcher: add LauncherFileWriteActionGravatar Laszlo Csomor2017-10-06
Introduce LauncherFileWriteAction, a FileWriteAction that can create a native {java,sh,py}_binary launcher from the launcher stub and the user-specified launch information. The LauncherFileWriteAction class does not use the "copy" command of cmd.exe so it's not restricted with path lengths. The class stores a LaunchInfo object, which describes the launch data that the launcher stub reads to identify its payload. The LaunchInfo is a lazy object, similar to CustomCommandLine. LaunchInfo won't fully construct the launch data until it is about to write the data to the output. Thus LaunchInfo is memory efficient because it won't create any String objects in the analysis phase that it would only read in the execution phase. Fixes https://github.com/bazelbuild/bazel/issues/3802 Change-Id: I4ddd83369e7131d42e2e9b35f105ad2dc60bcc52 PiperOrigin-RevId: 171115105