命令和选项

报告问题open_in_new 查看源代码open_in_new

本页面介绍了各种 Bazel 命令（例如 bazel build、bazel run 和 bazel test）提供的选项。本页是使用 Bazel 构建中的 Bazel 命令列表的配套内容。

目标语法

某些命令（如 build 或 test）可针对目标列表执行操作。它们使用的语法比标签更加灵活，详见指定要构建的目标一文。

选项

以下部分将介绍构建期间可用的选项。对帮助命令使用 --long 时，在线帮助消息会提供每个选项的含义、类型和默认值的摘要信息。

大多数选项只能指定一次。如果多次指定，则最后一个实例胜出。在线帮助中标识了可以多次指定的选项，并且带有文字“可以多次使用”。

软件包位置

--package_path

此选项可指定通过搜索来查找指定软件包的 build 文件的目录集。

Bazel 会通过搜索软件包路径来查找其软件包。这是以冒号分隔的 Bazel 目录列表，其中每个目录都是部分源代码树的根。

如需使用 --package_path 选项指定自定义软件包路径，请执行以下操作：

  % bazel build --package_path %workspace%:/some/other/root

软件包路径元素可以用三种格式指定：

1. 如果第一个字符是 /，则路径为绝对路径。
2. 如果路径以 %workspace% 开头，则路径将相对于最近的封闭式 Bazel 目录进行选择。例如，如果您的工作目录为 /home/bob/clients/bob_client/bazel/foo，则软件包路径中的字符串 %workspace% 会扩展为 /home/bob/clients/bob_client/bazel。
3. 其他任何信息均相对于工作目录而言。 这通常并不是您想要执行的操作，并且如果您从 Bazel 工作区下的目录中使用 Bazel，则可能会出现意外行为。例如，如果您使用软件包路径元素 .，然后通过 cd 操作进入目录 /home/bob/clients/bob_client/bazel/foo，系统将从 /home/bob/clients/bob_client/bazel/foo 目录解析软件包。

如果使用非默认软件包路径，为方便起见，请在 Bazel 配置文件中指定该路径。

Bazel 不要求任何软件包位于当前目录中，因此，如果可以在软件包路径的其他位置找到所有必要的软件包，则可以从空的 Bazel 工作区执行构建。

示例：从空客户端进行构建

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

此选项指定了以英文逗号分隔的软件包列表，Bazel 应将其视为已删除的软件包，并且不要尝试从软件包路径上的任何目录加载。这可用于模拟删除软件包而不实际删除软件包。此选项可以传递多次，在这种情况下，各个列表会串联起来。

检查时出错

这些选项可控制 Bazel 的错误检查和/或警告。

--[no]check_visibility

如果此选项设置为 false，则可见性检查会降级为警告。 此选项的默认值为 true，因此默认情况下，系统会完成公开范围检查。

--output_filter=regex

--output_filter 选项将仅针对与正则表达式匹配的目标显示构建和编译警告。如果目标与给定正则表达式不匹配，并且其执行成功，其标准输出和标准错误将被舍弃。

以下是此选项的一些典型值：

`--output_filter='^//(first/project|second/project):'`	显示指定软件包的输出。
`--output_filter='^//(?!(first/bad_project|second/bad_project):):*$'`	不显示指定软件包的输出。
`--output_filter=`	显示所有内容。
`--output_filter=DONT_MATCH_ANYTHING`	不显示任何内容。

工具标志

这些选项可控制 Bazel 会将哪些选项传递给其他工具。

--copt=cc-option

此选项接受要传递给编译器的参数。每当调用该参数进行预处理、编译和/或汇编 C、C++ 或汇编代码时，都会将其传递到编译器。关联时不会传递。

此选项可多次使用。例如：

  % bazel build --copt="-g0" --copt="-fpic" //foo

将在没有调试表的情况下编译 foo 库，从而生成与位置无关的代码。

--host_copt=cc-option

此选项接受一个参数，该参数会被传递给在 exec 配置中编译的源文件的编译器。这与 --copt 选项类似，但仅适用于执行配置。

--host_conlyopt=cc-option

此选项接受一个参数，该参数将被传递给在 exec 配置中编译的 C 源文件的编译器。这与 --conlyopt 选项类似，但仅适用于执行配置。

--host_cxxopt=cc-option

此选项接受一个参数，该参数会被传递给在 exec 配置中编译的 C++ 源文件的编译器。这与 --cxxopt 选项类似，但仅适用于执行配置。

--host_linkopt=linker-option

此选项接受一个参数，该参数会被传递给在执行配置中编译的源文件的链接器。这与 --linkopt 选项类似，但仅适用于执行配置。

--conlyopt=cc-option

此选项接受在编译 C 源文件时传递给编译器的参数。

它与 --copt 类似，但仅适用于 C 编译，而不适用于 C++ 编译或链接。因此，您可以使用 --conlyopt 传递特定于 C 的选项（例如 -Wno-pointer-sign）。

--cxxopt=cc-option

此选项接受在编译 C++ 源文件时传递给编译器的参数。

它与 --copt 类似，但仅适用于 C++ 编译，而不适用于 C 编译或链接。因此，您可以使用 --cxxopt 传递 C++ 专属选项（例如 -fpermissive 或 -fno-implicit-templates）。

例如：

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

此选项采用可在链接时传递给编译器的参数。

它与 --copt 类似，但仅适用于链接，而不适用于编译。因此，您可以使用 --linkopt 传递仅在链接时有意义的编译器选项（例如 -lssp 或 -Wl,--wrap,abort）。例如：

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

build 规则还可以在其属性中指定链接选项。此选项的设置始终优先。另请参阅 cc_library.linkopts。

--strip (always|never|sometimes)

此选项决定了使用 -Wl,--strip-debug 选项调用链接器，Bazel 是否会剥离所有二进制文件和共享库中的调试信息。 --strip=always 表示始终去除调试信息。--strip=never 表示永不剥离调试信息。如果 --compilation_mode 为 fastbuild，默认值为 --strip=sometimes。

  % bazel build --strip=always //foo:bar

会编译目标，同时从生成的所有二进制文件中删除调试信息。

Bazel 的 --strip 选项对应于 ld 的 --strip-debug 选项：它仅剥离调试信息。如果您出于某种原因需要剥离所有符号，而不仅仅是调试符号，则需要使用 ld 的 --strip-all 选项，可以通过将 --linkopt=-Wl,--strip-all 传递给 Bazel 来实现。另请注意，设置 Bazel 的 --strip 标志会替换 --linkopt=-Wl,--strip-all，因此您应该只设置其中一个。

如果您只是构建单个二进制文件并希望移除所有符号，还可以传递 --stripopt=--strip-all 并显式构建目标的 //foo:bar.stripped 版本。如 --stripopt 部分所述，此链接会在最终二进制文件关联后应用剥离，而不是在 build 的所有链接操作中包括剥离。

--stripopt=strip-option

这是在生成 *.stripped 二进制文件时向 strip 命令传递的另一个选项。默认值为 -S -p。此选项可多次使用。

--fdo_instrument=profile-output-dir

--fdo_instrument 选项用于在执行构建好的 C/C++ 二进制文件时生成 FDO（反馈优化）配置文件输出。对于 GCC，提供的参数用作 .gcda 文件的每个对象文件目录树的目录前缀，其中包含每个 .o 文件的配置文件信息。

生成配置文件数据树后，应压缩配置文件树并将其提供给 --fdo_optimize=profile-zip Bazel 选项，以启用 FDO 优化编译。

对于 LLVM 编译器，该参数也是转储原始 LLVM 配置文件数据文件的目录。例如：--fdo_instrument=/path/to/rawprof/dir/。

选项 --fdo_instrument 和 --fdo_optimize 不能同时使用。

--fdo_optimize=profile-zip

借助 --fdo_optimize 选项，您可以在编译时使用对象级文件配置文件信息执行 FDO（基于反馈的优化）优化。对于 GCC，提供的参数是包含之前生成的 .gcda 文件树的 ZIP 文件，其中包含每个 .o 文件的配置文件信息。

或者，提供的参数可以指向由扩展名 .afdo 标识的自动配置文件。

对于 LLVM 编译器，提供的参数应指向由 llvm-profdata 工具准备的已编入索引的 LLVM 配置文件输出文件，并且应包含 .profdata 扩展名。

选项 --fdo_instrument 和 --fdo_optimize 不能同时使用。

--java_language_version=version

此选项用于指定 Java 源代码的版本。例如：

  % bazel build --java_language_version=8 java/com/example/common/foo:all

编译并仅允许使用与 Java 8 规范兼容的结构。 默认值为 11。--> 相应的值包括：8、9、10、11、14 和 15，可使用 default_java_toolchain 注册自定义 Java 工具链，对这些值进行扩展。

--tool_java_language_version=version

用于构建在构建期间执行的工具的 Java 语言版本。 默认值为 11。

--java_runtime_version=version

此选项用于指定执行代码并运行测试的 JVM 版本。例如：

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

从远程代码库下载 JDK 11，并使用 Java 应用运行该应用。

默认值为 local_jdk。 可能的值包括 local_jdk、local_jdk_version、remotejdk_11 和 remotejdk_17。您可以通过使用 local_java_repository 或 remote_java_repository 代码库规则注册自定义 JVM 来扩展这些值。

--tool_java_runtime_version=version

