"bazel clean": prevent creation of command.log
Open files cannot be deleted on Windows, thus
`bazel clean --expunge` fails when it attemps to
delete the `command.log` that stdout/stderr is
tee'd into, and so does BlazeCommandDispatcher
when it attemps to delete the `command.log` just
before dispatching to the command implementation
(not just `clean` but any command).
This change:
- closes `command.log` before we attempt to
delete it
- marks CleanCommand (through the Command
annotation) as one that should not write to the
command.log, thus we don't create a new instance
of the file
This change allows `bazel clean --expunge` to
delete everything in the output base, with the
exception of `jvm.log`. Unfortunately that file is
opened by the C++ bazel client process, so we have
to close it there prior to sending the clean to
the bazel server.
See https://github.com/bazelbuild/bazel/issues/1586
--
MOS_MIGRATED_REVID=137278553
diff --git a/src/main/java/com/google/devtools/build/lib/runtime/Command.java b/src/main/java/com/google/devtools/build/lib/runtime/Command.java
index c415f0a..4db5627 100644
--- a/src/main/java/com/google/devtools/build/lib/runtime/Command.java
+++ b/src/main/java/com/google/devtools/build/lib/runtime/Command.java
@@ -15,7 +15,6 @@
import com.google.devtools.common.options.Option;
import com.google.devtools.common.options.OptionsBase;
-
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
@@ -89,6 +88,13 @@
boolean binaryStdErr() default false;
/**
+ * Returns true if this command may want to write to the command.log.
+ *
+ * <p>The clean command would typically set this to false so it can delete the command.log.
+ */
+ boolean writeCommandLog() default true;
+
+ /**
* The help message for this command. If the value starts with "resource:",
* the remainder is interpreted as the name of a text file resource (in the
* .jar file that provides the Command implementation class).