[7.5.0] Remove no-op --block_for_lock command option (#25000)

This option, which is different from the startup option of the same name, has no effect and doesn't even show a warning, which can be confusing. Closes #24953. PiperOrigin-RevId: 717853503 Change-Id: I8d7d1229f692007c4350b6c15526b7a95bbed5ef Commit 79508be Co-authored-by: Fabian Meumertzheim <[email protected]>
bazelbuild · Jan 21, 2025 · 86f0b8e · 86f0b8e
1 parent 19ea55d
commit 86f0b8e
Showing 1 changed file with 0 additions and 11 deletions.
diff --git a/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java b/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java
@@ -435,17 +435,6 @@ public String getTypeDescription() {
       help = "Enable processing of +<file> parameters.")
   public boolean allowProjectFiles;
 
-  @Option(
-      name = "block_for_lock",
-      defaultValue = "true",
-      documentationCategory = OptionDocumentationCategory.UNDOCUMENTED,
-      effectTags = {OptionEffectTag.BAZEL_INTERNAL_CONFIGURATION},
-      metadataTags = {OptionMetadataTag.HIDDEN},
-      help =
-          "If set (the default), a command will block if there is another one running. If "
-              + "unset, these commands will immediately return with an error.")
-  public boolean blockForLock;
-
   // We could accept multiple of these, in the event where there's a chain of tools that led to a
   // Bazel invocation. We would not want to expect anything from the order of these, and would need
   // to guarantee that the "label" for each command line is unique. Unless a need is demonstrated,