用于执行构建期间所需的工具的 JVM 版本。默认值为 remotejdk_11。

--jvmopt=jvm-option

此选项允许将选项参数传递给 Java 虚拟机。它可以与一个大参数一起使用，也可以多次与单个参数配合使用。例如：

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

将使用服务器虚拟机启动所有 Java 二进制文件，并将虚拟机的启动堆大小设置为 256 MB。

--javacopt=javac-option

此选项允许将选项参数传递给 javac。它可以与一个大参数一起使用，也可以多次与单个参数配合使用。例如：

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

将使用 javac 默认调试信息（而不是 bazel 默认值）重新构建 java_binary。

此选项会传递到 javac 的 javac 内置选项和 javac 选项之后。javac 中任何选项的最后一个规范胜出。javac 的默认选项包括：

  -source 8 -target 8 -encoding UTF-8

--strict_java_deps (default|strict|off|warn|error)

此选项用于控制 javac 检查是否缺少直接依赖项。Java 目标必须将所有直接使用的目标明确声明为依赖项。此标志指示 javac 确定对每个 Java 文件进行类型检查时实际使用的 JAR；如果这些 JAR 不是当前目标的直接依赖项的输出，则发出警告/错误。

• off 表示已停用检查。
• warn 表示 javac 将针对每个缺失的直接依赖项生成类型为 [strict] 的标准 java 警告。
• default、strict 和 error 均表示 javac 将生成错误而不是警告，如果发现任何缺失的直接依赖项，会导致当前目标无法构建。这也是未指定该标志时的默认行为。

构建语义

这些选项会影响构建命令和/或输出文件内容。

--compilation_mode (fastbuild|opt|dbg) (-c)

--compilation_mode 选项（通常缩写为 -c，尤其是 -c opt）接受 fastbuild、dbg 或 opt 的参数，并影响各种 C/C++ 代码生成选项，例如优化级别和调试表的完整性。Bazel 针对不同的编译模式使用不同的输出目录，因此您可以切换模式，而无需每次都进行全面重新构建。

• fastbuild 表示尽快构建：生成最少的调试信息 (-gmlt -Wl,-S)，并且不优化。这是默认值。注意：不会设置 -DNDEBUG。
• dbg 表示启用了调试功能 (-g) 的构建，因此您可以使用 gdb（或其他调试程序）。
• opt 表示启用优化并禁用 assert() 调用的构建 (-O2 -DNDEBUG)。在 opt 模式下，除非您同时传递 --copt -g，否则系统不会生成调试信息。

--cpu=cpu

此选项可指定要在构建期间编译二进制文件的目标 CPU 架构。

--action_env=VAR=VALUE

指定执行所有操作期间可用的环境变量集。 变量可以按名称指定，在这种情况下，值应从调用环境中获取，也可以由 name=value 对指定，因此无需设置调用环境即可设置值。

您可以多次指定此 --action_env 标志。如果将多个 --action_env 标志的值分配给同一个变量，则最新的赋值优先。

--experimental_action_listener=label

experimental_action_listener 选项会指示 Bazel 使用 label 指定的 action_listener 规则的详细信息，将 extra_actions 插入 build 图。

--[no]experimental_extra_action_top_level_only

如果此选项设置为 true，则 --experimental_action_listener 命令行选项指定的额外操作只会针对顶级目标进行调度。

--experimental_extra_action_filter=regex

experimental_extra_action_filter 选项指示 Bazel 过滤要安排 extra_actions 的一组目标。

此标志仅适用于 --experimental_action_listener 标志。

默认情况下，系统会请求执行所请求“目标构建”的传递性关闭中的所有 extra_actions。--experimental_extra_action_filter 将投放时间限制为 extra_actions，其中所有者的标签与指定正则表达式匹配。

以下示例将 extra_actions 的调度限制为仅针对所有者标签包含“/bar/”的操作：

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

此选项可指定用于构建主机工具的 CPU 架构的名称。

--fat_apk_cpu=cpu[,cpu]*

在 android_binary 规则的传递 deps 中构建 C/C++ 库的 CPU。其他 C/C++ 规则不受影响。例如，如果 cc_library 出现在 android_binary 规则和 cc_binary 规则的传递 deps 中，cc_library 会至少构建两次：对于使用 android_binary 规则的 --fat_apk_cpu 指定的每个 CPU，一次构建一次，对于 cc_binary 规则，使用 --cpu 指定的 CPU 构建一次。

默认值为 armeabi-v7a。

系统会针对使用 --fat_apk_cpu 指定的每个 CPU 创建一个 .so 文件并将其打包到 APK 中。.so 文件的名称会为 android_binary 规则的名称添加“lib”前缀。例如，如果 android_binary 的名称为“foo”，则文件为 libfoo.so。

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

如果存在，但包含标签或执行路径与任一包含式正则表达式匹配且与任何排除表达式不匹配的任何 C++ 文件，都将使用给定选项进行构建。标签匹配使用规范形式的标签（即 //package:label_name）。

执行路径是工作区目录的相对路径，其中包含 C++ 文件的基名（包括扩展名）。此外，还包含所有依赖于平台的前缀。

为了匹配生成的文件（例如 genrule 输出），Bazel 只能使用执行路径。在这种情况下，正则表达式不应以“//”开头，因为它与任何执行路径都不匹配。软件包名称可按如下方式使用：--per_file_copt=base/.*\.pb\.cc@-g0。这将与 base 目录下的每个 .pb.cc 文件匹配。

此选项可多次使用。

无论使用哪种编译模式，都会应用此选项。例如，可以在编译 --compilation_mode=opt 时有选择性地编译部分文件，同时启用更强的优化或停用优化。

注意事项：如果某些文件使用调试符号进行选择性编译，则符号可能会在链接期间被剥离。设置 --strip=never 可防止发生这种情况。

语法：[+-]regex[,[+-]regex]...@option[,option]...，其中 regex 表示正则表达式，其前缀为 + 可标识包含格式，- 表示排除模式。option 表示传递给 C++ 编译器的任意选项。如果选项包含 ,，则必须加上 \, 这样的引用。选项还可以包含 @，因为只有第一个 @ 用于分隔正则表达式与选项。

示例：--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs 将 -O0 和 -fprofile-arcs 选项添加到 C++ 编译器的命令行中，用于 //foo/ 中的所有 .cc 文件（file.cc 除外）。

--dynamic_mode=mode

决定 C++ 二进制文件是否会被动态关联，并与 build 规则中的 linkstatic 属性进行交互。

模式：

• auto：转换为依赖于平台的模式；对于 Linux，转换为 default；对于 cygwin，则转换为 off。
• default：允许 Bazel 选择是否动态链接。如需了解详情，请参阅 linkstatic。
• fully：动态链接所有目标。这可以缩短链接时间，并减小生成的二进制文件的大小。
• off：以大部分静态模式关联所有目标。如果在 linkopt 中设置 -static，目标将更改为完全静态。

--fission (yes|no|[dbg][,opt][,fastbuild])

启用 Fission，用于将 C++ 调试信息写入专用的 .dwo 文件而不是 .o 文件，否则会丢失。这样可以显著减少链接的输入大小，并缩短链接用时。

如果设置为 [dbg][,opt][,fastbuild]（例如：--fission=dbg,fastbuild），则仅对一组指定的编译模式启用 Fission。这对于 Bazelrc 设置很有用。设置为 yes 时，会通用启用 Fission。设置为 no 时，Fission 会通用停用。默认值为 no。

--force_ignore_dash_static

如果设置了此标志，cc_* 规则 BUILD 文件的 linkopt 中的任何 -static 选项都会被忽略。此变更仅作为 C++ 安全强化 build 的解决方法。

--[no]force_pic

启用后，所有 C++ 编译都会生成位置无关代码（“-fPIC”），链接更倾向于 PIC 预构建库，而不是非 PIC 库，并且链接会生成位置无关可执行文件（“-pie”）。默认为停用。

--android_resource_shrinking

选择是否为 android_binary 规则执行资源缩减。为 android_binary 规则设置 shrink_resources 属性的默认值；如需了解详情，请参阅该规则的文档。默认为关闭。

--custom_malloc=malloc-library-target

指定这些标记时，请始终使用指定的 malloc 实现，以替换所有 malloc="target" 属性，包括那些使用这些默认值（通过不指定任何 malloc）的目标。

--crosstool_top=label

此选项可指定跨工具编译器套件的位置，可在构建期间用于所有 C++ 编译。Bazel 将在该位置查找 CROSSTOOL 文件，并用它自动确定 --compiler 的设置。

--host_crosstool_top=label

如果未指定，Bazel 会使用 --crosstool_top 的值来编译执行配置中的代码，例如在构建期间运行的工具。此标记的主要目的是启用交叉编译。

--apple_crosstool_top=label

用于编译 objc*、ios* 和 apple* 规则的传递 deps 中的 C/C++ 规则的交叉工具。对于这些目标，此标志会覆盖 --crosstool_top。

--android_crosstool_top=label

用于编译 android_binary 规则传递 deps 中的 C/C++ 规则的交叉工具。如果 build 中的其他目标需要不同的 crosstool，这会很有用。默认设置为使用 WORKSPACE 文件中的 android_ndk_repository 规则生成的 crosstool。 另请参阅 --fat_apk_cpu。

--compiler=version

