| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 193130164
|
|
|
|
| |
PiperOrigin-RevId: 189244665
|
|
|
|
|
|
| |
for every type of action.
PiperOrigin-RevId: 187368369
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
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
|