本页面介绍了适用于各种 Bazel 命令的选项
例如 bazel build、bazel run 和 bazel test。此网页是随播网页
转到使用 Bazel 构建中的 Bazel 命令列表。
目标语法
某些命令（例如 build 或 test）可以对目标列表执行操作。它们使用的语法比标签更灵活，如指定要构建的目标中所述。
选项
以下各部分介绍了在配置期间
build。在 help 命令中使用 --long 时，在线
帮助消息提供有关应用含义、类型和
默认值。
大多数选项只能指定一次。如果指定多次， 最后一个实例胜出。可多次指定的选项包括 在线帮助中注明“可能多次使用”字样。
软件包位置
--package_path
警告：--package_path 选项已废弃。Bazel 更倾向于将主代码库中的软件包放在工作区根目录下。
此选项用于指定用于搜索给定软件包的 BUILD 文件的一组目录。
Bazel 会通过搜索软件包路径来查找软件包。这是一个冒号 按顺序排列的单独 bazel 目录列表，每个 bazel 目录都是 部分源代码树。
如需使用 --package_path 选项指定自定义软件包路径，请执行以下操作：
% bazel build --package_path %workspace%:/some/other/root
软件包路径元素可以采用以下三种格式进行指定：
- 如果第一个字符为
/，则路径为绝对路径。 - 如果路径以
%workspace%开头，则路径相对于最近的封闭 bazel 目录。例如，如果您的工作目录 为/home/bob/clients/bob_client/bazel/foo，则 软件包路径中的字符串%workspace%已展开 发送至/home/bob/clients/bob_client/bazel。 - 其他所有内容都将相对于工作目录采用。
这通常不是您想要的，如果您在 bazel 工作区下方的目录中使用 Bazel，可能会出现意外行为。例如，如果您使用 package-path 元素
.，然后 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 MODULE.bazel % bazel build --package_path /some/other/path //foo
--deleted_packages
此选项指定了以英文逗号分隔的软件包列表，Bazel 应将这些软件包视为已删除，并且不会尝试从软件包路径上的任何目录加载这些软件包。这可用于模拟删除软件包的操作 确实会删除它们此选项可以多次传递，在这种情况下，系统会串联各个列表。
错误检查
这些选项用于控制 Bazel 的错误检查和/或警告。
--[no]check_visibility
如果此选项设置为 false，则可见性检查会降级为警告。 此选项的默认值为 true。 检查已完成。
--output_filter=regex
--output_filter 选项仅会针对与正则表达式匹配的目标显示 build 和编译警告。如果目标不匹配给定的正则表达式且其执行成功，则其标准输出和标准错误会被舍弃。
以下是此选项的一些典型值：
| `--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 选项类似，但仅适用于 exec 配置。
--host_conlyopt=cc-option
此选项接受一个参数，该参数将传递给在 exec 配置中编译的 C 源文件的编译器。类似于
--conlyopt 选项，但仅适用于
更改为 exec 配置。
--host_cxxopt=cc-option
此选项带有一个参数，该参数将传递给 C++ 源文件的编译器
在 exec 配置中编译的应用。类似于
--cxxopt 选项，但仅适用于
exec 配置。
--host_linkopt=linker-option
此选项接受一个参数，该参数将传递给在 exec 配置中编译的源文件的链接器。这与 --linkopt 选项类似，但仅适用于 exec 配置。
--conlyopt=cc-option
此选项接受一个参数，该参数将在编译 C 源文件时传递给编译器。
它与 --copt 类似，但仅适用于 C 编译，
而不是 C++ 编译或链接。这样您就可以传递特定于 C 的选项
（例如 -Wno-pointer-sign）。--conlyopt
--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 类似，但仅适用于链接，而不适用于编译。因此，您可以传递只有意义的编译器选项
（例如 -lssp 或 -Wl,--wrap,abort）
使用 --linkopt。例如：
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
制作规则还可以在其属性中指定关联选项。此选项的 设置始终优先。另请参阅 cc_library.linkopts。
--strip (always|never|sometimes)
此选项决定了 Bazel 是否会从
所有二进制文件和共享库，方法是使用 -Wl,--strip-debug 选项调用链接器。
--strip=always 表示始终剥离调试信息。--strip=never 表示永远不剥离调试信息。默认值为 --strip=sometimes，表示如果 --compilation_mode
为 fastbuild。
% 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 - 这会在最终二进制文件完成上传后应用剥离操作
链接，而不是在构建的所有链接操作中进行剥离。
--stripopt=strip-option
这是在生成 *.stripped 二进制文件时要传递给 strip 命令的额外选项。默认
为 -S -p。此选项可多次使用。
--fdo_instrument=profile-output-dir
--fdo_instrument 选项支持
FDO（反馈导向型优化）配置文件会输出
会执行构建的 C/C++ 二进制文件。对于 GCC，所提供的参数将用作
.gcda 文件的每个对象文件目录树的目录前缀
包含每个 .o 文件的配置文件信息。
在配置文件数据树生成之后，配置文件树
压缩文件后提供给
--fdo_optimize=profile-zip
用于启用 FDO 优化编译的 Bazel 选项。
对于 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 llvm-profdata 工具准备的配置文件输出文件，其中应包含 .profdata 。
选项 --fdo_instrument 和 --fdo_optimize 不能同时使用。
--java_language_version=version
此选项用于指定 Java 源代码的版本。例如：
% bazel build --java_language_version=8 java/com/example/common/foo:all
编译，并且仅允许与 Java 8 规范兼容的构造。
默认值为 8。-->
可能的值为：8、9、10、11、14、15 和 21，您可以使用 default_java_toolchain 注册自定义 Java 工具链来扩展这些值。
--tool_java_language_version=version
Java 语言版本，用于构建在构建期间执行的工具。 默认值为 8。
--java_runtime_version=version
此选项指定用于执行代码和运行测试的 JVM 版本。例如：
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
从远程代码库下载 JDK 11 并使用 JDK 11 运行 Java 应用。
默认值为 local_jdk。
可能的值包括：local_jdk、local_jdk_version、remotejdk_11 和 remotejdk_17。您可以扩展这些值，只需使用
local_java_repository 或 remote_java_repository 代码库规则。
--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 默认调试信息重新构建 java_binary （而不是 bazel 默认值）。
选项会在 Bazel 内置默认选项之后传递给 javac javac 和 per-rule 选项之前。最后一个规范是 javac 的任何选项都适用。javac 的默认选项包括：
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
此选项用于控制 javac 是否检查缺少的直接依赖项。 Java 目标必须将所有直接使用的目标明确声明为 依赖项此标记指示 javac 确定实际使用的 JAR 用于对每个 java 文件进行类型检查，并在不是输出时发出警告/错误 当前目标的直接依赖项。
off表示检查已停用。warn表示 javac 会生成以下标准 Java 警告： 为每个缺失的直接依赖项类型[strict]。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）的 build。除非您还传递--copt -g，否则opt模式不会生成调试信息。
--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 插入构建图。
--[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 架构的名称。
--android_platforms=platform[,platform]*
用于构建以下对象的传递 deps 的平台：
android_binary 规则（特别是针对 C++ 等原生依赖项）。对于
例如，如果 cc_library 出现在deps
android_binary规则，则对于使用
针对 android_binary 规则为 --android_platforms，并包含在最终规则中
输出。
此标志没有默认值：必须使用自定义 Android 平台 定义和使用的方法。
系统会为使用 --android_platforms 指定的每个平台创建一个 .so 文件，并将其打包到 APK 中。.so 文件的名称是
包含“lib”的 android_binary 规则。例如，如果 android_binary 的名称为“foo”，则文件为 libfoo.so。
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
标签或执行路径与某个包含正则表达式相匹配的任何 C++ 文件（如果存在）
将构建不匹配任何排除表达式的表达式
。标签匹配使用规范形式的标签。
（即 //package:label_name）。
执行路径是工作区目录的相对路径，包括基本名称 （包括扩展名）。它还包括任何依赖于平台的前缀。
为了匹配生成的文件（例如 genrule 输出）
Bazel 只能使用执行路径。在这种情况下，正则表达式不应以“//”开头，因为它与任何执行路径都不匹配。软件包名称可采用以下格式：
--per_file_copt=base/.*\.pb\.cc@-g0。与每
.pb.cc 文件（位于名为 base 的目录下）。
此选项可以多次使用。
无论使用哪种编译模式，都会应用此选项。例如，您可以使用 --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 选项添加到 //foo/ 中除 file.cc 之外的所有 .cc 文件的 C++ 编译器命令行。
--dynamic_mode=mode
确定 C++ 二进制文件是否将动态链接，并与构建规则中的 linkstatic 属性进行交互。
模式：
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
如果设置了此标志，则 linkopt 中的任何 -static 选项
cc_* 规则 BUILD 文件会被忽略。这只能作为
针对 C++ 安全加固 build 的临时解决方案。
--[no]force_pic
如果启用，所有 C++ 编译都会生成位置无关代码 ("-fPIC")， 链接首选 PIC 预构建库而不是非 PIC 库，并且链接生成 位置独立的可执行文件（“-pie”）。默认为停用。
--android_resource_shrinking
选择是否为 android_binary 规则执行资源缩减。为 shrink_resources 属性 android_binary 规则；有关详情，请参阅关于该规则的文档。默认为关闭。
--custom_malloc=malloc-library-target
指定后，始终使用给定的 malloc 实现，替换所有 malloc="target" 属性，包括使用默认值（通过不指定任何 malloc）的目标。
--crosstool_top=label
此选项用于指定要用于构建期间的所有 C++ 编译的跨平台编译器套件的所在位置。Bazel 会查看
CROSSTOOL 文件的位置，并使用该位置自动确定
--compiler的设置。
--host_crosstool_top=label
如果未指定，Bazel 将使用 --crosstool_top 的值来编译 exec 配置中的代码，例如构建期间运行的工具。此标记的主要用途
启用交叉编译
--apple_crosstool_top=label
用于在 objc*、ios* 和 apple* 规则的传递 deps 中编译 C/C++ 规则的交叉工具。对于这些目标，此标志会覆盖 --crosstool_top。
--compiler=version
此选项用于指定在构建过程中用于编译二进制文件的 C/C++ 编译器版本（例如 gcc-4.1.0）。如果您想
则应该使用 CROSSTOOL 文件而不是
指定此标记。
--android_sdk=label
已弃用。不应直接指定此值。
此选项用于指定将用于构建任何与 Android 相关的规则的 Android SDK/平台工具链和 Android 运行时库。
如果 android_sdk_repository，系统会自动选择 Android SDK
在 WORKSPACE 文件中定义。
--java_toolchain=label
无运维。仅用于实现向后兼容性。
--host_java_toolchain=label
无操作。仅出于向后兼容性目的而保留。
--javabase=(label)
无操作。仅出于向后兼容性目的而保留。
--host_javabase=label
无操作。仅出于向后兼容性目的而保留。
执行策略
这些选项会影响 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 Genrule）。如需了解支持的策略及其影响，请参阅 --spawn_strategy。
--strategy_regexp=<filter,filter,...>=<strategy>
此选项用于指定应使用哪种策略来执行与特定 regex_filter 匹配的描述的命令。如需详细了解 regex_filter 匹配，请参阅 --per_file_copt。请参阅
--spawn_strategy（适用于受支持的
策略及其影响。
系统会使用与说明匹配的最后一个 regex_filter。此选项会替换用于指定策略的其他标志。
- 示例：
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local表示使用local策略（如果其说明与 //foo.*.cc 匹配，但不相符 //foo/bar）。 - 示例：
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed运行“Compiling //foo/bar/baz”sandboxed策略，但逆转 订单会使用local运行它。 - 示例：
--strategy_regexp='Compiling.*/bar=local,sandboxed'运行 “编译 //foo/bar/baz”然后回退到localsandboxed。
--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 为单位的 RAM 和 CPU 逻辑核心数）。它们会
整数或关键字（HOST_RAM 或 HOST_CPUS），可以选择后跟 [-|*float]
（例如 --local_cpu_resources=2、--local_ram_resources=HOST_RAM*.5、
--local_cpu_resources=HOST_CPUS-1）。
标志是独立的；可以设置其中之一，也可以同时设置两者。默认情况下，Bazel 会直接根据本地系统的配置来估算 RAM 用量和 CPU 核心数。
--[no]build_runfile_links
此选项默认处于启用状态，用于指定运行文件
测试和二进制文件的符号链接应在输出目录中构建。
使用 --nobuild_runfile_links
验证是否所有目标都能编译而不会产生开销
用于构建 Runfile 树。
执行测试（或应用）时，其运行时数据
所有依赖项集中在一起在 Bazel 的
输出树就是这个“runfiles”树通常作为
相应的二进制文件或测试。
在测试执行期间，可以使用 $TEST_SRCDIR/canonical_repo_name/packagename/filename 格式的路径访问 runfile。Runfiles 树可确保测试能够访问
即表明它们确实存在依赖关系默认情况下，运行文件树是通过构建指向所需文件的一组符号链接来实现的。随着链接数的增加
会计算此操作的成本
会显著增加总构建时间，尤其是在
每个单独的测试（或应用）都需要有自己的 runfiles 树。
--[no]build_runfile_manifests
此选项默认处于启用状态，用于指定 runfiles 清单
应该写入输出树。
将其停用意味着 --nobuild_runfile_links。
在远程执行测试时，可以停用此功能，因为 runfile 树将从内存中的清单远程创建。
--[no]discard_analysis_cache
启用此选项后，Bazel 将舍弃分析缓存 从而释放额外的内存 执行阶段（约 10%）。 缺点是，后续增量构建的速度会变慢。另请参阅 内存节省模式。
--[no]keep_going (-k)
与在 GNU Make 中一样，当第一个 错误。有时，即使遇到错误，也应尝试尽可能进行构建，这很有用。此选项可启用此行为，如果指定此选项，构建系统会尝试构建已成功构建其前提条件的每个目标，但会忽略错误。
虽然此选项通常与
还会影响分析阶段：如果有多个目标
但只有部分规则可以
成功分析后，构建将停止并报错
除非已指定 --keep_going，在这种情况下，
构建将进入执行阶段，但仅针对目标
分析成功的数据
--[no]use_ijars
此选项会改变java_library定位条件的方式
由 Bazel 编译而成Bazel 不会使用 java_library 的输出来编译依赖的 java_library 目标，而是会创建仅包含非私有成员（公共、受保护和默认 [软件包] 访问方法和字段）签名的接口 jar，并使用接口 jar 来编译依赖的目标。这样，当仅更改类的方法体或私有成员时，就可以避免重新编译。
--[no]interface_shared_objects
此选项会启用接口共享对象，从而将二进制文件和 其他共享库依赖于共享对象的接口， 而非实现方式当只有实现发生变化时，Bazel 可以避免重新构建依赖于更改后的共享库的目标 不需要。
输出选择
这些选项决定了要构建或测试的内容。
--[no]build
此选项会触发构建的执行阶段；默认处于开启状态。关闭此选项后，执行阶段为 并且只执行前两个阶段，即加载和分析。
此选项非常适合验证 BUILD 文件和检测输入中的错误，而无需实际构建任何内容。
--[no]build_tests_only
如果指定，Bazel 将仅构建运行 *_test 所需的内容
以及 test_suite 条规则未被滤除
size、
timeout、
标签或
语言。
如果指定了此参数，Bazel 会忽略命令行中指定的其他目标。
默认情况下，此选项处于停用状态，并且 Bazel 将构建请求的所有内容，包括从测试中滤除的 *_test 和 test_suite 规则。这很有用，因为运行 bazel test --build_tests_only foo/... 可能无法检测 foo 树中的所有构建故障。
--[no]check_up_to_date
此选项会导致 Bazel 不执行构建，而只是检查 指定的所有目标是否都是最新的。如果是，构建会照常成功完成。但是，如果有任何文件已过时，系统会报告错误，并导致构建失败，而不是进行构建。此选项可能有助于确定某个 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 将仅构建具有至少一个必需标记（如果指定了任何必需标记）且不含任何排除标记的目标。build 标记 过滤器指定为以逗号分隔的标记关键字列表， 以“-”开头号用于表示排除的代码。必需的标记 前面带有“+”号。
运行测试时，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
和
% 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 将
test（如果也指定了 --build_tests_only，则为 build）
所引用规则类的目标要排除这些目标，请使用
字符串“-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 的特定解释最高为
负责运行测试的测试框架。它可以是通配符、子字符串或正则表达式。--test_filter 是为了提供便利
传递不同的 --test_arg 过滤条件参数时，
但并非所有框架都支持
详细程度
这些选项可以控制 Bazel 输出的详细程度 或其他日志文件
--explain=logfile
此选项需要一个文件名参数，会导致 bazel build 执行阶段中的依赖项检查器针对每个 build 步骤说明其执行原因或其处于最新状态。说明会写入日志文件。
如果您遇到意外重建，此选项可以帮助您了解原因。将其添加到 .bazelrc，以便为所有后续 build 进行日志记录，然后在您看到意外执行的执行步骤时检查日志。此选项
可能会对效果产生轻微影响，因此建议您删除
以便在不再需要时提供。
--verbose_explanations
此选项会在启用 --explain 选项时增加生成的说明的详细程度。
具体而言，如果启用了详细说明，并且由于用于构建输出文件的命令已更改而重新构建了输出文件，则说明文件中的输出将包含新命令的完整详细信息（至少对于大多数命令而言）。
使用此选项可能会大幅增加
使用生成的说明文件会降低性能，
--explain。
如果 --explain 未启用，则 --verbose_explanations 不会产生任何影响。
--profile=file
此选项接受文件名参数，会导致 Bazel 将性能分析数据写入文件。然后，您可以使用 bazel analyze-profile 命令分析或解析数据。构建配置文件有助于了解 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 可能很有用，但对于大型 build（例如整个顶级项目树），这些信息可能会令人眼花缭乱，让人分心；通过此选项，您可以控制这些信息。--show_result
采用一个整数参数，该参数表示目标数量上限
并输出其完整结果信息。默认情况下
其值为 1。高于此阈值时，不会出现任何结果信息
。因此，如果为零，则会导致系统始终抑制结果信息；如果为非常大的值，则会导致系统始终输出结果。
用户经常希望选择一个介于
您可以交替构建少量目标（例如，
和大量目标
（例如，在创建新工作区或
回归测试）。在前一种情况下，结果信息为
在后一种情况下，它就没那么实用了。与所有
选项，可以通过
.bazelrc 文件。
系统会输出这些文件，以便您轻松将文件名复制并粘贴到 shell 中，以运行构建的执行文件。“最新版本” 或“已失败”即可轻松通过脚本解析每个目标的消息 来驱动构建的
--sandbox_debug
此选项会导致 Bazel 在为 Action 使用沙盒时输出额外的调试信息 执行。此选项还会保留沙盒目录，以便文件对操作可见 可以检查。
--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。
如需以工具友好的格式将子命令记录到文件中，请参阅 --execution_log_json_file 和 --execution_log_binary_file.
--verbose_failures
此选项会使 Bazel 的执行阶段输出完整的命令行 检查失败的命令这对于调试 构建失败。
失败的命令会以与 Bourne shell 兼容的语法输出， 可将其复制并粘贴到 shell 提示符中。
工作区状态
使用这些选项可以“印章”Bazel 构建的二进制文件：
二进制文件，例如源代码控制修订版本或其他与工作区相关的信息。您可以使用
该机制具有支持 stamp 属性的规则，例如
genrule、cc_binary等。
--workspace_status_command=program
借助此标志，您可以指定 Bazel 在每次构建之前运行的二进制文件。程序可以报告 有关工作区状态的信息，例如当前的源代码控制修订版本。
该标记的值必须是原生程序的路径。在 Linux/macOS 上，这可以是任何可执行文件。在 Windows 上，文件必须是原生二进制文件，通常为“.exe”、“.bat”或“.cmd”文件。
该程序应将零个或多个键值对输出到标准输出，每行一个条目，然后返回 0（否则构建会失败）。键名可以是任意名称 请使用大写字母和下划线。键名后面的第一个空格用于分隔 值。值是该行的其余部分（包括其他空格）。键和值均不得跨多行。键不得重复。
Bazel 将密钥划分为两个存储分区：“stable”和“volatile”值。（“稳定”和“易失”这两个名称有点违反直觉，因此请不要过多关注它们。）
然后，Bazel 会将键值对写入两个文件：
bazel-out/stable-status.txt包含键名称以STABLE_开头的所有键和值bazel-out/volatile-status.txt包含其余键及其值
合同如下：
“stable”钥匙的应尽量避免更改这些值（如果可能）。如果
bazel-out/stable-status.txt则 Bazel 会使依赖于它们的操作失效。在 换句话说，如果稳定键的值发生变化，Bazel 将重新运行已标记的操作。 因此，稳定状态不应包含时间戳之类的内容，因为它们 并且让 Bazel 在每次构建时都重新运行标记的操作Bazel 始终输出以下稳定键：
BUILD_EMBED_LABEL：--embed_label的值BUILD_HOST：运行 Bazel 的主机的名称BUILD_USER：Bazel 以哪个用户身份运行
“易失性”键的值可能会经常更改。Bazel 会希望它们始终发生变化 并及时更新
bazel-out/volatile-status.txt文件。不过，为了避免始终重新运行带有时间戳的操作，Bazel 会假装易失性文件永远不会更改。换句话说，如果 volatile 状态文件是唯一一个内容 则 Bazel 不会使依赖于它的操作失效。如果操作的其他输入 则 Bazel 会重新运行该操作，并且该操作将看到更新后的 volatile 状态，但只要发生变化不会导致操作失效。Bazel 始终会输出以下易失性键：
BUILD_TIMESTAMP：自 Unix Epoch（Unix 纪元）开始的构建时间（以秒为单位）。 除以System.currentTimeMillis()除以 1000）FORMATTED_DATE：构建时间，格式设置为yyyy MMM d HH mm ss EEE（例如 2023 年 6 月 201 日 44 29 周五），采用世界协调时间(UTC)。
在 Linux/macOS 上，您可以将 --workspace_status_command=/bin/true 传递给
禁止检索工作区状态，因为 true 未成功执行任何操作（退出
零）不输出任何内容。在 Windows 上，您可以传递 MSYS 的 true.exe 路径以实现相同的效果。
如果工作区状态命令因任何原因失败（退出非零状态），构建将失败。
使用 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 行，易失性状态文件将包含其余行。
--[no]stamp
此选项与 stamp 规则属性结合使用，可控制是否
在二进制文件中嵌入 build 信息。
您可以使用 stamp 属性按规则明确启用或停用加盖章功能。有关详情，请参阅“构建百科全书”。时间
规则设置 stamp = -1（*_binary 规则的默认值），此选项
确定是否已启用标记。
Bazel 绝不会标记针对 exec 配置构建的二进制文件，
无论此选项或 stamp 属性如何。对于设置 stamp =
0（*_test 规则的默认值）的规则，无论 --[no]stamp 如何，都会停用加盖章功能。如果存在以下情况，指定 --stamp 不会强制重新构建目标：
其依赖项没有发生变化
通常希望设置 --nostamp 来提高构建性能，因为它
降低输入波动并最大化构建缓存。
平台
您可以使用这些选项来控制用于配置构建方式的宿主平台和目标平台，以及控制 Bazel 规则可用的执行平台和工具链。
--platforms=labels
平台规则的标签，用于描述当前命令的目标平台。
--host_platform=label
用于描述主机系统的平台规则的标签。
--extra_execution_platforms=labels
可用作执行平台来运行操作的平台。 平台可以通过确切目标或目标模式进行指定。这些平台会优先于通过 register_execution_platforms() 在 MODULE.bazel 文件中声明的平台得到考虑。此选项接受以逗号分隔的平台列表（按优先级排序）。如果多次传递此标志，则最新的标志会替换之前的标志。
--extra_toolchains=labels
工具链解析期间要考虑的工具链规则。工具链可以通过确切目标或目标模式指定。这些工具链 先于 MODULE.bazel 文件中声明的网址进行 register_toolchains().
--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。具体而言，以下选项 两种方法
这些选项也很重要：
--package_path--symlink_prefix：如需管理多个配置的 build，您可以使用不同的标识符（例如“64 位”与“32 位”）来区分每个 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请求多次测试运行 - 测试失败。
如果为“no”，则系统将无条件地执行所有测试。
如果选择“是”，缓存行为将与自动缓存行为相同
只不过它会缓存测试失败情况，并使用
--runs_per_test。
如果用户在 .bazelrc 文件中默认启用了此选项，则可以使用缩写 -t（开启）或 -t-（关闭）来覆盖特定运行的默认设置。
--check_tests_up_to_date
此选项指示 Bazel 不要运行测试，而只是检查和报告 缓存的测试结果如果有任何测试未通过 或者其测试结果已经过时（例如， 源代码或构建选项发生变化），则 Bazel 会 将记录测试的 状态为“NO STATUS”（如果启用了颜色输出，则返回红色）， 非零退出代码。
此选项还暗示 --check_up_to_date 行为。
此选项对于提交前检查可能很有用。
--test_verbose_timeout_warnings
此选项指示 Bazel 在测试超时时明确警告用户 大大超过测试的实际执行时间。虽然测试的超时设置应确保测试不会不稳定，但超时过长的测试可能会掩盖意外出现的实际问题。
例如，一个通常在一两分钟内执行的测试 “ETERNAL”或“LONG”的超时值，因为它们太过慷慨了。
此选项有助于用户确定合适的超时值或对现有超时值进行合理性检查。
--[no]test_keep_going
默认情况下，所有测试都会运行至完成。不过，如果停用此标志，则在任何测试未通过时都会中止 build。系统不会运行后续 build 步骤和测试调用，并且会取消正在进行的调用。请勿同时指定 --notest_keep_going 和 --keep_going。
--flaky_test_attempts=attempts
此选项指定应尝试测试的最大次数
如果由于任何原因而失败如果测试一开始失败，但最终成功，测试摘要中会将其报告为 FLAKY。不过，在确定 Bazel 退出代码或通过的测试总数时，该测试会被视为通过。如果测试在所有允许的尝试中都失败，则会被视为失败。
默认（当此选项未指定或设置为
默认），常规测试仅允许一次尝试，以及
3 表示设置了 flaky 属性的测试规则。您可以指定
一个整数值，用于覆盖测试尝试次数上限。为防止滥用系统，Bazel 最多允许 10 次测试尝试。
--runs_per_test=[regex@]number
此选项用于指定应执行每项测试的次数。全部 测试作业会被视为单独的测试（回退功能） 将分别应用于每项功能）。
运行失败的目标的状态取决于 --runs_per_test_detects_flakes 标志的值：
- 如果不存在，任何失败的运行都会导致整个测试失败。
- 如果存在，并且来自同一分片的两次运行分别返回“通过”和“失败”，则测试将收到不稳定的状态（除非其他失败的运行导致其失败）。
如果指定单个数字，则所有测试都将运行该次数。
或者，也可以使用以下语法指定正则表达式：
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 会通过从测试大小（无论是隐式还是显式设置的大小）推断超时限制，为所有测试使用这些超时设置。
明确声明超时类别不同于 尺寸接收的值将与 尺寸标记。因此，对“small”大小进行测试它声明一个“long”超时将会 其有效超时时间与“大型”测试中 超时。
--test_arg=arg
将命令行选项/标志/参数传递给每个测试进程。此选项可多次使用，以传递多个实参。例如，--test_arg=--logtostderr --test_arg=--v=3。
请注意，与 bazel run 命令不同，您无法像在 bazel test -- target --logtostderr --v=3 中那样直接传递测试参数。这是因为
传递给 bazel test 的无关参数会被解释为额外测试
目标。也就是说，--logtostderr 和 --v=3 都会被解释为测试目标。bazel run 命令不存在这种模糊性，它只接受一个目标。
--test_arg 可以传递给 bazel run 命令，但除非
正在运行的目标是一个测试目标。（与其他任何标记一样，如果在
bazel run 命令放在 -- 令牌之后，它不会由 Bazel 处理，
向执行的目标一字不差地转发。）
--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，不同之处在于
它用于构建和运行单个目标。以下是一个典型的会话
（//java/myapp:myapp 说 hello 并输出其参数）：
% bazel run java/myapp:myapp -- --arg1 --arg2
INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
INFO: Found 1 target...
Target //java/myapp:myapp up-to-date:
bazel-bin/java/myapp/myapp
INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
INFO: Build completed successfully, 4 total actions
INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
Hello there
$EXEC_ROOT/java/myapp/myapp
--arg1
--arg2
bazel run 与直接调用由 Bazel 构建的二进制文件类似，但并不完全相同，其行为因要调用的二进制文件是否为测试而异。
如果二进制文件不是测试文件，则当前工作目录将是 二进制文件的 runfiles 树
如果二进制文件是测试，则当前工作目录将是执行根目录，并且会尽力重现测试通常运行的环境。不过，此模拟并不完美，
无法以这种方式运行（
可以使用 --test_sharding_strategy=disabled 命令行选项
来解决这个问题）
二进制文件还可以使用以下额外的环境变量：
BUILD_WORKSPACE_DIRECTORY：工作区的根目录， build 的状态。BUILD_WORKING_DIRECTORY：运行 Bazel 的当前工作目录。
例如，这些命令可用于在命令行中解释 以方便用户使用的方式
“bazel run”的选项
--run_under=command-prefix
这与 --run_under 选项的
bazel test（参见上文）、
只不过它适用于 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 有一个类似于 Make 的 clean 命令。
它会删除执行的所有构建配置的输出目录
或者由此 Bazel 实例创建的整个工作树
Bazel 实例，以及重置内部缓存。如果不使用任何命令行选项执行，则系统会清理所有配置的输出目录。
回想一下，每个 Bazel 实例都与单个工作区相关联，因此 clean 命令会删除您在该工作区中使用该 Bazel 实例完成的所有 build 的所有输出。
彻底移除由 Bazel 创建的整个工作树
实例，您可以指定 --expunge 选项。时间
使用 --expunge 执行整洁命令时，直接
移除整个输出基本树，除了 build
输出，其中包含由 Bazel 创建的所有临时文件。它还
在执行清理后停止 Bazel 服务器，这相当于 shutdown 命令。例如，
清理 Bazel 实例的所有磁盘和内存跟踪记录
指定：
% bazel clean --expunge
或者，您也可以使用 --expunge_async 在后台清除数据。调用 Bazel 命令是安全的
同时异步清除继续运行。
clean命令主要用作
为不再需要的工作区回收磁盘空间。
Bazel 的增量重新构建
因此 clean 可用于恢复一致的
在出现问题时的状态
Bazel 的设计使得这些问题是可以解决的，并且这些 bug 是需要优先解决的。如果您
发现错误的增量 build、提交 bug 报告以及在工具中报告 bug
而不是使用 clean。
查询依赖图
Bazel 包含一种查询语言， 构建期间使用的依赖关系图。查询语言使用 查询和 cquery 两条命令这两个命令之间的主要区别在于，query 在加载阶段之后运行，而 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 命令在 build 图中查询操作。它会对分析后配置的目标图表进行操作，并公开有关操作、工件及其关系的信息。
该工具接受多个命令行选项。--output 选择输出格式。默认输出格式 (text) 是直观易懂的，请使用 proto 或 textproto 以机器可读的格式。值得注意的是，aquery 命令运行在常规 Bazel 构建之上，并且继承了
构建期间可用的一组选项。
它支持的一系列功能与传统
query，但 siblings、buildfiles 和
tests。
如需了解详情，请参阅Action Graph 查询。
其他命令和选项
help
help 命令提供在线帮助。默认情况下，它会显示可用命令和帮助主题的摘要，如使用 Bazel 进行构建中所示。指定参数可显示特定主题的详细帮助。大多数主题都是 Bazel 命令，例如 build
或query，不过您还能看到
与命令不对应。
--[no]long（-l）
默认情况下，bazel help [topic] 仅输出主题的相关选项摘要。如果
已指定 --long 选项，类型，默认值
以及每个选项的完整说明。
shutdown
您可以使用 shutdown 停止 Bazel 服务器进程
命令。此命令会导致 Bazel 服务器在运行后立即退出
进入空闲状态（例如，在完成任何构建或其他
命令）。有关详情，请参阅
客户端/服务器实现。
Bazel 服务器会在空闲超时后自行停止，因此很少需要使用此命令；不过，如果您知道给定工作区不会再进行进一步构建，则可以在脚本中使用此命令。
shutdown接受一个
选项--iff_heap_size_greater_than _n_
需要整数参数（以 MB 为单位）。如果指定，则会关停
取决于已消耗的内存量这是
这对于启动大量构建的脚本非常有用，
数据泄露，可能会导致其在
时机执行条件式重启会抢占此条件。
info
info 命令会输出与
运行项目或者使用特定的构建配置
（这些变量可能会被用于驱动 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：执行根目录下输出目录的绝对路径，用于存放构建命令实际生成的所有文件。如果工作区目录是 可写，其中一个名为bazel-out的符号链接指向 复制到此目录中server_pid：Bazel 服务器进程的进程 ID。server_log：Bazel 服务器的调试日志文件的绝对路径。 此文件包含在 Bazel 服务器，专供 Bazel 开发者和高级用户使用。command_log：命令日志文件的绝对路径； 其中包含最近提供的 运行 Bazel 命令请注意，运行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：报告bazel-*目录，由 build 的位置。这通常（但并不总是）等同于 在基本工作区目录中创建的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，请将此项设为 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-agent 签入到 Bazel 中的
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar，因此请确保
请务必针对 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 命令会分析
之前的 JSON 轨迹配置文件
在 Bazel 调用期间收集的
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
启动选项
本部分介绍的选项会影响 Java 的启动 这些虚拟机是 Bazel 服务器进程使用的，并且适用于 由该服务器处理的后续命令如果已经有 Bazel 服务器在运行，并且启动选项不匹配，则会重启该服务器。
本部分介绍的所有选项必须使用
--key=value 或 --key value
语法。此外，这些选项必须显示在 Bazel 命令名称的前面。使用 startup --key=value 可在 .bazelrc 文件中列出这些内容。
--output_base=dir
此选项需要路径实参，该实参必须指定可写入的目录。Bazel 将使用此位置写入其所有输出。输出基准也是客户端定位 Bazel 服务器的键。通过更改输出基准，您将更改服务器 将负责处理命令
默认情况下，输出基准来自用户的登录名，
以及工作区目录（实际上是其 MD5 digest）的名称，
因此，典型值如下所示：
/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。
--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 子进程（如应用、测试、 工具等等使用构建选项 --javabase 或 --host_javabase。
此标志之前称为 --host_javabase（有时称为
“left-hand side”--host_javabase），但已重命名以避免与
构建标记 --host_javabase（有时称为
“right-hand side”--host_javabase）。
--host_jvm_args=string
指定要传递给运行 Bazel 本身的 Java 虚拟机的启动选项。这可用于设置堆栈大小，例如：
% bazel --host_jvm_args="-Xss256K" build //foo
此选项可以在单个参数中多次使用。请注意， 应该很少需要设置此标志。您还可以传递以空格分隔的字符串列表， 每个 JVM 参数都将解读为单独的 JVM 参数，但此功能很快就会被 已弃用。
此操作不影响
Bazel 的子进程：应用、测试、工具等。通过
可执行 Java 程序的 JVM 选项，无论是由 bazel
run 运行还是在命令行上运行，都应使用
--jvm_flags 参数，
所有 java_binary 和 java_test 计划
联系。或者，对于测试，请使用 bazel test --test_arg=--jvm_flags=foo ...。
--host_jvm_debug
此选项会导致 Java 虚拟机在调用 Bazel 本身的主方法之前等待来自符合 JDWP 规范的调试程序的连接。这主要供 Bazel 开发者使用。
--autodetect_server_javabase
此选项会导致 Bazel 在启动时自动搜索已安装的 JDK，如果嵌入式 JRE 不可用，则回退到已安装的 JRE。--explicit_server_javabase 可用于选择用于运行 Bazel 的显式 JRE。
--batch
批处理模式导致 Bazel 不使用 标准客户端/服务器模式，但运行 bazel java 进程的处理，已被用于提高可预测性 与信号处理、作业控制和环境相关的语义， 变量继承，并且是在 chroot 监狱中运行 bazel 所必需的。
批处理模式在同一 output_base 内保留适当的队列语义。 也就是说，同时进行的调用将按顺序处理，而不会出现重叠。 如果批处理模式 Bazel 在具有正在运行的服务器的客户端上运行，它首先 在处理命令之前终止服务器。
在批处理模式下，或者采用上述替代方案时，Bazel 的运行速度会变慢。 这是因为，除其他外，构建文件缓存驻留在内存中，因此不会在连续批量调用之间保留。因此，在性能不佳的情况下， 不太重要，例如持续构建。
--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 命令而导致长时间等待。
--io_nice_level=n
为尽力而为的 IO 调度设置一个级别（0-7）。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，则 Bazel 仅会在以下情况下使用颜色输出：
输出将发送到终端和 TERM 环境变量
设置为 dumb、emacs 或 xterm-mono 以外的值。
如果此选项设为 no，系统会停用颜色输出，
无论输出是否发送至终端
TERM 环境变量的设置部分。
--config=name
从 rc 文件中选择其他配置部分；对于当前 command，如果存在此类部分，它还会从 command:name 中提取选项。可以多次指定此字段，以从多个配置部分添加标志。扩展可以引用
定义（例如，可以链接展开）。
--curses (yes|no|auto)
此选项用于确定 Bazel 是否会在屏幕输出中使用光标控件。这样可以减少滚动数据
简单易懂的 Bazel 输出流。这种方法适用于
--color。
如果此选项设置为 yes，则启用光标控件。
如果此选项设为 no，则会停用光标控件。
如果此选项设为 auto，将使用光标控件
在与 --color=auto 相同的条件下启用。
--[no]show_timestamps
如果已指定，则会为通过 用于指定消息显示时间的 Bazel。