此选项可指定在构建期间将用于编译二进制文件的 C/C++ 编译器版本（例如 gcc-4.1.0）。如果您想使用自定义交叉工具进行构建，则应使用 CROSSTOOL 文件，而不是指定此标志。

--android_sdk=label

此选项可指定用于构建任何 Android 相关规则的 Android SDK/平台工具链和 Android 运行时库。

如果在 WORKSPACE 文件中定义了 android_sdk_repository 规则，系统会自动选择 Android SDK。

--java_toolchain=label

此选项可指定用于编译 Java 源文件的 java_toolchain 的标签。

--host_java_toolchain=label

如果未指定，bazel 会使用 --java_toolchain 的值来编译执行配置中的代码，例如对于在构建期间运行的工具。此标记的主要目的是启用交叉编译。

--javabase=(label)

此选项可设置用于 bazel run、bazel test 以及由 java_binary 和 java_test 规则构建的 Java 二进制文件的基本 Java 安装标签。JAVABASE 和 JAVA “Make”变量衍生自此选项。

--host_javabase=label

此选项设置要在执行配置中使用的基本 Java 安装标签，例如，用于 JavaBuilder 和 Singlejar 等主机构建工具。

此操作不会选择用于编译 Java 源文件的 Java 编译器。您可以通过设置 --java_toolchain 选项来选择编译器。

执行策略

这些选项会影响 Bazel 的执行方式。它们应该不会对 build 生成的输出文件产生任何重大影响。通常情况下，它们的主要影响因素是构建速度。

--spawn_strategy=strategy

此选项用于控制命令的执行位置和执行方式。

• standalone 使命令作为本地子进程执行。此值已弃用。请改用“local”。
• sandboxed 导致在本地机器上的沙盒内执行命令。这要求所有输入文件、数据依赖项和工具在 srcs、data 和 tools 属性中列为直接依赖项。在支持沙盒化执行的系统上，Bazel 会默认启用本地沙盒。
• local 使命令作为本地子进程执行。
• worker 允许使用持久性工作器（如果可用）执行命令。
• docker 会导致在本地机器上的 Docker 沙盒内执行命令。 这需要安装 Docker。
• remote 可远程执行命令；只有在远程执行程序已单独配置的情况下，此命令才可用。

--strategy mnemonic=strategy

此选项可控制命令的执行位置和执行方式，重写每个记忆规则的 --spawn_Strategy（以及含记忆规则的 --genrule_Strategy）。如需了解支持的策略及其影响，请参阅 --spawn_Strategy。

--strategy_regexp=<filter,filter,...>=<strategy>

此选项用于指定应使用何种策略执行包含与特定 regex_filter 匹配的命令的命令。如需详细了解正则表达式，请参阅 --per_file_copt。如需了解支持的策略及其影响，请参阅 --spawn_Strategy。

系统会使用与说明匹配的最后一个 regex_filter。此选项会替换用于指定策略的其他标志。

• 示例：--strategy_regexp=//foo.*\\.cc,-//foo/bar=local 表示如果说明与 //foo.*.cc 匹配，但不与 //foo/bar 匹配，则使用 local 策略运行操作。
• 示例：--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed 使用 sandboxed 策略运行“Compiling //foo/bar/baz”，但逆转顺序使用 local 运行它。
• 示例：--strategy_regexp='Compiling.*/bar=local,sandboxed' 使用 local 策略运行“Compiling //foo/bar/baz”，并在失败时回退到 sandboxed。

--genrule_strategy=strategy

这是 --strategy=Genrule=strategy 的简写形式。

--jobs=n (-j)

此选项采用整数参数，用于指定在构建执行阶段应并发执行的作业数量限制。

--progress_report_interval=n

Bazel 会定期输出尚未完成的作业（例如长时间运行的测试）的进度报告。此选项会设置报告频率，每 n 秒输出一次进度。

默认值为 0，表示增量算法：第一个报告将在 10 秒后输出，然后是 30 秒，之后每分钟报告一次进度。

当 Bazel 使用光标控件（由 --curses 指定）时，每秒报告一次进度。

--local_{ram,cpu}_resources resources or resource expression

这些选项指定 Bazel 在安排在本地运行的构建和测试活动时可考虑的本地资源量（MB，CPU 逻辑 CPU 的数量）它们接受一个整数或一个关键字（HOST_RAM 或 HOST_CPUS），后面可选择加上 [-|* 浮点数]（例如 --local_cpu_resources=2、--local_ram_resources=HOST_RAM*.5 和 --local_cpu_resources=HOST_CPUS-1）。这些标志是独立的，可以设置其中一个，也可以同时设置两个。默认情况下，Bazel 会根据本地系统的配置直接估算 RAM 数量和 CPU 核心数。

--[no]build_runfile_links

此选项默认处于启用状态，用于指定是否应在输出目录中构建用于测试和二进制文件的 runfiles 符号链接。使用 --nobuild_runfile_links 有助于验证所有目标是否会编译，而不会产生构建 Runfile 树的开销。

执行测试（或应用）时，其运行时数据依赖项会集中在一起。在 Bazel 的输出树中，“runfiles”树的 root 权限通常对应于相应二进制文件或测试的同级。 在测试执行期间，您可以使用 $TEST_SRCDIR/workspace/packagename/filename 形式的路径访问 runfile。runfiles 树可确保测试能够访问其声明了依赖关系的所有文件，并且完全无法访问其他内容。默认情况下，runfiles 树是通过构建到所需文件的一组符号链接实现的。随着这组链接不断增加，此操作的成本也会增加。对于某些大型 build，这可能会对整体构建时间产生极大影响，尤其是因为每个测试（或应用）都需要有自己的 Runfile 树。

--[no]build_runfile_manifests

此选项（默认处于启用状态）可指定是否应将 runfile 清单写入输出树。将其停用意味着使用 --nobuild_runfile_links。

在远程执行测试时可以将其停用，因为 runfile 树将根据内存中的清单远程创建。

--[no]discard_analysis_cache

启用此选项后，Bazel 将在执行开始之前舍弃分析缓存，从而为执行阶段释放更多内存（约 10%）。但其缺点是，进一步增加构建速度会较慢。另请参阅内存节省模式。

--[no]keep_going (-k)

与 GNU Make 一样，当出现第一个错误时，build 的执行阶段会停止。有时即使存在错误，尝试构建尽可能多的代码也很有用。此选项可启用该行为，指定该选项后，build 会尝试构建前提条件已成功构建的每个目标，但会忽略错误。

虽然此选项通常与 build 的执行阶段相关联，但它也会影响分析阶段：如果在 build 命令中指定多个目标，但只有其中一些目标可以成功分析，除非指定 --keep_going，否则构建将会停止，在这种情况下，构建只会进入执行阶段，但仅针对成功分析的目标。

--[no]use_ijars

此选项会更改 Bazel 编译 java_library 目标的方式。Bazel 不会使用 java_library 的输出来构建编译 java_library 目标，而是创建仅包含非私有成员（公共、受保护和默认（软件包）访问方法和字段）签名的接口 JAR，并使用接口 JAR 编译依赖目标。这样一来，当仅对方法的正文或私有成员进行更改时，就可以避免重新编译。

--[no]interface_shared_objects

此选项会启用接口共享对象，这使得二进制文件和其他共享库依赖于共享对象的接口，而非其实现。如果只有实现发生变化，Bazel 可以避免重新构建不必要地更改共享库的目标。

输出选择

这些选项决定了要构建或测试的内容。

--[no]build

此选项会导致 build 的执行阶段发生；该选项默认处于开启状态。关闭时，系统会跳过执行阶段，并且只会出现前两个阶段（加载和分析）。

此选项有助于验证 BUILD 文件并检测输入中的错误，而无需实际构建任何内容。

--[no]build_tests_only

如果已指定，Bazel 将仅构建运行由于大小、超时、标记或语言而未过滤的 *_test 和 test_suite 规则所必需的内容。 如果指定，Bazel 会忽略命令行中指定的其他目标。 默认情况下，此选项处于停用状态，Bazel 将构建请求的所有内容，包括被从测试中滤除的 *_test 和 test_suite 规则。这非常有用，因为运行 bazel test --build_tests_only foo/... 不一定能检测到 foo 树中的所有构建中断。

--[no]check_up_to_date

此选项会导致 Bazel 不执行构建，而只是检查所有指定的目标是否处于最新状态。如果是这样，构建会照常完成。但是，如果任何文件已过时，系统不会报告构建，而是会报告错误并且构建会失败。此选项可能有助于确定某个 build 的执行时间是否比源代码修改最近（例如，用于进行提交前检查）而未产生 build 费用。

另请参阅 --check_tests_up_to_date。

--[no]compile_one_dependency

编译参数文件的一个依赖项。这对于 IDE 中的语法检查源文件非常有用，例如，通过重新构建依赖于源文件的目标，尽早在修改/构建/测试周期中检测错误。此参数会影响所有非标志参数的解读方式：每个参数都必须是文件目标标签或相对于当前工作目录的普通文件名，并且系统会构建一条依赖于每个源文件名的规则。对于 C++ 和 Java 源代码，系统会优先选择同一语言空间中的规则。对于具有相同偏好设置的多个规则，系统会选择在 build 文件中首先显示的规则。明确引用的目标模式不引用源文件会导致错误。

--save_temps

--save_temps 选项会保存编译器的临时输出。其中包括 .s 文件（汇编代码）、.i（预处理 C）和 .ii（预处理 C++）文件。这些输出通常对调试很有用。系统只会为命令行中指定的目标集生成临时温度。

--save_temps 标志目前仅适用于 cc_* 规则。

为了确保 Bazel 能够输出其他输出文件的位置，请检查您的 --show_result n 设置是否足够高。

--build_tag_filters=tag[,tag]*

如果已指定，Bazel 将仅构建具有至少一个必需标记（如果指定了其中任何一个标记）且没有任何已排除标记的目标。构建标记过滤器是以逗号分隔的标记关键字列表的形式指定的，前面带有“-”符号，用于表示排除的标记。必需的标记也可以前面带有“+”。

在运行测试时，Bazel 会忽略测试目标的 --build_tag_filters，即使这些目标不符合此过滤条件，它们也会构建并运行。为避免构建测试目标，请使用 --test_tag_filters 或明确排除测试目标。

--test_size_filters=size[,size]*

如果指定，则 Bazel 将仅测试具有指定大小的目标（如果还指定了 --build_tests_only，则构建）。测试大小过滤条件指定为允许的测试大小值列表（以英文逗号分隔，小、中、大或超大），前面可以加上“-”符号，表示被排除的测试大小。例如，

  % bazel test --test_size_filters=small,medium //foo:all

and

  % bazel test --test_size_filters=-large,-enormous //foo:all

只测试 //foo 内的中小型企业测试。

默认情况下，系统不会应用测试尺寸过滤功能。

--test_timeout_filters=timeout[,timeout]*

如果指定，则 Bazel 将仅测试具有指定超时的测试目标（或者如果还指定了 --build_tests_only，则构建）。测试超时过滤器指定为允许使用的测试超时值（短、中、长或永久）的逗号分隔列表，可以选择后跟“-”符号来表示排除的测试超时。如需查看语法示例，请参阅 --test_size_filters。

默认情况下，系统不会应用测试超时过滤。

--test_tag_filters=tag[,tag]*

如果已指定，则 Bazel 将仅测试具有至少一个必需标记（如果指定了其中任何一个）且没有任何已排除标记的测试目标（或者指定了 --build_tests_only）。测试标记过滤器指定为标记关键字列表的逗号分隔列表，可以选择在前面加上“-”符号来表示排除的标记。必需的标记也可以前面带有“+”。

例如，

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

将测试标记有 performance 或 stress 标记但没有标记 flaky 标记的目标。

默认情况下，系统不会应用测试标记过滤。请注意，您还可以通过这种方式过滤测试的 size 和 local 标记。

--test_lang_filters=string[,string]*

以逗号分隔列表的形式指定测试规则类的名称。如需引用规则类 foo_test，请使用字符串“foo”。Bazel 将仅测试（如果还指定了 --build_tests_only）构建引用的规则类的目标。如需排除这些目标，请使用字符串“-foo”。例如，

  % bazel test --test_lang_filters=foo,bar //baz/...

将仅测试 //baz/... 中属于 foo_test 或 bar_test 实例的目标，而

  % bazel test --test_lang_filters=-foo,-bar //baz/...

将测试 //baz/... 中的所有目标（foo_test 和 bar_test 实例除外）。

--test_filter=filter-expression

指定测试运行程序可用来选择要运行的部分测试的过滤器。调用中指定的所有目标都会构建，但只有部分执行可以执行，具体取决于表达式；在某些情况下，只有特定测试方法可以运行。

对 filter-expression 的具体解读取决于负责运行测试的测试框架。它可能是 glob、子字符串或正则表达式。与传递不同的 --test_arg 过滤条件参数相比，--test_filter 非常便捷，但并非所有框架都支持该参数。

详细程度

这些选项可以控制 Bazel 输出到终端或其他日志文件的详细程度。

--explain=logfile

此选项需要文件名参数，这会导致 bazel build 的执行阶段中的每个构建步骤都说明执行它的原因或原因为最新。说明已写入 logfile。

如果您遇到意外的重新构建，此选项有助于理解原因。将其添加到 .bazelrc，以便在所有后续构建中都进行日志记录，然后在看到执行步骤意外执行时检查日志。此选项的性能可能会下降，因此如果您不再需要它，不妨将其移除。

--verbose_explanations

此选项可提高启用 --explain 选项时生成的说明的详细程度。

具体而言，如果启用详细解释，并且由于构建它所用的命令已更改，因此需要重新构建输出文件，那么说明文件中的输出将包含新命令的完整详细信息（至少对于大多数命令）。

使用此选项可能会显著增加生成的说明文件的长度，并降低使用 --explain 的性能。

如果未启用 --explain，则 --verbose_explanations 不会产生任何影响。

--profile=file

此选项采用文件名参数，会导致 Bazel 将分析数据写入文件。然后，可以使用 bazel analyze-profile 命令分析或解析数据。Build 配置文件可用于了解 Bazel 的 build 命令将时间花在了何处。

--[no]show_loading_progress

此选项会使 Bazel 输出软件包加载进度消息。如果已停用，系统将不会显示消息。

--[no]show_progress

此选项可使系统显示进度消息；此功能默认处于开启状态。如果停用此设置，系统会禁止显示进度消息。

--show_progress_rate_limit=n

此选项会导致 Bazel 每 n 秒最多显示一个进度消息，其中 n 是一个实数。此选项的默认值为 0.02，这意味着 Bazel 将进度消息限制为每 0.02 秒一次。

--show_result=n

此选项用于控制 bazel build 命令末尾的结果信息输出。默认情况下，如果指定了单个构建目标，则 Bazel 会输出一条消息，说明目标是否已成功更新，如果成功，则会创建目标创建的输出文件列表。如果指定了多个目标，则不会显示结果信息。

虽然结果信息可能对于单个目标或少数目标 build 很有用，但对于大型构建（例如整个顶级项目树），这些信息可能会让您应接不暇且分散注意力；此选项可让您对其进行控制。--show_result 接受一个整数参数，即系统应输出完整结果信息的目标数量上限。默认情况下，值为 1。超过此阈值时，系统将不会显示各个目标的任何结果信息。因此，零会导致结果信息始终被抑制，非常大的值会导致系统始终输出结果。

如果用户定期构建少量目标（例如，在编译-修改-测试周期期间）和大量目标（例如，建立新工作区或运行回归测试时），则可能会选择两者之间的值。在前一种情况下，结果信息非常有用，但在后一种情况下，它的实用性要低得多。与所有选项一样，您可以通过 .bazelrc 文件隐式指定结果。

系统会输出这些文件，以便轻松将文件名复制并粘贴到 shell 中，以运行构建的可执行文件。每个目标的“最新”或“失败”消息都可以通过驱动 build 的脚本轻松解析。

--sandbox_debug

选择此选项后，Bazel 在使用沙盒执行操作时，会输出额外的调试信息。此选项还会保留沙盒目录，以便检查执行期间可见的文件。

--subcommands（-s）

此选项会使 Bazel 的执行阶段先输出每个命令的完整命令行，然后再执行。

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

请尽可能使用与 Bourne shell 兼容的语法来输出命令，以便轻松将其复制并粘贴到 shell 命令提示符中。 （提供周围括号是为了保护您的 shell 免受 cd 和 exec 调用的作用；请务必复制它们！） 但是，某些命令会在 Bazel 内部实现，例如创建符号链接树。对于这些，没有可供显示的命令行。

可以通过传递 --subcommands=pretty_print 来以列表（而非一行）的形式输出命令参数。这有助于提高长命令行的可读性。

另请参阅下文的 --verbose_failures。

如需将工具的子命令记录为适用于工具的格式，请参阅 --execute_log_json_file 和 --execute_log_binary_file。

--verbose_failures

此选项会导致 Bazel 的执行阶段输出失败的命令的完整命令行。这对于调试失败的 build 非常有用。

失败的命令以与 Bourne shell 兼容的语法显示，适用于复制和粘贴 shell 提示符。

工作区状态

使用这些选项对 Bazel 构建的二进制文件进行“标记”：可将额外的信息嵌入到二进制文件中，如源代码控制修订版本或其他与工作区相关的信息。您可以将此机制与支持 stamp 特性的规则（例如 genrule、cc_binary 等）一起使用。

--workspace_status_command=program

通过此标记，您可以指定 Bazel 在每次构建之前运行的二进制文件。该程序可以报告有关工作区状态的信息，如当前源代码控制修订版本。

该标记的值必须是原生程序的路径。在 Linux/macOS 上，这可能是任何可执行文件。 在 Windows 上，此文件必须是原生二进制文件，通常为“.exe”“.bat”或“.cmd”文件。

程序应输出零个或多个键值对到标准输出，每行一个条目，然后零退出（否则，构建会失败）。键名可以是任意名称，但只能使用大写字母和下划线。键名后面的第一个空格表示值。值是行的其余部分（包括额外的空格）。键和值都不能横跨多行。键不得重复。

Bazel 将密钥划分到两个存储分区中：“stable”和“volatile”。（“stable”和“volatile”这两个名称有点违背常理，因此不用在意）。

然后，Bazel 会将键值对写入两个文件：

• bazel-out/stable-status.txt 包含键以 STABLE_ 开头的所有键和值
• bazel-out/volatile-status.txt 包含其余键及其值

合同为：

• “稳定”键的值应尽可能极少更改。如果 bazel-out/stable-status.txt 的内容发生更改，则 Bazel 会使依赖于它们的操作失效。换句话说，如果稳定键的值发生更改，Bazel 将重新运行印章操作。因此，稳定状态不应包含时间戳等内容，因为它们会始终发生变化，并且会使 Bazel 在每次构建时重新运行标记操作。

  Bazel 始终会输出以下稳定版密钥：

  • BUILD_EMBED_LABEL：值 --embed_label
  • BUILD_HOST：运行 Bazel 的主机的名称
  • BUILD_USER：Bazel 运行时所用的用户名称

• “volatile”键的值可能会经常变化。Bazel 希望时间戳和时间戳一样都会发生变化，并会及时更新 bazel-out/volatile-status.txt 文件。不过，为了避免始终重新运行印记操作，Bazel 会假定易变文件始终保持不变。换句话说，如果易变状态文件是唯一一个内容发生更改的文件，则 Bazel 不会使其依赖操作失效。如果操作的其他输入已更改，则 Bazel 会重新运行该操作，该操作将看到更新后的易变状态，但仅更改易变状态不会使操作失效。

  Bazel 始终会输出以下易失性键：

  • BUILD_TIMESTAMP：自 Unix 纪元起的秒数（System.currentTimeMillis() 的值除以一千）
  • FORMATTED_DATE：build 的时间，格式为 yyyy MMM d HH mm ss EEE（例如 2023 年 6 月 2 日 01 44 29 日 世界协调时间）。

在 Linux/macOS 上，您可以传递 --workspace_status_command=/bin/true 以停用检索工作区状态，因为 true 不执行任何操作（成功退出，不输出），也不会输出任何内容。在 Windows 上，您可以传递 MSYS 的 true.exe 的路径来达到相同的效果。

如果工作区状态命令因任何原因失败（退出非零），build 将失败。

使用 Git 的 Linux 上的程序示例：

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

使用 --workspace_status_command 传递此程序的路径，稳定的状态文件将包含 STABLE 行，而 volatile 状态文件将包含其余行。

--[no]stamp

此选项与 stamp 规则属性一起控制是否在二进制文件中嵌入 build 信息。

可以使用 stamp 属性根据每条规则明确启用或停用标记。如需了解详情，请参阅《构建百科全书》。当规则设置 stamp = -1（*_binary 规则的默认设置）时，此选项用于确定是否启用冲压。

无论此选项或 stamp 特性如何，Bazel 绝不会为为执行配置构建的二进制文件签名。对于设置 stamp = 0 的规则（*_test 规则的默认设置），无论 --[no]stamp 为何，戳记都会停用。指定 --stamp 不会强制重新构建依赖项的依赖项未更改。

通常情况下，最好设置 --nostamp 来提高 build 性能，因为它可以减少输入波动并最大限度地提高构建缓存。

平台

使用这些选项可以控制配置构建的工作原理的主机和目标平台，以及 Bazel 规则可用的执行平台和工具链。

请参阅关于平台和工具链的背景信息。

--platforms=labels

平台规则的标签，用于描述当前命令的目标平台。

--host_platform=label

用于描述主机系统的平台规则的标签。

--extra_execution_platforms=labels

可作为执行平台执行操作的平台。 平台可以按确切目标指定，或作为目标模式指定。这些平台将由 register_execute_platforms() 在 WORKSPACE 文件中声明的平台之前考虑。此选项会按优先级顺序接受以英文逗号分隔的平台列表。 如果多次传递该标志，则最新的替换值。

--extra_toolchains=labels

在工具链解析过程中要考虑的工具链规则。工具链可以按确切目标指定，也可以指定为目标模式。这些工具链将由 register_toolchains() 在 WORKSPACE 文件中声明的之前考虑。

--toolchain_resolution_debug=regex

如果工具链类型与正则表达式匹配，则输出调试信息并查找工具链。多个正则表达式可以用英文逗号分隔。正则表达式可以通过在开头使用 - 来否定。这有助于 Bazel 或 Starlark 规则的开发者调试由于缺少工具链而失败。

其他

--flag_alias=alias_name=target_path

一种便捷标记，用于将较长的 Starlark build 设置绑定到较短的名称。如需了解详情，请参阅 Starlark 配置。

--symlink_prefix=string

用于更改生成的便利符号链接的前缀。符号链接前缀的默认值为 bazel-，这将创建符号链接 bazel-bin、bazel-testlogs 和 bazel-genfiles。

如果由于任何原因无法创建符号链接，系统会发出警告，但 build 仍会被视为成功。尤其是，这让您可以在只读目录或您无权写入的目录中进行构建。在构建结束时输出到信息消息中的任何路径都只会在符号链接指向预期位置时才使用符号链接相对的短格式；换句话说，您可以依赖于这些路径的正确性，即使您不能依赖正在创建的符号链接也是如此。

此选项的一些常见值：

• 禁止创建符号链接：--symlink_prefix=/ 会导致 Bazel 无法创建或更新任何符号链接，包括 bazel-out 和 bazel-<workspace> 符号链接。使用此选项可完全禁止创建符号链接。

• 减少杂乱：--symlink_prefix=.bazel/ 会导致 Bazel 在隐藏目录 .bazel 中创建一个名为 bin 等的符号链接。

--platform_suffix=string

为配置简称添加后缀，用于确定输出目录。将此选项设置为不同的值时，会将文件放入不同的目录中，例如，为构建提高缓存命中率，否则会相互覆盖输出文件，或保留输出文件以进行比较。

--default_visibility=(private|public)

用于测试 Bazel 默认可见性更改的临时标志。并非用于常规用途，而是为了完整而记录。

--starlark_cpu_profile=_file_

此标记的值是文件的名称，它会导致 Bazel 收集所有 Starlark 线程的 CPU 使用情况统计信息，并以 pprof 格式将配置文件写入指定文件。

使用此选项可帮助您确定 Starlark 函数，该函数会导致计算速度过慢而导致加载和分析速度变慢。例如：

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

对于同一数据的不同视图，请尝试使用 pprof 命令 svg、web 和 list。

使用 Bazel 发布

开发周期中，软件工程师和发布工程师在准备二进制文件以部署到生产环境时，都使用 Bazel。本部分针对使用 Bazel 的发布工程师提供提示列表。

重要选项

使用 Bazel 发布 build 时，会出现与执行 build 的其他脚本相同的问题。如需了解详情，请参阅从脚本调用 Bazel。具体而言，强烈建议以下选项：

• --bazelrc=/dev/null
• --nokeep_state_after_build

以下选项也很重要：

• --package_path
• --symlink_prefix：用于针对多种配置管理 build，因此使用唯一标识符（例如“64bit”与“32bit”）区分各个 build 可能很方便。此选项可区分 bazel-bin（等）符号链接。

运行测试

如需使用 Bazel 构建和运行测试，请输入 bazel test，然后输入测试目标的名称。

默认情况下，此命令会同时执行构建和测试活动，构建所有指定的目标（包括在命令行中指定的任何非测试目标），并在构建 *_test 和 test_suite 的前提条件后立即进行测试，这意味着测试执行会交错进行构建。这样做通常可以显著提高速度。

“bazel test”的选项

--cache_test_results=(yes|no|auto)（-t）

如果此选项设置为“auto”（默认值），则 Bazel 只有在满足以下任一条件时才会重新运行测试：

• Bazel 检测测试或其依赖项的变化
• 测试被标记为 external
• 使用 --runs_per_test 请求了多次测试运行
• 测试失败。

如果选择“否”，则所有测试都将无条件执行。

如果为“yes”，则缓存行为与 auto 相同，只不过它可能会缓存测试失败并使用 --runs_per_test 运行测试。

如果用户在其 .bazelrc 文件中默认启用了此选项，对于在特定运行期间替换默认设置的用户而言，缩写为 -t（开启）或 -t-（关闭）会非常方便。

--check_tests_up_to_date

此选项会告知 Bazel 不要运行测试，而只需检查和报告缓存的测试结果。如果存在之前尚未构建和运行的任何测试，或者其测试结果已过时（例如，由于源代码或构建选项已更改），则 Bazel 将报告错误消息（“测试结果不是最新状态”），并将测试的状态记录为“NO STATUS”（如果启用了颜色输出，则输出为零）。

此选项也表示 [--check_up_to_date](#check-up-to-date) 行为。

此选项可能对提交前检查很有用。

--test_verbose_timeout_warnings

此选项会告知 Bazel，如果测试的超时时间明显长于测试的实际执行时间，则明确警告用户。虽然测试的超时应不稳定地设置，但具有足够宽松的超时的测试可以隐藏意外出现的真实问题。

例如，通常在一两分钟内执行的测试不应包含 ETERNAL 或 LONG 的超时，因为它们非常宽松。

此选项有助于用户确定合适的超时值或健全性检查现有超时值。

--[no]test_keep_going

默认情况下，所有测试都会运行完成。但是，如果停用此标记，任何未通过的测试都会取消构建。后续构建步骤和测试调用不会运行，运行中调用也会被取消。请勿同时指定 --notest_keep_going 和 --keep_going。

--flaky_test_attempts=attempts

此选项指定测试因任何原因失败时的最大尝试次数。如果测试初始失败，但最终成功，则会在测试摘要中报告为 FLAKY。不过，当识别 Bazel 退出代码或通过的测试总数时，系统会认为已通过测试。如果测试未通过所有允许的尝试次数，即被视为失败。

默认情况下（如果您未指定此选项或将其设置为默认值），常规测试只允许执行一次尝试操作，如果设置了 flaky 属性，则测试规则只允许尝试 3 次。您可以指定整数值来替换测试尝试次数上限。为了防止滥用系统，Bazel 最多允许尝试 10 次。

--runs_per_test=[regex@]number

此选项指定每个测试应执行的次数。所有测试作业都被视为单独的测试（回退功能将分别适用于每个测试）。

运行失败的目标的状态取决于 --runs_per_test_detects_flakes 标志的值：

• 如果不运行，任何失败的运行都会导致整个测试失败。
• 如果存在，并且来自同一分片的两次运行返回“PASS”和“FAIL”，则测试将收到不稳定的状态（除非其他失败的运行导致测试失败）。

如果指定了单个数字，则所有测试都将运行多次。或者，也可以使用语法 regex@number 指定正则表达式。这会将 --runs_per_test 的效果限制为与正则表达式匹配的目标（--runs_per_test=^//pizza:.*@4 会运行 //pizza/ 4 次以下的所有测试）。 这种形式的 --runs_per_test 可以多次指定。

--[no]runs_per_test_detects_flakes

如果指定此选项（默认情况下未指定），Bazel 将通过 --runs_per_test 检测不稳定的测试分片。如果对单个分片的一次或多次运行失败，并且对同一分片遍历运行一次或多次，目标将被视为不稳定，带有标志。如果未指定，目标将报告失败状态。

--test_summary=output_style

指定测试结果摘要的显示方式。

• 如果测试失败，short 会输出每个测试的结果以及包含测试输出的文件的名称。此设置为默认值。
• terse，例如 short，但会更加简短：仅输出未通过的测试的信息。
• detailed 会输出每个失败的测试用例，而不仅仅是每个测试。测试输出文件的名称将被省略。
• none 不会输出测试摘要。

--test_output=output_style

指定应如何显示测试输出：

• summary 显示每个测试是通过还是失败的摘要。还会显示失败测试的输出日志文件名。摘要会在构建结束时输出（在构建期间，测试开始、通过或失败时，用户只会看到简单的进度消息）。这是默认行为。
• errors 仅在测试完成后立即将失败测试的组合 stdout/stderr 输出发送到 stdout，以确保来自并发测试的测试输出不相互交错。根据上面的摘要输出在构建时输出摘要。
• all 与 errors 类似，但输出所有测试（包括通过的测试）的输出。
• streamed 会实时流式传输每个测试的 stdout/stderr 输出。

--java_debug

此选项会使 Java 测试的 Java 虚拟机等待从与 JDWP 兼容的调试程序建立连接，然后再启动测试。此选项表示 --test_output=streamed。

--[no]verbose_test_summary

默认情况下，此选项处于启用状态，系统会将测试时间和其他信息（例如测试尝试）输出到测试摘要中。如果指定了 --noverbose_test_summary，测试摘要将仅包含测试名称、测试状态和缓存的测试指示器，并且将设置为不超过 80 个字符的格式。

--test_tmpdir=path

为本地执行的测试指定临时目录。每个测试都将在此目录下的单独子目录中执行。每个 bazel test 命令的开头都会清除此目录。默认情况下，bazel 会将此目录放在 Bazel 输出基目录下。

--test_timeout=seconds 或 --test_timeout=seconds,seconds,seconds,seconds

使用指定的秒数作为新的超时值来替换所有测试的超时值。如果只提供一个值，此值将用于所有测试超时类别。

或者，您也可以使用四个逗号分隔值，分别指定短、中、长和永久测试的超时时间。无论采用哪种形式，任何测试大小的零值或负值都将替换为编写测试页面中定义的指定超时类别的默认超时时间。 默认情况下，Bazel 将通过根据测试的大小推断出超时限制（无论是隐式还是显式设置），借此在所有测试中使用这些超时。

明确将超时类别明确与其大小不同的测试将收到相同的值，就好像该大小标记已隐式设置该超时一样。因此，声明“超时”超时时间的“小”测试与“大”测试没有有效超时时，具有相同的有效超时。

--test_arg=arg

将命令行选项/标志/参数传递给每个测试进程。此选项可多次用于传递多个参数。例如，--test_arg=--logtostderr --test_arg=--v=3。

--test_env=variable=_value_ 或 --test_env=variable

指定必须为每个测试注入测试环境的其他变量。如果未指定 value，它将从用于启动 bazel test 命令的 shell 环境继承。

可以使用 System.getenv("var") (Java)、getenv("var")（C 或 C++）从测试中访问环境，

--run_under=command-prefix

这会指定一个测试运行程序在运行测试命令之前将插入的前缀。使用 Bourne shell 词元化规则将 command-prefix 拆分为多个单词，然后单词列表将附加到要执行的命令前面。

如果第一个单词是完全限定标签（以 // 开头），则会构建它。然后，标签将替换为相应的可执行位置，该位置将附加到与其他字词一起执行的命令。

需要注意以下几点：

• 用于运行测试的 PATH 可能与您环境中的 PATH 不同，因此您可能需要使用 --run_under 命令（command-prefix 中的第一个字词）的绝对路径。
• stdin 未连接，因此 --run_under 不能用于交互式命令。

示例：

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

测试选择

如输出选择选项下所述，您可以按大小、超时、标记或语言过滤测试。便捷的通用名称过滤器可以将特定的过滤器参数转发到测试运行程序。

“bazel test”的其他选项

其语法和其余选项与 bazel build 完全相同。

运行可执行文件

bazel run 命令类似于 bazel build，不过它用于构建和运行单个目标。下面是一个典型的会话：

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run 与直接调用 Bazel 构建的二进制文件类似，但其行为有所不同，具体取决于要调用的二进制文件是否为测试。

如果二进制文件不是测试文件，那么当前工作目录将是二进制文件的运行文件树。

当二进制文件是测试时，当前工作目录将是执行根目录，并且本着善意原则来尝试复制通常运行的环境测试。不过，模拟并不完美，包含多个分片的测试无法通过这种方式运行（可使用 --test_sharding_strategy=disabled 命令行选项解决此问题）

该二进制文件还提供了以下额外的环境变量：

• BUILD_WORKSPACE_DIRECTORY：运行 build 的工作区的根目录。
• BUILD_WORKING_DIRECTORY：运行 Bazel 的当前工作目录。

例如，这些文件名可用于以方便用户使用的方式解释命令行上的文件名。

“bazel run”的选项

--run_under=command-prefix

这与 bazel test 的 --run_under 选项的作用相同（见上文），但它适用于由 bazel run 运行的命令，而不是由 bazel test 运行的测试，并且无法在标签下运行。

过滤 Bazel 的日志记录输出

使用 bazel run 调用二进制文件时，Bazel 会输出 Bazel 本身以及调用中的二进制文件的输出日志记录。如需降低日志的嘈杂程度，您可以使用 --ui_event_filters 和 --noshow_progress 标志禁止显示 Bazel 本身的输出。

例如：bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp。

执行测试

bazel run 还可以执行测试二进制文件，这样可以在编写测试中所述的近似环境下运行测试。请注意，除 --test_arg 之外，在以这种方式运行测试时，--test_* 参数均不会产生任何影响。

清理构建输出

clean 命令

Bazel 有一个 clean 命令，类似于 Make。它会删除此 Bazel 实例执行的所有构建配置或此 Bazel 实例创建的整个工作树的输出目录，并重置内部缓存。如果在没有任何命令行选项的情况下执行，则系统会清除所有配置的输出目录。

回想一下，每个 Bazel 实例都与一个工作区相关联，因此，clean 命令将删除您在该工作区中对相应 Bazel 实例执行的所有构建的所有输出。

如需完全移除 Bazel 实例创建的整个工作树，您可以指定 --expunge 选项。使用 --expunge 执行时，干净命令会仅移除整个输出基本树，除了构建输出之外，该文件还会包含 Bazel 创建的所有临时文件。而且，它会在清理后相当于运行 Bazel 服务器，相当于 shutdown 命令。例如，如需清理 Bazel 实例的所有磁盘和内存跟踪记录，您可以指定：

  % bazel clean --expunge

或者，您也可以使用 --expunge_async 在后台清除。您可以放心地在同一客户端中调用 Bazel 命令，同时继续清除异步清除。

我们提供 clean 命令主要是为不再需要的工作区回收磁盘空间。Bazel 的增量重新构建可能并不完善，因此当出现问题时，可以使用 clean 恢复一致的状态。

根据 Bazel 的设计，这些问题是可以修复的，并优先修复这些 bug。如果您发现错误的增量 build，请在工具中提交 bug 报告并报告 bug（而不是使用 clean）。

查询依赖关系图

Bazel 包含一个查询语言，用于询问与构建期间使用的依赖关系图有关的问题。查询语言供两个命令使用：query 和 cquery。这两个命令之间的主要区别在于，查询在加载阶段之后运行，而 cquery 在分析阶段之后运行。这些工具是许多软件工程任务的重要帮助。

查询语言基于图表上的代数运算这一概念；如需了解详情，请参阅

Bazel 查询参考文档。如需查看相关示例和查询专用命令行选项，请参阅该文档。

查询工具接受多个命令行选项。--output 用于选择输出格式。--[no]keep_going（默认情况下处于停用状态）会导致查询工具在出现错误后继续执行进度；如果遇到错误，不接受不完整的结果，则此行为可能会被停用。

默认情况下，--[no]tool_deps 选项会使非目标配置中的依赖项包含在运行查询的依赖关系图中。

--[no]implicit_deps 选项（默认处于启用状态）会使隐式依赖项包含在运行查询的依赖项关系图中。隐式依赖项未在 BUILD 文件中明确指定，但由 bazel 添加。

示例：“显示 PEBL 树中构建所有测试所需的所有 Genrule 的定义（在 BUILD 文件中）的位置。”

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

查询操作图

您可以使用 aquery 命令查询构建图中的操作。此模型针对配置后分析的目标图运行，并公开有关操作、工件及其关系的信息。

该工具接受多个命令行选项。 --output 用于选择输出格式。默认输出格式 (text) 直观易懂，使用 proto 或 textproto 表示机器可读的格式。值得注意的是，query 命令在常规 Bazel build 之上运行，并继承在 build 期间可用的一组选项。

它支持同样适用于传统 query（但 siblings、buildfiles 和 tests）的一组函数。

如需了解详情，请参阅操作图查询。

其他命令和选项

help

help 命令可提供在线帮助。默认情况下，它会显示可用命令和帮助主题的摘要，如使用 Bazel 构建中所示。指定参数可显示特定主题的详细帮助。大多数主题都是 Bazel 命令，例如 build 或 query，但还有一些与命令不对应的其他帮助主题。

--[no]long（-l）

默认情况下，bazel help [topic] 仅输出主题的相关选项摘要。如果指定了 --long 选项，系统还会输出每个选项的类型、默认值和完整说明。

shutdown

Bazel 服务器进程可以使用 shutdown 命令停止。此命令会使 Bazel 服务器在进入空闲状态（例如，完成任何正在进行的构建或其他目前正在运行的命令后）后立即退出。如需了解详情，请参阅客户端/服务器实现。

Bazel 服务器在空闲超时后自行停止，因此很少需要此命令；但是，当知道给定工作区中不会再发生任何构建时，此命令在脚本中很有用。

shutdown 接受一个选项，即 --iff_heap_size_greater_than _n_，这需要整数参数（以 MB 为单位）。如果已指定，则会导致关停已根据内存消耗量确定。这对于启动大量构建的脚本非常有用，因为 Bazel 服务器中的任何内存泄漏都可能造成它偶尔崩溃；执行条件重启会导致抢占此条件。

info

info 命令会输出与 Bazel 服务器实例或特定构建配置相关联的各种值。（可供驱动 build 的脚本使用）。

info 命令还允许使用单个（可选）参数，该参数是以下列表中某个键的名称。在这种情况下，bazel info key 将仅输出该键的值。（这在为 Bazel 编写脚本时尤其方便，因为这可以避免通过 sed -ne /key:/s/key://p 传输结果）：

与配置无关的数据

• release：此 Bazel 实例的版本标签（如果此版本不是已发布的二进制文件，则为“开发版本”）。
• workspace 是基本工作区目录的绝对路径。

• install_base：此 Bazel 实例为当前用户使用的安装目录的绝对路径。Bazel 会将它在内部必需的可执行文件安装到此目录下。

• output_base：此 Bazel 实例为当前用户和工作区组合使用的基本输出目录的绝对路径。Bazel 会将其所有暂存内容放在此目录下并构建输出。

• execution_root：output_base 下执行根目录的绝对路径。此目录是可在构建期间执行的命令访问的所有文件的根目录，也是这些命令的工作目录。如果工作区目录可写，则名为 bazel-<workspace> 的符号链接将指向该目录。

• output_path：执行目录下输出目录的绝对路径，用于通过 build 命令实际生成的所有文件。如果工作区目录可写入，名为“bazel-out”的符号链接将指向该目录。

• server_pid：Bazel 服务器进程的进程 ID。

• server_log：Bazel 服务器的调试日志文件的绝对路径。此文件包含 Bazel 服务器生命周期内所有命令的调试信息，旨在供 Bazel 开发者和高级用户使用。

• command_log：命令日志文件的绝对路径；其中包含最新 Bazel 命令的交错 stdout 和 stderr 流。请注意，运行 bazel info 会覆盖此文件的内容，因为它会成为最新的 Bazel 命令。但是，除非您更改 --output_base 或 --output_user_root 选项的设置，否则命令日志文件的位置不会更改。

• used-heap-size、committed-heap-size、max-heap-size：报告各种 JVM 堆大小参数。分别是：当前已使用的内存、当前可供系统使用的 JVM 的内存（可能的分配）。

• gc-count、gc-time：自此 Bazel 服务器启动以来的垃圾回收计数以及执行这些回收所花费的时间。请注意，每次构建开始时，这些值都不会重置。

• package_path：以英文冒号分隔的路径列表，用于按 Bazel 搜索软件包。格式与 --package_path 构建命令行参数相同。

示例：Bazel 服务器的进程 ID。

% bazel info server_pid
1285

特定于配置的数据

这些数据可能会受到传递给 bazel info 的配置选项（例如 --cpu、--compilation_mode 等）的影响。info 命令接受控制依赖项分析的所有选项，因为其中一些选项决定了 build 输出目录的位置、编译器的选择等。

• bazel-bin、bazel-testlogs、bazel-genfiles：报告 build 生成的程序所在的 bazel-* 目录的绝对路径。通常情况下，这不一定与成功构建后在基础工作区目录中创建的 bazel-* 符号链接相同。不过，如果工作区目录是只读的，则无法创建 bazel-* 符号链接。使用 bazel info 报告的值（而不是假定符号链接存在）的脚本会更加可靠。
• 完整的“Make”环境。如果指定了 --show_make_env 标志，则还会显示当前配置的“Make”环境中的所有变量（例如 CC、GLIBC_VERSION 等）。这些是 BUILD 文件中使用 $(CC) 或 varref("CC") 语法访问的变量。

示例：当前配置的 C++ 编译器。 这是“Make”环境中的 $(CC) 变量，因此需要 --show_make_env 标志。

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

示例：当前配置的 bazel-bin 输出目录。即使由于某种原因（例如，您是在只读目录中构建）而无法创建 bazel-bin 符号链接，这种方法也一定是正确的。

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version和--version

version 命令可输出有关已构建 Bazel 二进制文件的版本详细信息，包括构建该文件的变更列表和日期。这些日志特别有助于确定您是否拥有最新的 Bazel，或者是否报告了 bug。以下是一些有趣的值：

• changelist：此版本的 Bazel 发布后的变更列表。
• label：此 Bazel 实例的版本标签（如果此版本不是已发布的二进制文件，则为“开发版本”）。在报告 bug 时非常有用。

不带其他参数的 bazel --version 将发出与 bazel version --gnu_format 相同的输出，不过没有副作用，可能会导致启动 Bazel 服务器或解压缩服务器归档。bazel --version 可以从任何位置运行，它不需要工作区目录。

mobile-install

mobile-install 命令可将应用安装到移动设备。 目前仅支持运行 ART 的 Android 设备。

如需了解详情，请参阅 bazel mobile-install。

支持的选项如下：

--incremental

如果设置了此标记，Bazel 会尝试增量安装应用，也就是说，只有上次构建以来发生更改的部分。此操作无法更新从 AndroidManifest.xml、原生代码或 Java 资源（如 Class.getResource() 引用的资源）引用的资源。如果这些内容发生变化，则必须忽略此选项。与 Bazel 的精神相反，由于 Android 平台的局限性，用户有责任了解此命令何时足够好以及何时需要完整安装。

如果您使用的是搭载 Marshmallow 或更高版本的设备，请考虑使用 --split_apks 标志。

--split_apks

是否使用拆分 APK 安装和更新设备上的应用。 仅适用于运行 Marshmallow 或更高版本的设备。请注意，使用 --split_apks 时，不需要 --incremental 标志。

--start_app

安装应用后，以干净状态启动应用。等同于 --start=COLD。

--debug_app

在安装后等待应用处于干净状态后再附加调试程序。 等同于 --start=DEBUG。

--start=_start_type_

安装应用后应如何启动。支持的 _start_type_s 包括：

• NO 无法启动应用。这是默认设置。
• COLD：在安装后从干净状态启动应用。
• WARM 在增量安装时保留并恢复应用状态。
• DEBUG：在安装后等待应用处于干净状态之前，等待调试程序。

--adb=path

指示要使用的 adb 二进制文件。

默认方法是在 --android_sdk 指定的 Android SDK 中使用 adb。

--adb_arg=serial

adb 的额外参数。这些参数位于命令行中的子命令之前，通常用于指定要安装到的设备。例如，如需选择要使用的 Android 设备或模拟器，请运行以下命令：

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

调用 adb

adb -s deadbeef install ...

--incremental_install_verbosity=number

增量安装的详细程度。设置为 1 表示要输出到控制台中的调试日志记录。

dump

dump 命令将输出 stdout（即 Bazel 服务器的内部状态的转储）。此命令主要供 Bazel 开发者使用，因此未指定输出，随时可能更改。

默认情况下，命令将仅输出帮助消息，列出转储 Bazel 状态的特定区域的可能选项。如需转储内部状态，必须至少指定一个选项。

支持的选项如下：

• --action_cache 会转储操作缓存内容。
• --packages 会转储软件包缓存内容。
• --skyframe 会转储内部 Bazel 依赖关系图的状态。
• --rules 会转储每个规则和宽高比类的规则摘要，包括计数和操作数。这包括原生和 Starlark 规则。如果启用了内存跟踪，则还会输出规则的内存消耗量。
• --skylark_memory 会将 pprof 兼容的 .gz 文件转储到指定的路径。您必须启用内存跟踪功能才能使用此功能。

内存跟踪

某些 dump 命令需要内存跟踪。如需开启此功能，您必须将启动标志传递给 Bazel：

• --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
• --host_jvm_args=-DRULE_MEMORY_TRACKER=1

Java 代理会在 third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar 签入 Bazel，因此请务必针对 Bazel 代码库的存储位置调整 $BAZEL。

不要忘记针对每个命令继续将这些选项传递给 Bazel，否则服务器会重启。

例如：

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

analyze-profile 命令可分析之前在 Bazel 调用期间收集的 JSON 跟踪配置文件。

canonicalize-flags

canonicalize-flags 命令，该命令接受 Bazel 命令的选项列表，并返回具有相同效果的选项列表。新的选项列表是规范网页。例如，具有相同效果的两个选项列表会规范化为同一个新列表。

--for_command 选项可用于在不同命令之间进行选择。目前，仅支持 build 和 test。给定命令不支持的选项会导致错误。

示例：

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

启动选项

本部分介绍的选项会影响 Bazel 服务器进程使用的 Java 虚拟机的启动，这些选项适用于该服务器处理的所有后续命令。如果已有正在运行的 Bazel 服务器，但启动选项不匹配，则它会重启。

必须使用 --key=value 或 --key value 语法指定本部分中所述的所有选项。此外，这些选项必须出现在 Bazel 命令的名称之前。使用 startup --key=value 将它们列在 .bazelrc 文件中。

--output_base=dir

此选项需要路径参数，该参数必须指定可写目录。Bazel 将使用此位置写入其所有输出。输出基也是客户端定位 Bazel 服务器的键。通过更改输出基站，可以更改将处理该命令的服务器。

默认情况下，输出基础会派生自用户的登录名和工作区目录的名称（实际上是其 MD5 摘要），因此典型值如下所示：/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e。

例如：

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

在此命令中，这两个 Bazel 命令同时运行（由于 shell & 运算符），每个命令使用不同的 Bazel 服务器实例（因为输出基础不同）。相反，如果两个命令中都使用默认输出基数，则这两个请求都会发送到同一服务器，服务器将依序处理这两个请求：先构建 //foo，然后构建 //bar 的增量 build。

--output_user_root=dir

指向创建输出和安装基础的根目录。该目录必须不存在，或者归发起调用的用户所有。过去，允许指向在不同用户之间共享的目录，但现在不再允许此类目录。解决问题 11100 后，这可能会允许。

如果指定了 --output_base 选项，它会替换使用 --output_user_root 来计算输出基数。

安装量基于 --output_user_root 以及 Bazel 嵌入式二进制文件的 MD5 身份计算得出。

如果您的文件系统布局中存在更好的位置，您可以使用 --output_user_root 选项为 Bazel 的所有输出（安装量和输出基准）选择备用基准位置。

--server_javabase=dir

指定 Bazel 运行所在的 Java 虚拟机。该值必须是指向包含 JDK 或 JRE 的目录的路径。它不能是一个标签。 此选项应显示在任何 Bazel 命令之前，例如：

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

此标志不会影响 Bazel 子进程（如应用、测试、工具等）使用的 JVM。请改用构建选项 --javabase 或 --host_javabase。

此标记之前名为 --host_javabase（有时称为“左侧”--host_javabase），但后来重命名，以避免与构建标志 --host_javabase（有时称为“右侧”--host_javabase）混淆。

--host_jvm_args=string

指定将传递给运行 Bazel 本身的 Java 虚拟机的启动选项。这可用于设置堆栈大小，例如：

  % bazel --host_jvm_args="-Xss256K" build //foo

此选项可多次用于单个参数。请注意，很少需要设置此标志。您还可以传递以空格分隔的字符串列表，每个字符串都会被解读为单独的 JVM 参数，但此功能即将被弃用。

这不会影响 Bazel 子进程使用的任何 JVM：应用、测试、工具等。如需将 JVM 选项传递给可执行的 Java 程序（无论是通过 bazel run 运行，还是从命令行运行），您应该使用所有 java_binary 和 java_test 程序都支持的 --jvm_flags 参数。或者，您也可以使用 bazel test --test_arg=--jvm_flags=foo ... 进行测试。

--host_jvm_debug

此选项会使 Java 虚拟机等待来自与 JDWP 兼容的调试程序的连接，然后再调用 Bazel 本身的主要方法。它主要供 Bazel 开发者使用。

--autodetect_server_javabase

此选项会使 Bazel 在启动时自动搜索已安装的 JDK，并在嵌入式 JRE 不可用时回退到已安装的 JRE。 --explicit_server_javabase 可用于选择要运行 Bazel 的显式 JRE。

--batch

批处理模式会导致 Bazel 不使用标准客户端/服务器模式，而是针对单个命令运行 Bazel Java 进程，该模式用于在信号处理、作业控制和环境变量继承方面用于可预测的语义，对于在 chroot 监狱中运行 Bazel 而言，是必需的。

批处理模式保留了相同的 output_base 中适当的队列语义。也就是说，并发调用将按顺序处理，而不会出现重叠。如果在使用正在运行的服务器的客户端上运行批处理模式，则 Bazel 会先处理该服务器，然后再处理该命令。

Bazel 在批处理模式下或使用上述替代方案可以运行速度较慢。这是因为，除了其他方面，build 文件缓存是内存驻留的，而不会在顺序批量调用之间保留。因此，在性能不太重要的情况（例如连续构建）下，使用批处理模式通常更合理。

--max_idle_secs=n

此选项可指定 Bazel 服务器进程在最后一次客户端请求之后应退出多长时间（以秒为单位）。默认值为 10800（3 小时）。--max_idle_secs=0 会导致 Bazel 服务器进程无限期保留。

调用 Bazel 的脚本可以使用此选项，以确保它们不会在用户不会运行时从用户计算机离开 Bazel 服务器进程。例如，提交前脚本可能希望调用 bazel query 以确保用户的待处理更改不会引入不需要的依赖项。但是，如果用户尚未在该工作区中完成近期的构建，那么提交前脚本无需启动 Bazel 服务器即可使其在当天的剩余时间内保持空闲状态。通过在查询请求中指定一个很小的 --max_idle_secs 值，脚本可以确保如果它导致新服务器启动，则服务器会立即退出；但如果已经有服务器在运行，则该服务器会继续运行，直到其通常处于空闲状态。当然，现有服务器的空闲计时器将会重置。

--[no]shutdown_on_low_sys_mem

启用后，如果 --max_idle_secs 被设为正时长，构建服务器在空闲一段时间后，当系统内存不足时，将关闭服务器。仅 Linux。

除了运行与 max_idle_secs 对应的空闲检查之外，构建服务器还将在服务器处于空闲一段时间后开始监控可用系统内存。如果可用系统内存变得非常低，服务器将退出。

--[no]block_for_lock

启用后，Bazel 将等待持有服务器锁的其他 Bazel 命令，然后再继续。如果停用，如果 Bazel 无法立即获取锁并继续，则会错误退出。

开发者可以在提交前检查中使用此方法，以避免由同一客户端中的其他 Bazel 命令导致的长时间等待。

--io_nice_level=n

设置一个从 0 到 7 的级别，以尽可能提高 IO 调度效率。0 表示优先级最高，7 表示最低。预期调度器最多只能支持优先级 4。 负值会被忽略。

--batch_cpu_scheduling

为 Bazel 使用 batch CPU 调度功能。此政策对于非交互式但不想降低其良好值的工作负载非常有用。 请参阅“man 2 sched_setscheduler”。此政策可提供更好的系统互动能力，但代价是 Bazel 吞吐量。

其他选项

--[no]announce_rc

控制 Bazel 是否在启动时读出在 bazelrc 文件中读取的命令选项。（无条件地公布启动选项。）

--color (yes|no|auto)

此选项用于确定 Bazel 是否会使用颜色在屏幕上突出显示其输出。

如果此选项设置为 yes，系统会启用颜色输出。 如果此选项设置为 auto，则仅当输出发送到终端且 TERM 环境变量设置为 dumb、emacs 或 xterm-mono 以外的值时，Bazel 才会使用颜色输出。 如果此选项设置为 no，则无论输出是否指向终端，也无论 TERM 环境变量如何设置，颜色输出都会停用。

--config=name

从 rc 文件中选择其他配置部分；对于当前的 command，它还会从 command:name 提取选项（如果存在此类部分）。您可以多次指定此标记，以便添加来自多个配置部分的标志。展开内容可以引用其他定义（例如，展开内容可以链接起来）。

--curses (yes|no|auto)

此选项用于确定 Bazel 是否会在其屏幕输出中使用光标控件。这有助于减少滚动数据量，以及从 Bazel 输出更精简、更易读的信息流。它非常适合与 --color 搭配使用。

如果此选项设置为 yes，则能够使用光标控件。 如果将此选项设为 no，系统会禁止使用光标控件。 如果此选项设置为 auto，则系统会根据与 --color=auto 相同的条件启用光标控件。

--[no]show_timestamps

如果指定，则系统会向 Bazel 生成的每条消息添加时间戳，以指定消息的显示时间。