Startup Options

If set, Bazel will be run as just a client process without a server, instead of
in the standard client/server mode. This is deprecated and will be removed,
please prefer shutting down the server explicitly if you wish to avoid
lingering servers.
Tags:
loses_incremental_state, bazel_internal_configuration, deprecated

Only on Linux; use 'batch' CPU scheduling for Bazel. This policy is
useful for workloads that are non-interactive, but do not want to lower their
nice value. See 'man 2 sched_setscheduler'. If false, then Bazel does
not perform a system call.
Tags:
host_machine_resource_optimizations

The location of the user .bazelrc file containing default values of Bazel
options. If unspecified, Bazel uses the first .bazelrc file it finds in the
following two locations: the workspace directory, then the user's home
directory. Use /dev/null to disable the search for a user rc file, e.g. in
release builds.
Tags:
changes_inputs

If set, attempt to detect Java heap OOM conditions and exit before thrashing.
Only honored when --batch is also passed. In some cases, builds that previously
succeeded may OOM if they were close to OOMing before. Deprecated: Use the
command argument --experimental_oom_more_eagerly_threshold instead.
Tags:
loses_incremental_state, eagerness_to_exit

If this flag is set, Bazel will OOM if, after two full GC's, more than this
percentage of the (old gen) heap is still occupied. Deprecated: Use the command
argument --experimental_oom_more_eagerly_threshold instead.
Tags:
loses_incremental_state, eagerness_to_exit

Only on Linux; set a level from 0-7 for best-effort IO scheduling using the
sys_ioprio_set system call. 0 is highest priority, 7 is lowest. The
anticipatory scheduler may only honor up to priority 4. If set to a negative
value, then Bazel does not perform a system call.
Tags:
host_machine_resource_optimizations

If set, specifies the output location to which all build output will be
written. Otherwise, the location will be ${OUTPUT_ROOT}/_bazel_${USER}
/${MD5_OF_WORKSPACE_ROOT}. Note: If you specify a different option from one to
the next Bazel invocation for this value, you'll likely start up a new,
additional Bazel server. Bazel starts exactly one server per specified output
base. Typically there is one output base per workspace - however, with this
option you may have multiple output bases per workspace and thereby run
multiple builds for the same client on the same machine concurrently. See '
bazel help shutdown' on how to shutdown a Bazel server.
Tags:
affects_outputs, loses_incremental_state

The user-specific directory beneath which all build outputs are written; by
default, this is a function of $USER, but by specifying a constant, build
outputs can be shared between collaborating users.
Tags:
affects_outputs, loses_incremental_state

Create a new log file when the bazel server process (re)starts, and update
the java.log symbolic link to point to the new file. Otherwise, java.log would
be a regular file which would be overwritten each time the server process
starts.
Tags:
bazel_monitoring

Raises the soft coredump limit to the hard limit to make coredumps of the
server (including the JVM) and the client possible under common conditions.
Stick this flag in your bazelrc once and forget about it so that you get
coredumps when you actually encounter a condition that triggers them.
Tags:
bazel_internal_configuration

Convenience option to add some profiler/debugger-specific JVM startup flags.
Bazel has a list of known values that it maps to hard-coded JVM startup flags,
possibly searching some hardcoded paths for certain files.

If set to true, tools should be passed to `ctx.actions.run()` and `ctx.actions.
run_shell()` using the `tools` parameter instead of the `inputs` parameter.
Furthermore, if this flag is set and a `tools` parameter is not passed to the
action, it is an error for any tools to appear in the `inputs`.
Tags:
build_file_semantics, incompatible_change, triggered_by_all_incompatible_changes

If false, Bazel will not persist data that allows for invalidation and re-
evaluation on incremental builds in order to save memory on this build.
Subsequent builds will not have any incrementality with respect to this one.
Usually you will want to specify --batch when setting this to false.
Tags:
loses_incremental_state

Specifies the maximal size of stdout or stderr to be buffered in BEP, before it
is reported as a progress event. Individual writes are still reported in a
single event, even if larger than the specified value.
Tags:
affects_outputs

Specifies how long bazel should wait for the BES/BEP upload to complete after
the build and tests have finished. A valid timeout is a natural number followed
by a unit: Days (d), hours (h), minutes (m), seconds (s), and milliseconds
(ms). The default value is '0' which means that there is no timeout.
Tags:
affects_outputs

The maximum number of entries for a single named_set_of_files event; values
smaller than 2 are ignored and no event splitting is performed. This is
intended for limiting the maximum event size in the build event protocol,
although it does not directly control event size. The total event size is a
function of the structure of the set as well as the file and uri lengths, which
may in turn depend on the hash function.
Tags:
affects_outputs

Tune memory profile's computation of stable heap at end of build. Should be
two integers separated by a comma. First parameter is the number of GCs to
perform. Second parameter is the number of seconds to wait between GCs.
Tags:
bazel_monitoring

Selects additional config sections from the rc files; for every <
command>, it also pulls in the options from <command>:<config>
if such a section exists; if this section doesn't exist in any .rc file,
Bazel fails with an error. The config sections and flag combinations they are
equivalent to are located in the tools/*.bazelrc config files.

Number of concurrent actions shown in the alternative progress bar; each action
is shown on a separate line. The alternative progress bar always shows at least
one one, all numbers less than 1 are mapped to 1. This option has no effect
unless --experimental_ui is set.

Number of bytes to which the experimental UI will limit its output (non-
positive values indicate unlimited). Once the limit is approaching, the
experimental UI will try hard to limit in a meaningful way, but will ultimately
just drop all output.

If --html_details is present, the task diagram contains all tasks of the
profile and performance statistics on user-defined and built-in Skylark
functions. If --nohtml_details is present, an aggregated diagram is generated.
The default is to generate an aggregated diagram.
Tags:
affects_outputs

If --html_histograms and --html_details is present, the HTML output will
display histograms for Skylark functions clicked in the statistics table. This
will increase file size massively.
Tags:
affects_outputs

How to resolve aspect dependencies when the output format is one of {xml,proto,
record}. 'off' means no aspect dependencies are resolved, '
conservative' (the default) means all declared aspect dependencies are
added regardless of whether they are given the rule class of direct
dependencies, 'precise' means that only those aspects are added that
are possibly active given the rule class of the direct dependencies. Note that
precise mode requires loading other packages to evaluate a single target thus
making it slower than the other modes. Also note that even precise mode is not
completely precise: the decision whether to compute an aspect is decided in the
analysis phase, which is not run during 'bazel query'.
Tags:
build_file_semantics

Query: If disabled, dependencies on 'host configuration' targets will
not be included in the dependency graph over which the query operates. A '
host configuration' dependency edge, such as the one from any '
proto_library' rule to the Protocol Compiler, usually points to a tool
executed during the build (on the host machine) rather than a part of the same
'target' program.
Cquery: If disabled, filters out all configured targets which cross a host
transition from the top-level target that discovered this configured target.
That means if the top-level target is in the target configuration, only
configured targets also in the target configuration will be returned. If the
top-level target is in the host configuration, only host configured targets
will be returned.
Tags:
build_file_semantics

If enabled, implicit dependencies will be included in the dependency graph over
which the query operates. An implicit dependency is one that is not explicitly
specified in the BUILD file but added by bazel.
Tags:
build_file_semantics

If enabled, configurable attributes created by select() are flattened. For list
types the flattened representation is a list containing each value of the
select map exactly once. Scalar types are flattened to null.
Tags:
build_file_semantics

If true, the location of BUILD files in xml and proto outputs will be relative.
By default, the location output is an absolute path and will not be consistent
across machines. You can set this option to true to have a consistent result
across machines.
Tags:
terminal_output

A comma-separated set of target patterns (additive and subtractive). The query
may be performed in the universe defined by the transitive closure of the
specified targets. This option is used for the query and cquery commands.
For cquery, the input to this option is the targets all answers are built under
and so this option may affect configurations and transitions. If this option is
not specified, the top-level targets are assumed to be the targets parsed from
the query expression. Note: For cquery, not specifying this option may cause
the build to break if targets parsed from the query expression are not
buildable with top-level options.
Tags:
loading_and_analysis

Add or remove keys from an action's execution info based on action
mnemonic. Applies only to actions which support execution info. Many common
actions support execution info, e.g. Genrule, CppCompile, Javac, SkylarkAction,
TestRunner. When specifying multiple values, order matters because many regexes
may apply to the same mnemonic.
Syntax: "regex=[+-]key,[+-]key,...".
Examples:
'.*=+x,.*=-y,.*=+z' adds 'x' and 'z' to, and removes
'y' from, the execution info for all actions.
'Genrule=+requires-x' adds 'requires-x' to the execution info
for all Genrule actions.
'(?!Genrule).*=-requires-x' removes 'requires-x' from the
execution info for all non-Genrule actions.
Tags:
execution, affects_outputs, loading_and_analysis

Location of the binary that is used to generate coverage reports. This must
currently be a filegroup that contains a single file, the binary. Defaults to
'//tools/test:coverage_report_generator'.
Tags:
changes_inputs, affects_outputs, loading_and_analysis

Enable toolchain resolution for the given toolchain type, if the rules used
support that. This does not directly change the core Bazel machinery, but is a
signal to participating rule implementations that toolchain resolution should
be used.
Tags:
loading_and_analysis

Allows objc_* rules to depend on cc_library and causes any objc dependencies to
be built with --cpu set to "ios_<--ios_cpu>" for any values in
--ios_multi_cpu.
Tags:
loading_and_analysis, incompatible_change

The platforms that are available as execution platforms to run actions.
Platforms can be specified by exact target, or as a target pattern. These
platforms will be considered before those declared in the WORKSPACE file by
register_execution_platforms().
Tags:
execution

The toolchain rules to be considered during toolchain resolution. Toolchains
can be specified by exact target, or as a target pattern. These toolchains will
be considered before those declared in the WORKSPACE file by
register_toolchains().
Tags:
affects_outputs, changes_inputs, loading_and_analysis

By default, the --crosstool_top and --compiler options are also used for the
host configuration. If this flag is provided, Bazel uses the default libc and
compiler for the given crosstool_top.
Tags:
loading_and_analysis, changes_inputs, affects_outputs

Specifies which compilation modes use fission for C++ compilations and links.
May be any combination of {'fastbuild', 'dbg', 'opt'}
or the special values 'yes' to enable all modes and 'no' to
disable all modes.
Tags:
loading_and_analysis, action_command_lines, affects_outputs

Specifies the set of environment variables available to actions. Variables can
be either specified by name, in which case the value will be taken from the
invocation environment, or by the name=value pair which sets the value
independent of the invocation environment. This option can be used multiple
times; for options given for the same variable, the latest wins, options for
different variables accumulate.
Tags:
action_command_lines

Determines whether C++ deps of Android rules will be linked dynamically when a
cc_binary does not explicitly create a shared library. 'default' means
bazel will choose whether to link dynamically. 'fully' means all
libraries will be linked dynamically. 'off' means that all libraries
will be linked in mostly static mode.
Tags:
affects_outputs, loading_and_analysis

If specified, Bazel will instrument code (using offline instrumentation where
possible) and will collect coverage information during tests. Only targets
that match --instrumentation_filter will be affected. Usually this option
should not be specified directly - 'bazel coverage' command should be
used instead.
Tags:
affects_outputs

This flag is experimental and may go away at any time. If true, dynamically
linked binary targets will build and link their own srcs as a dynamic library
instead of directly linking it in.
Tags:
loading_and_analysis, affects_outputs, experimental

Use FDO profile information to optimize compilation. Specify the name of the
zip file containing the .gcda file tree, or an afdo file containing an auto
profile. This flag also accepts files specified as labels, for example
//foo/bar:file.afdo. Such labels must refer to input files; you may need to add
an exports_files directive to the corresponding package to make the file
visible to Bazel. It also accepts a raw or an indexed LLVM profile file. This
flag will be superseded by fdo_profile rule.
Tags:
affects_outputs

The given features will be enabled or disabled by default for all packages.
Specifying -<feature> will disable the feature globally. Negative
features always override positive ones. This flag is used to enable rolling out
default feature changes without a Bazel release.
Tags:
changes_inputs, affects_outputs

When coverage is enabled, only rules with names included by the specified regex-
based filter will be instrumented. Rules prefixed with '-' are excluded
instead. Note that only non-test rules are instrumented unless --
instrument_test_targets is enabled.
Tags:
affects_outputs

When on, use --whole-archive for cc_binary rules that have linkshared=1 and
either linkstatic=1 or '-static' in linkopts. This is for backwards
compatibility only. A better alternative is to use alwayslink=1 where required.
Tags:
action_command_lines, affects_outputs

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to gcc when compiling certain files.
This option can be passed multiple times. Syntax: regex_filter@option_1,
option_2,...,option_n. Where regex_filter stands for a list of include and
exclude regular expression patterns (Also see --instrumentation_filter).
option_1 to option_n stand for arbitrary command line options. If an option
contains a comma it has to be quoted with a backslash. Options can contain @.
Only the first @ is used to split the string. Example: --per_file_copt=//foo/.
*\.cc,-//foo/bar\.cc@-O0 adds the -O0 command line option to the gcc command
line of all cc files in //foo/ except bar.cc.
Tags:
action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to LTO backend (under --
features=thin_lto) when compiling certain backend objects. This option can be
passed multiple times. Syntax: regex_filter@option_1,option_2,...,option_n.
Where regex_filter stands for a list of include and exclude regular expression
patterns. option_1 to option_n stand for arbitrary command line options. If an
option contains a comma it has to be quoted with a backslash. Options can
contain @. Only the first @ is used to split the string. Example: --
per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 adds the -O0 command line
option to the LTO backend command line of all o files in //foo/ except bar.o.
Tags:
action_command_lines, affects_outputs

Use XbinaryFDO profile information to optimize compilation. Specify the name of
default cross binary profile. When the option is used together with --
fdo_instrument/--fdo_optimize/--fdo_profile, those options will always prevail
as if xbinary_fdo is never specified.
Tags:
affects_outputs

Flag to help transition from allowing to disallowing srcs-less android_library
rules with deps. The depot needs to be cleaned up to roll this out by default.
Tags:
eagerness_to_exit, loading_and_analysis

If this option is enabled, filesets crossing package boundaries are reported as
errors. It does not work when check_fileset_dependencies_recursively is
disabled.
Tags:
build_file_semantics, eagerness_to_exit

Certificate name to use for iOS signing. If not set will fall back to
provisioning profile. May be the certificate's keychain identity preference
or (substring) of the certificate's common name, as per codesign's man
page (SIGNING IDENTITIES).
Tags:
action_command_lines

Options that govern the behavior of the test environment or test runner:

If true, an analysis failure of a rule target results in the target's
propagation of an instance of AnalysisFailureInfo containing the error
description, instead of resulting in a build failure.
Tags:
loading_and_analysis, experimental

Sets the maximum number of transitive dependencies through a rule attribute
with a for_analysis_testing configuration transition. Exceeding this limit will
result in a rule error.
Tags:
loading_and_analysis

The device to simulate when running an iOS application in the simulator, e.g.
'iPhone 6'. You can get a list of devices by running 'xcrun simctl
list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The version of iOS to run on the simulator when running or testing. This is
ignored for ios_test rules if a target device is specified in the rule.
Tags:
test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once&gt multiple uses are accumulated

Specifies number of times to run each test. If any of those attempts fail for
any reason, the whole test would be considered failed. Normally the value
specified is just an integer. Example: --runs_per_test=3 will run all tests 3
times. Alternate syntax: regex_filter@runs_per_test. Where runs_per_test stands
for an integer value and regex_filter stands for a list of include and exclude
regular expression patterns (Also see --instrumentation_filter). Example: --
runs_per_test=//foo/.*,-//foo/bar/.*@3 runs all tests in //foo/ except those
under foo/bar three times. This option can be passed multiple times.

Specifies additional environment variables to be injected into the test runner
environment. Variables can be either specified by name, in which case its value
will be read from the Bazel client environment, or by the name=value pair. This
option can be used multiple times to specify several variables. Used only by
the 'bazel test' command.
Tags:
test_runner

Override the default test timeout values for test timeouts (in secs). If a
single positive integer value is specified it will override all categories. If
4 comma-separated integers are specified, they will override the timeouts for
short, moderate, long and eternal (in that order). In either form, a value of
-1 tells bazel to use its default timeouts for that category.

The device to simulate when running an tvOS application in the simulator, e.g.
'Apple TV 1080p'. You can get a list of devices by running 'xcrun
simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The device to simulate when running an watchOS application in the simulator, e.
g. 'Apple Watch - 38mm'. You can get a list of devices by running '
xcrun simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

How to resolve aspect dependencies when the output format is one of {xml,proto,
record}. 'off' means no aspect dependencies are resolved, '
conservative' (the default) means all declared aspect dependencies are
added regardless of whether they are given the rule class of direct
dependencies, 'precise' means that only those aspects are added that
are possibly active given the rule class of the direct dependencies. Note that
precise mode requires loading other packages to evaluate a single target thus
making it slower than the other modes. Also note that even precise mode is not
completely precise: the decision whether to compute an aspect is decided in the
analysis phase, which is not run during 'bazel query'.
Tags:
build_file_semantics

Query: If disabled, dependencies on 'host configuration' targets will
not be included in the dependency graph over which the query operates. A '
host configuration' dependency edge, such as the one from any '
proto_library' rule to the Protocol Compiler, usually points to a tool
executed during the build (on the host machine) rather than a part of the same
'target' program.
Cquery: If disabled, filters out all configured targets which cross a host
transition from the top-level target that discovered this configured target.
That means if the top-level target is in the target configuration, only
configured targets also in the target configuration will be returned. If the
top-level target is in the host configuration, only host configured targets
will be returned.
Tags:
build_file_semantics

If enabled, implicit dependencies will be included in the dependency graph over
which the query operates. An implicit dependency is one that is not explicitly
specified in the BUILD file but added by bazel.
Tags:
build_file_semantics

If enabled, configurable attributes created by select() are flattened. For list
types the flattened representation is a list containing each value of the
select map exactly once. Scalar types are flattened to null.
Tags:
build_file_semantics

If true, the location of BUILD files in xml and proto outputs will be relative.
By default, the location output is an absolute path and will not be consistent
across machines. You can set this option to true to have a consistent result
across machines.
Tags:
terminal_output

A comma-separated set of target patterns (additive and subtractive). The query
may be performed in the universe defined by the transitive closure of the
specified targets. This option is used for the query and cquery commands.
For cquery, the input to this option is the targets all answers are built under
and so this option may affect configurations and transitions. If this option is
not specified, the top-level targets are assumed to be the targets parsed from
the query expression. Note: For cquery, not specifying this option may cause
the build to break if targets parsed from the query expression are not
buildable with top-level options.
Tags:
loading_and_analysis

Build all the tools used during the build for a distinct configuration from
that used for the target program. When this is disabled, the same configuration
is used for host and target programs. This may cause undesirable rebuilds of
tools such as the protocol compiler (and then everything downstream) whenever a
minor change is made to the target configuration, such as setting the linker
options. When this is enabled (the default), a distinct configuration will be
used to build the tools, preventing undesired rebuilds. However, certain
libraries will then need to be compiled twice, once for each configuration,
which may cause some builds to be slower. As a rule of thumb, this option is
likely to benefit users that make frequent changes in configuration (e.g.
opt/dbg). Please read the user manual for the full explanation.
Tags:
loses_incremental_state, bazel_internal_configuration, loading_and_analysis

If enabled, the parse_headers feature verifies that a header module can be
built for the target in question instead of doing a separate compile of the
header.
Tags:
loading_and_analysis, changes_inputs

When enabled, test-related options will be cleared below the top level of the
build. When this flag is active, tests cannot be built as dependencies of non-
test rules, but changes to test-related options will not cause non-test rules
to be re-analyzed.
Tags:
loading_and_analysis, loses_incremental_state

If set to 'auto', Bazel reruns a test if and only if: (1) Bazel detects
changes in the test or its dependencies, (2) the test is marked as external,
(3) multiple test runs were requested with --runs_per_test, or(4) the test
previously failed. If set to 'yes', Bazel caches all test results
except for tests marked as external. If set to 'no', Bazel does not
cache any test results.

If true, Bazel uses an environment with a static value for PATH and does not
inherit LD_LIBRARY_PATH or TMPDIR. Use --action_env=ENV_VARIABLE if you want to
inherit specific environment variables from the client, but note that doing so
can prevent cross-user caching if a shared cache is used.
Tags:
loading_and_analysis, incompatible_change, triggered_by_all_incompatible_changes

Absolute path to the shell executable for Bazel to use. If this is unset, but
the BAZEL_SH environment variable is set on the first Bazel invocation (that
starts up a Bazel server), Bazel uses that. If neither is set, Bazel uses a
hard-coded default path depending on the operating system it runs on (Windows:
c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, all others:
/bin/bash). Note that using a shell that is not compatible with bash may lead
to build failures or runtime failures of the generated binaries.
Tags:
loading_and_analysis

Specifies additional options and arguments that should be passed to the test
executable. Can be used multiple times to specify several arguments. If
multiple tests are executed, each of them will receive identical arguments.
Used only by the 'bazel test' command.

Specify strategy for test sharding: 'explicit' to only use sharding if
the 'shard_count' BUILD attribute is present. 'disabled' to
never use test sharding. 'experimental_heuristic' to enable sharding on
remotely executed tests without an explicit 'shard_count' attribute
which link in a supported framework. Considered experimental.

Scale all timeouts in Starlark repository rules by this factor. In this way,
external repositories can be made working on machines that are slower than the
rule author expected, without changing the source code
Tags:
bazel_internal_configuration, experimental

Specifies the cache location of the downloaded values obtained during the
fetching of external repositories. An empty string as argument requests the
cache to be disabled.
Tags:
bazel_internal_configuration

Specify a Docker image name (e.g. "ubuntu:latest") that should be
used to execute a sandboxed action when using the docker strategy and the
action itself doesn't already have a container-image attribute in its
remote_execution_properties in the platform description. The value of this flag
is passed verbatim to 'docker run', so it supports the same syntax and
mechanisms as Docker itself.
Tags:
execution

If enabled, injects the uid and gid of the current user into the Docker image
before using it. This is required if your build / tests depend on the user
having a name and home directory inside the container. This is on by default,
but you can disable it in case the automatic image customization feature
doesn't work in your case or you know that you don't need it.
Tags:
execution

If this flag is set, and a test action does not generate a test.xml file, then
Bazel uses a separate action to generate a dummy test.xml file containing the
test log. Otherwise, Bazel generates the test.xml as part of the test action.
Tags:
execution

The number of concurrent jobs to run. 0 means build sequentially. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors). Values above 5000 are not
allowed, and values above 2500 may cause memory issues.
Tags:
host_machine_resource_optimizations, execution

Number of parallel threads to use for the loading/analysis phase. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors).
Tags:
bazel_internal_configuration

Execute the build; this is the usual behaviour. Specifying --nobuild causes the
build to stop before executing the build actions, returning zero iff the
package loading and analysis phases completed successfully; this mode is useful
for testing those phases.
Tags:
execution, affects_outputs

Specifies which output groups of the top-level targets to build. If omitted, a
default set of output groups are built. When specified the default set is
overridden. However you may use --output_groups=+<output_group> or --
output_groups=-<output_group> to instead modify the set of output groups.
Tags:
execution, affects_outputs

Options that let the user configure the intended output, affecting its value, as opposed to its existence:

Comma-separated list of aspects to be applied to top-level targets. All aspects
are applied to all top-level targets independently. Aspects are specified in
the form <bzl-file-label>%<aspect_name>, for example '//tools:
my_def.bzl%my_aspect', where 'my_aspect' is a top-level value from
from a file tools/my_def.bzl

The prefix that is prepended to any of the convenience symlinks that are
created after a build. If '/' is passed, then no symlinks are created
and no warning is emitted. If omitted, the default value is the name of the
build tool.
Tags:
affects_outputs

When discarding the analysis cache due to a change in the build options,
displays up to the given number of changed option names. If the number given is
-1, all changed options will be displayed.
Tags:
terminal_output

Show the results of the build. For each target, state whether or not it was
brought up-to-date, and if so, a list of output files that were built. The
printed files are convenient strings for copy+pasting to the shell, to execute
them.
This option requires an integer argument, which is the threshold number of
targets above which result information is not printed. Thus zero causes
suppression of the message and MAX_INT causes printing of the result to occur
always. The default is one.
Tags:
affects_outputs

Specifies a comma-separated list of tags. Each tag can be optionally preceded
with '-' to specify excluded tags. Only those targets will be built
that contain at least one included tag and do not contain any excluded tags.
This option does not affect the set of tests executed with the 'test'
command; those are be governed by the test filtering options, for example '
--test_tag_filters'

Don't run tests, just check if they are up-to-date. If all tests results
are up-to-date, the testing completes successfully. If any test needs to be
built or executed, an error is reported and the testing fails. This option
implies --check_up_to_date behavior.

Compile a single dependency of the argument files. This is useful for syntax
checking source files in IDEs, for example, by rebuilding a single target that
depends on the source file to detect errors as early as possible in the
edit/build/test cycle. This argument affects the way all non-flag arguments are
interpreted; instead of being targets to build they are source filenames. For
each source filename an arbitrary target that depends on it will be built.

A comma-separated list of names of packages which the build system will
consider non-existent, even if they are visible somewhere on the package path.
Use this option when deleting a subpackage 'x/y' of an existing package
'x'. For example, after deleting x/y/BUILD in your client, the build
system may complain if it encounters a label '//x:y/z' if that is still
provided by another package_path entry. Specifying --deleted_packages x/y
avoids this problem.

Expand test_suite targets into their constituent tests before analysis. When
this flag is turned on (the default), negative target patterns will apply to
the tests belonging to the test suite, otherwise they will not. Turning off
this flag is useful when top-level aspects are applied at command line: then
they can analyze test_suite targets.
Tags:
loading_and_analysis

Turn this off to disable checking the ctime of input files of an action before
uploading it to a remote cache. There may be cases where the Linux kernel
delays writing of files, which could cause false positives.

Estimate the actual memory available online. By default, Bazel assumes most
actions use a fixed amount of memory, and counts that against the total
available system memory, regardless of how much memory is actually available.
This option enables online estimation of how much memory is available at any
given time, and thus does not require accurate estimation of how much memory a
given action will take.

If specified, a path to a file to log gRPC call related details. This log
consists of a sequence of serialized com.google.devtools.build.lib.remote.
logging.RemoteExecutionLog.LogEntry protobufs with each message prefixed by a
varint denoting the size of the following serialized protobuf message, as
performed by the method LogEntry.writeDelimitedTo(OutputStream).

Lets the sandbox create its sandbox directories underneath this path. Specify a
path on tmpfs (like /run/shm) to possibly improve performance a lot when your
build / tests have many input files. Note: You need enough RAM and free space
on the tmpfs to hold output and intermediate files generated by running actions.

Enable dynamic execution by running actions locally and remotely in parallel.
Bazel spawns each action locally and remotely and picks the one that completes
first. If an action supports workers, the local action will be run in the
persistent worker mode. To enable dynamic execution for an individual action
mnemonic, use the `--internal_spawn_scheduler` and `--strategy=<mnemonic>
=dynamic` flags instead.
Expands to:--internal_spawn_scheduler--spawn_strategy=dynamic

--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once&gt multiple uses are accumulated

Each test will be retried up to the specified number of times in case of any
test failure. Tests that required more than one attempt to pass would be marked
as 'FLAKY' in the test summary. If this option is set, it should
specify an int N or the string 'default'. If it's an int, then all
tests will be run up to N times. If it is not specified or its value is '
default', then only a single test attempt will be made for regular tests
and three for tests marked explicitly as flaky by their rule (flaky=1
attribute).

Do not print a warning when sandboxed execution is not supported on this system.

--local_resources=<comma-separated available amount of RAM (in MB), CPU (in cores) and available I/O (1.0 being average workstation)&gt default: see description

Explicitly set amount of local resources available to Bazel. By default, Bazel
will query system configuration to estimate amount of RAM (in MB) and number of
CPU cores available for the locally executed build actions. It would also
assume default I/O capabilities of the local workstation (1.0). This options
allows to explicitly set all 3 values. Note, that if this option is used, Bazel
will ignore --ram_utilization_factor.

The max number of local test jobs to run concurrently. 0 means local resources
will limit the number of local test jobs to run concurrently instead. Setting
this greater than the value for --jobs is ineffectual.

A colon-separated list of where to look for packages. Elements beginning with
'%workspace%' are relative to the enclosing workspace. If omitted or
empty, the default is the output of 'bazel info default-package-path'.

Specify what percentage of the system's RAM Bazel should try to use for its
subprocesses. This option affects how many processes Bazel will try to run in
parallel. If you run several Bazel builds in parallel, using a lower value for
this option may avoid thrashing and thus improve overall throughput. Using a
value higher than the default is NOT recommended. Note that Bazel's
estimates are very coarse, so the actual RAM usage may be much higher or much
lower than specified. Note also that this option does not affect the amount of
memory that the Bazel server itself will use.

The max. number of concurrent network connections to the remote cache/executor.
By default Bazel limits the number of TCP connections to 100. Setting this flag
to 0 will make Bazel choose the number of connections automatically.
Tags:
host_machine_resource_optimizations

Specify how spawn actions are executed by default. 'standalone' means
run all of them locally without any kind of sandboxing. 'sandboxed'
means to run them in a sandboxed environment with limited privileges (details
depend on platform support).

Override which spawn strategy should be used to execute spawn actions that have
descriptions matching a certain regex_filter. See --per_file_copt for details
onregex_filter matching. The first regex_filter that matches the description is
used. This option overrides other flags for specifying strategy. Example: --
strategy_regexp=//foo.*\.cc,-//foo/bar=local means to run actions using local
strategy if their descriptions match //foo.*.cc but not //foo/bar. Example: --
strategy_regexp='Compiling.*/bar=local --
strategy_regexp=Compiling=sandboxed will run 'Compiling //foo/bar/baz'
with the 'local' strategy, but reversing the order would run it with
'sandboxed'.

Specifies a comma-separated list of test languages. Each language can be
optionally preceded with '-' to specify excluded languages. Only those
test targets will be found that are written in the specified languages. The
name used for each language should be the same as the language prefix in the
*_test rule, e.g. one of 'cc', 'java', 'py', etc. This
option affects --build_tests_only behavior and the test command.

Specifies desired output mode. Valid values are 'summary' to output
only test status summary, 'errors' to also print test logs for failed
tests, 'all' to print logs for all tests and 'streamed' to
output logs for all tests in real time (this will force tests to be executed
locally one at a time regardless of --test_strategy value).

Specifies a comma-separated list of test sizes. Each size can be optionally
preceded with '-' to specify excluded sizes. Only those test targets
will be found that contain at least one included size and do not contain any
excluded sizes. This option affects --build_tests_only behavior and the test
command.

Specifies the desired format ot the test summary. Valid values are '
short' to print information only about tests executed, 'terse', to
print information only about unsuccessful tests that were run, '
detailed' to print detailed information about failed test cases, and '
none' to omit the summary.

Specifies a comma-separated list of test tags. Each tag can be optionally
preceded with '-' to specify excluded tags. Only those test targets
will be found that contain at least one included tag and do not contain any
excluded tags. This option affects --build_tests_only behavior and the test
command.

Specifies a comma-separated list of test timeouts. Each timeout can be
optionally preceded with '-' to specify excluded timeouts. Only those
test targets will be found that contain at least one included timeout and do
not contain any excluded timeouts. This option affects --build_tests_only
behavior and the test command.

How many instances of a worker process (like the persistent Java compiler) may
be launched if you use the 'worker' strategy. May be specified as
[name=value] to give a different value per worker mnemonic.

If this flag is set, and a test action does not generate a test.xml file, then
Bazel uses a separate action to generate a dummy test.xml file containing the
test log. Otherwise, Bazel generates the test.xml as part of the test action.
Tags:
execution

The number of concurrent jobs to run. 0 means build sequentially. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors). Values above 5000 are not
allowed, and values above 2500 may cause memory issues.
Tags:
host_machine_resource_optimizations, execution

Number of parallel threads to use for the loading/analysis phase. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors).
Tags:
bazel_internal_configuration

Add or remove keys from an action's execution info based on action
mnemonic. Applies only to actions which support execution info. Many common
actions support execution info, e.g. Genrule, CppCompile, Javac, SkylarkAction,
TestRunner. When specifying multiple values, order matters because many regexes
may apply to the same mnemonic.
Syntax: "regex=[+-]key,[+-]key,...".
Examples:
'.*=+x,.*=-y,.*=+z' adds 'x' and 'z' to, and removes
'y' from, the execution info for all actions.
'Genrule=+requires-x' adds 'requires-x' to the execution info
for all Genrule actions.
'(?!Genrule).*=-requires-x' removes 'requires-x' from the
execution info for all non-Genrule actions.
Tags:
execution, affects_outputs, loading_and_analysis

Location of the binary that is used to generate coverage reports. This must
currently be a filegroup that contains a single file, the binary. Defaults to
'//tools/test:coverage_report_generator'.
Tags:
changes_inputs, affects_outputs, loading_and_analysis

Enable toolchain resolution for the given toolchain type, if the rules used
support that. This does not directly change the core Bazel machinery, but is a
signal to participating rule implementations that toolchain resolution should
be used.
Tags:
loading_and_analysis

Allows objc_* rules to depend on cc_library and causes any objc dependencies to
be built with --cpu set to "ios_<--ios_cpu>" for any values in
--ios_multi_cpu.
Tags:
loading_and_analysis, incompatible_change

The platforms that are available as execution platforms to run actions.
Platforms can be specified by exact target, or as a target pattern. These
platforms will be considered before those declared in the WORKSPACE file by
register_execution_platforms().
Tags:
execution

The toolchain rules to be considered during toolchain resolution. Toolchains
can be specified by exact target, or as a target pattern. These toolchains will
be considered before those declared in the WORKSPACE file by
register_toolchains().
Tags:
affects_outputs, changes_inputs, loading_and_analysis

By default, the --crosstool_top and --compiler options are also used for the
host configuration. If this flag is provided, Bazel uses the default libc and
compiler for the given crosstool_top.
Tags:
loading_and_analysis, changes_inputs, affects_outputs

Execute the build; this is the usual behaviour. Specifying --nobuild causes the
build to stop before executing the build actions, returning zero iff the
package loading and analysis phases completed successfully; this mode is useful
for testing those phases.
Tags:
execution, affects_outputs

Specifies which compilation modes use fission for C++ compilations and links.
May be any combination of {'fastbuild', 'dbg', 'opt'}
or the special values 'yes' to enable all modes and 'no' to
disable all modes.
Tags:
loading_and_analysis, action_command_lines, affects_outputs

Specifies which output groups of the top-level targets to build. If omitted, a
default set of output groups are built. When specified the default set is
overridden. However you may use --output_groups=+<output_group> or --
output_groups=-<output_group> to instead modify the set of output groups.
Tags:
execution, affects_outputs

Specifies the set of environment variables available to actions. Variables can
be either specified by name, in which case the value will be taken from the
invocation environment, or by the name=value pair which sets the value
independent of the invocation environment. This option can be used multiple
times; for options given for the same variable, the latest wins, options for
different variables accumulate.
Tags:
action_command_lines

Determines whether C++ deps of Android rules will be linked dynamically when a
cc_binary does not explicitly create a shared library. 'default' means
bazel will choose whether to link dynamically. 'fully' means all
libraries will be linked dynamically. 'off' means that all libraries
will be linked in mostly static mode.
Tags:
affects_outputs, loading_and_analysis

Comma-separated list of aspects to be applied to top-level targets. All aspects
are applied to all top-level targets independently. Aspects are specified in
the form <bzl-file-label>%<aspect_name>, for example '//tools:
my_def.bzl%my_aspect', where 'my_aspect' is a top-level value from
from a file tools/my_def.bzl

If specified, Bazel will instrument code (using offline instrumentation where
possible) and will collect coverage information during tests. Only targets
that match --instrumentation_filter will be affected. Usually this option
should not be specified directly - 'bazel coverage' command should be
used instead.
Tags:
affects_outputs

This flag is experimental and may go away at any time. If true, dynamically
linked binary targets will build and link their own srcs as a dynamic library
instead of directly linking it in.
Tags:
loading_and_analysis, affects_outputs, experimental

Use FDO profile information to optimize compilation. Specify the name of the
zip file containing the .gcda file tree, or an afdo file containing an auto
profile. This flag also accepts files specified as labels, for example
//foo/bar:file.afdo. Such labels must refer to input files; you may need to add
an exports_files directive to the corresponding package to make the file
visible to Bazel. It also accepts a raw or an indexed LLVM profile file. This
flag will be superseded by fdo_profile rule.
Tags:
affects_outputs

The given features will be enabled or disabled by default for all packages.
Specifying -<feature> will disable the feature globally. Negative
features always override positive ones. This flag is used to enable rolling out
default feature changes without a Bazel release.
Tags:
changes_inputs, affects_outputs

When coverage is enabled, only rules with names included by the specified regex-
based filter will be instrumented. Rules prefixed with '-' are excluded
instead. Note that only non-test rules are instrumented unless --
instrument_test_targets is enabled.
Tags:
affects_outputs

When on, use --whole-archive for cc_binary rules that have linkshared=1 and
either linkstatic=1 or '-static' in linkopts. This is for backwards
compatibility only. A better alternative is to use alwayslink=1 where required.
Tags:
action_command_lines, affects_outputs

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to gcc when compiling certain files.
This option can be passed multiple times. Syntax: regex_filter@option_1,
option_2,...,option_n. Where regex_filter stands for a list of include and
exclude regular expression patterns (Also see --instrumentation_filter).
option_1 to option_n stand for arbitrary command line options. If an option
contains a comma it has to be quoted with a backslash. Options can contain @.
Only the first @ is used to split the string. Example: --per_file_copt=//foo/.
*\.cc,-//foo/bar\.cc@-O0 adds the -O0 command line option to the gcc command
line of all cc files in //foo/ except bar.cc.
Tags:
action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to LTO backend (under --
features=thin_lto) when compiling certain backend objects. This option can be
passed multiple times. Syntax: regex_filter@option_1,option_2,...,option_n.
Where regex_filter stands for a list of include and exclude regular expression
patterns. option_1 to option_n stand for arbitrary command line options. If an
option contains a comma it has to be quoted with a backslash. Options can
contain @. Only the first @ is used to split the string. Example: --
per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 adds the -O0 command line
option to the LTO backend command line of all o files in //foo/ except bar.o.
Tags:
action_command_lines, affects_outputs

The prefix that is prepended to any of the convenience symlinks that are
created after a build. If '/' is passed, then no symlinks are created
and no warning is emitted. If omitted, the default value is the name of the
build tool.
Tags:
affects_outputs

Use XbinaryFDO profile information to optimize compilation. Specify the name of
default cross binary profile. When the option is used together with --
fdo_instrument/--fdo_optimize/--fdo_profile, those options will always prevail
as if xbinary_fdo is never specified.
Tags:
affects_outputs

Flag to help transition from allowing to disallowing srcs-less android_library
rules with deps. The depot needs to be cleaned up to roll this out by default.
Tags:
eagerness_to_exit, loading_and_analysis

If this option is enabled, filesets crossing package boundaries are reported as
errors. It does not work when check_fileset_dependencies_recursively is
disabled.
Tags:
build_file_semantics, eagerness_to_exit

Certificate name to use for iOS signing. If not set will fall back to
provisioning profile. May be the certificate's keychain identity preference
or (substring) of the certificate's common name, as per codesign's man
page (SIGNING IDENTITIES).
Tags:
action_command_lines

Options that govern the behavior of the test environment or test runner:

If true, an analysis failure of a rule target results in the target's
propagation of an instance of AnalysisFailureInfo containing the error
description, instead of resulting in a build failure.
Tags:
loading_and_analysis, experimental

Sets the maximum number of transitive dependencies through a rule attribute
with a for_analysis_testing configuration transition. Exceeding this limit will
result in a rule error.
Tags:
loading_and_analysis

The device to simulate when running an iOS application in the simulator, e.g.
'iPhone 6'. You can get a list of devices by running 'xcrun simctl
list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The version of iOS to run on the simulator when running or testing. This is
ignored for ios_test rules if a target device is specified in the rule.
Tags:
test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once&gt multiple uses are accumulated

Specifies number of times to run each test. If any of those attempts fail for
any reason, the whole test would be considered failed. Normally the value
specified is just an integer. Example: --runs_per_test=3 will run all tests 3
times. Alternate syntax: regex_filter@runs_per_test. Where runs_per_test stands
for an integer value and regex_filter stands for a list of include and exclude
regular expression patterns (Also see --instrumentation_filter). Example: --
runs_per_test=//foo/.*,-//foo/bar/.*@3 runs all tests in //foo/ except those
under foo/bar three times. This option can be passed multiple times.

Specifies additional environment variables to be injected into the test runner
environment. Variables can be either specified by name, in which case its value
will be read from the Bazel client environment, or by the name=value pair. This
option can be used multiple times to specify several variables. Used only by
the 'bazel test' command.
Tags:
test_runner

Override the default test timeout values for test timeouts (in secs). If a
single positive integer value is specified it will override all categories. If
4 comma-separated integers are specified, they will override the timeouts for
short, moderate, long and eternal (in that order). In either form, a value of
-1 tells bazel to use its default timeouts for that category.

The device to simulate when running an tvOS application in the simulator, e.g.
'Apple TV 1080p'. You can get a list of devices by running 'xcrun
simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The device to simulate when running an watchOS application in the simulator, e.
g. 'Apple Watch - 38mm'. You can get a list of devices by running '
xcrun simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

Build all the tools used during the build for a distinct configuration from
that used for the target program. When this is disabled, the same configuration
is used for host and target programs. This may cause undesirable rebuilds of
tools such as the protocol compiler (and then everything downstream) whenever a
minor change is made to the target configuration, such as setting the linker
options. When this is enabled (the default), a distinct configuration will be
used to build the tools, preventing undesired rebuilds. However, certain
libraries will then need to be compiled twice, once for each configuration,
which may cause some builds to be slower. As a rule of thumb, this option is
likely to benefit users that make frequent changes in configuration (e.g.
opt/dbg). Please read the user manual for the full explanation.
Tags:
loses_incremental_state, bazel_internal_configuration, loading_and_analysis

If enabled, the parse_headers feature verifies that a header module can be
built for the target in question instead of doing a separate compile of the
header.
Tags:
loading_and_analysis, changes_inputs

When enabled, test-related options will be cleared below the top level of the
build. When this flag is active, tests cannot be built as dependencies of non-
test rules, but changes to test-related options will not cause non-test rules
to be re-analyzed.
Tags:
loading_and_analysis, loses_incremental_state

When discarding the analysis cache due to a change in the build options,
displays up to the given number of changed option names. If the number given is
-1, all changed options will be displayed.
Tags:
terminal_output

Show the results of the build. For each target, state whether or not it was
brought up-to-date, and if so, a list of output files that were built. The
printed files are convenient strings for copy+pasting to the shell, to execute
them.
This option requires an integer argument, which is the threshold number of
targets above which result information is not printed. Thus zero causes
suppression of the message and MAX_INT causes printing of the result to occur
always. The default is one.
Tags:
affects_outputs

Specifies a comma-separated list of tags. Each tag can be optionally preceded
with '-' to specify excluded tags. Only those targets will be built
that contain at least one included tag and do not contain any excluded tags.
This option does not affect the set of tests executed with the 'test'
command; those are be governed by the test filtering options, for example '
--test_tag_filters'

If set to 'auto', Bazel reruns a test if and only if: (1) Bazel detects
changes in the test or its dependencies, (2) the test is marked as external,
(3) multiple test runs were requested with --runs_per_test, or(4) the test
previously failed. If set to 'yes', Bazel caches all test results
except for tests marked as external. If set to 'no', Bazel does not
cache any test results.

Don't run tests, just check if they are up-to-date. If all tests results
are up-to-date, the testing completes successfully. If any test needs to be
built or executed, an error is reported and the testing fails. This option
implies --check_up_to_date behavior.

Compile a single dependency of the argument files. This is useful for syntax
checking source files in IDEs, for example, by rebuilding a single target that
depends on the source file to detect errors as early as possible in the
edit/build/test cycle. This argument affects the way all non-flag arguments are
interpreted; instead of being targets to build they are source filenames. For
each source filename an arbitrary target that depends on it will be built.

A comma-separated list of names of packages which the build system will
consider non-existent, even if they are visible somewhere on the package path.
Use this option when deleting a subpackage 'x/y' of an existing package
'x'. For example, after deleting x/y/BUILD in your client, the build
system may complain if it encounters a label '//x:y/z' if that is still
provided by another package_path entry. Specifying --deleted_packages x/y
avoids this problem.

Expand test_suite targets into their constituent tests before analysis. When
this flag is turned on (the default), negative target patterns will apply to
the tests belonging to the test suite, otherwise they will not. Turning off
this flag is useful when top-level aspects are applied at command line: then
they can analyze test_suite targets.
Tags:
loading_and_analysis

Estimate the actual memory available online. By default, Bazel assumes most
actions use a fixed amount of memory, and counts that against the total
available system memory, regardless of how much memory is actually available.
This option enables online estimation of how much memory is available at any
given time, and thus does not require accurate estimation of how much memory a
given action will take.

Explicitly specify a dependency to JUnit or Hamcrest in a java_test instead of
accidentally obtaining from the TestRunner's deps. Only works for bazel
right now.

--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once&gt multiple uses are accumulated

Each test will be retried up to the specified number of times in case of any
test failure. Tests that required more than one attempt to pass would be marked
as 'FLAKY' in the test summary. If this option is set, it should
specify an int N or the string 'default'. If it's an int, then all
tests will be run up to N times. If it is not specified or its value is '
default', then only a single test attempt will be made for regular tests
and three for tests marked explicitly as flaky by their rule (flaky=1
attribute).

If true, Bazel uses an environment with a static value for PATH and does not
inherit LD_LIBRARY_PATH or TMPDIR. Use --action_env=ENV_VARIABLE if you want to
inherit specific environment variables from the client, but note that doing so
can prevent cross-user caching if a shared cache is used.
Tags:
loading_and_analysis, incompatible_change, triggered_by_all_incompatible_changes

Additional options to pass to the Java VM. These options will get added to the
VM startup options of each java_binary target.

--local_resources=<comma-separated available amount of RAM (in MB), CPU (in cores) and available I/O (1.0 being average workstation)&gt default: see description

Explicitly set amount of local resources available to Bazel. By default, Bazel
will query system configuration to estimate amount of RAM (in MB) and number of
CPU cores available for the locally executed build actions. It would also
assume default I/O capabilities of the local workstation (1.0). This options
allows to explicitly set all 3 values. Note, that if this option is used, Bazel
will ignore --ram_utilization_factor.

The max number of local test jobs to run concurrently. 0 means local resources
will limit the number of local test jobs to run concurrently instead. Setting
this greater than the value for --jobs is ineffectual.

A colon-separated list of where to look for packages. Elements beginning with
'%workspace%' are relative to the enclosing workspace. If omitted or
empty, the default is the output of 'bazel info default-package-path'.

Specify what percentage of the system's RAM Bazel should try to use for its
subprocesses. This option affects how many processes Bazel will try to run in
parallel. If you run several Bazel builds in parallel, using a lower value for
this option may avoid thrashing and thus improve overall throughput. Using a
value higher than the default is NOT recommended. Note that Bazel's
estimates are very coarse, so the actual RAM usage may be much higher or much
lower than specified. Note also that this option does not affect the amount of
memory that the Bazel server itself will use.

Absolute path to the shell executable for Bazel to use. If this is unset, but
the BAZEL_SH environment variable is set on the first Bazel invocation (that
starts up a Bazel server), Bazel uses that. If neither is set, Bazel uses a
hard-coded default path depending on the operating system it runs on (Windows:
c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, all others:
/bin/bash). Note that using a shell that is not compatible with bash may lead
to build failures or runtime failures of the generated binaries.
Tags:
loading_and_analysis

Specifies additional options and arguments that should be passed to the test
executable. Can be used multiple times to specify several arguments. If
multiple tests are executed, each of them will receive identical arguments.
Used only by the 'bazel test' command.

Specifies a comma-separated list of test languages. Each language can be
optionally preceded with '-' to specify excluded languages. Only those
test targets will be found that are written in the specified languages. The
name used for each language should be the same as the language prefix in the
*_test rule, e.g. one of 'cc', 'java', 'py', etc. This
option affects --build_tests_only behavior and the test command.

Specifies desired output mode. Valid values are 'summary' to output
only test status summary, 'errors' to also print test logs for failed
tests, 'all' to print logs for all tests and 'streamed' to
output logs for all tests in real time (this will force tests to be executed
locally one at a time regardless of --test_strategy value).

Specify strategy for test sharding: 'explicit' to only use sharding if
the 'shard_count' BUILD attribute is present. 'disabled' to
never use test sharding. 'experimental_heuristic' to enable sharding on
remotely executed tests without an explicit 'shard_count' attribute
which link in a supported framework. Considered experimental.

Specifies a comma-separated list of test sizes. Each size can be optionally
preceded with '-' to specify excluded sizes. Only those test targets
will be found that contain at least one included size and do not contain any
excluded sizes. This option affects --build_tests_only behavior and the test
command.

Specifies the desired format ot the test summary. Valid values are '
short' to print information only about tests executed, 'terse', to
print information only about unsuccessful tests that were run, '
detailed' to print detailed information about failed test cases, and '
none' to omit the summary.

Specifies a comma-separated list of test tags. Each tag can be optionally
preceded with '-' to specify excluded tags. Only those test targets
will be found that contain at least one included tag and do not contain any
excluded tags. This option affects --build_tests_only behavior and the test
command.

Specifies a comma-separated list of test timeouts. Each timeout can be
optionally preceded with '-' to specify excluded timeouts. Only those
test targets will be found that contain at least one included timeout and do
not contain any excluded timeouts. This option affects --build_tests_only
behavior and the test command.

Output the canonical policy, after expansion and filtering. To keep the output
clean, the canonicalized command arguments will NOT be shown when this option
is set to true. Note that the command specified by --for_command affects the
filtered policy, and if none is specified, the default command is '
build'.
Tags:
affects_outputs, terminal_output

If true, output cleaning is asynchronous. When this command completes, it will
be safe to execute new commands in the same client, even though the deletion
may continue in the background.
Tags:
host_machine_resource_optimizations

If true, clean removes the entire working tree for this bazel instance,
which includes all bazel-created temporary and build output files, and
stops the bazel server if it is running.
Tags:
host_machine_resource_optimizations

If specified, clean asynchronously removes the entire working tree for this %
{product} instance, which includes all bazel-created temporary and build
output files, and stops the bazel server if it is running. When this
command completes, it will be safe to execute new commands in the same client,
even though the deletion may continue in the background.
Expands to:--expunge--async

How to resolve aspect dependencies when the output format is one of {xml,proto,
record}. 'off' means no aspect dependencies are resolved, '
conservative' (the default) means all declared aspect dependencies are
added regardless of whether they are given the rule class of direct
dependencies, 'precise' means that only those aspects are added that
are possibly active given the rule class of the direct dependencies. Note that
precise mode requires loading other packages to evaluate a single target thus
making it slower than the other modes. Also note that even precise mode is not
completely precise: the decision whether to compute an aspect is decided in the
analysis phase, which is not run during 'bazel query'.
Tags:
build_file_semantics

Query: If disabled, dependencies on 'host configuration' targets will
not be included in the dependency graph over which the query operates. A '
host configuration' dependency edge, such as the one from any '
proto_library' rule to the Protocol Compiler, usually points to a tool
executed during the build (on the host machine) rather than a part of the same
'target' program.
Cquery: If disabled, filters out all configured targets which cross a host
transition from the top-level target that discovered this configured target.
That means if the top-level target is in the target configuration, only
configured targets also in the target configuration will be returned. If the
top-level target is in the host configuration, only host configured targets
will be returned.
Tags:
build_file_semantics

If enabled, implicit dependencies will be included in the dependency graph over
which the query operates. An implicit dependency is one that is not explicitly
specified in the BUILD file but added by bazel.
Tags:
build_file_semantics

The format in which the cquery results should be printed. Allowed values for
cquery are: label, textproto, transitions, proto. If you select '
transitions', you also have to specify the --transitions=(lite|full) option.
Tags:
terminal_output

If enabled, configurable attributes created by select() are flattened. For list
types the flattened representation is a list containing each value of the
select map exactly once. Scalar types are flattened to null.
Tags:
build_file_semantics

If true, the location of BUILD files in xml and proto outputs will be relative.
By default, the location output is an absolute path and will not be consistent
across machines. You can set this option to true to have a consistent result
across machines.
Tags:
terminal_output

A comma-separated set of target patterns (additive and subtractive). The query
may be performed in the universe defined by the transitive closure of the
specified targets. This option is used for the query and cquery commands.
For cquery, the input to this option is the targets all answers are built under
and so this option may affect configurations and transitions. If this option is
not specified, the top-level targets are assumed to be the targets parsed from
the query expression. Note: For cquery, not specifying this option may cause
the build to break if targets parsed from the query expression are not
buildable with top-level options.
Tags:
loading_and_analysis

Add or remove keys from an action's execution info based on action
mnemonic. Applies only to actions which support execution info. Many common
actions support execution info, e.g. Genrule, CppCompile, Javac, SkylarkAction,
TestRunner. When specifying multiple values, order matters because many regexes
may apply to the same mnemonic.
Syntax: "regex=[+-]key,[+-]key,...".
Examples:
'.*=+x,.*=-y,.*=+z' adds 'x' and 'z' to, and removes
'y' from, the execution info for all actions.
'Genrule=+requires-x' adds 'requires-x' to the execution info
for all Genrule actions.
'(?!Genrule).*=-requires-x' removes 'requires-x' from the
execution info for all non-Genrule actions.
Tags:
execution, affects_outputs, loading_and_analysis

Location of the binary that is used to generate coverage reports. This must
currently be a filegroup that contains a single file, the binary. Defaults to
'//tools/test:coverage_report_generator'.
Tags:
changes_inputs, affects_outputs, loading_and_analysis

Enable toolchain resolution for the given toolchain type, if the rules used
support that. This does not directly change the core Bazel machinery, but is a
signal to participating rule implementations that toolchain resolution should
be used.
Tags:
loading_and_analysis

Allows objc_* rules to depend on cc_library and causes any objc dependencies to
be built with --cpu set to "ios_<--ios_cpu>" for any values in
--ios_multi_cpu.
Tags:
loading_and_analysis, incompatible_change

The platforms that are available as execution platforms to run actions.
Platforms can be specified by exact target, or as a target pattern. These
platforms will be considered before those declared in the WORKSPACE file by
register_execution_platforms().
Tags:
execution

The toolchain rules to be considered during toolchain resolution. Toolchains
can be specified by exact target, or as a target pattern. These toolchains will
be considered before those declared in the WORKSPACE file by
register_toolchains().
Tags:
affects_outputs, changes_inputs, loading_and_analysis

By default, the --crosstool_top and --compiler options are also used for the
host configuration. If this flag is provided, Bazel uses the default libc and
compiler for the given crosstool_top.
Tags:
loading_and_analysis, changes_inputs, affects_outputs

Specifies which compilation modes use fission for C++ compilations and links.
May be any combination of {'fastbuild', 'dbg', 'opt'}
or the special values 'yes' to enable all modes and 'no' to
disable all modes.
Tags:
loading_and_analysis, action_command_lines, affects_outputs

Specifies the set of environment variables available to actions. Variables can
be either specified by name, in which case the value will be taken from the
invocation environment, or by the name=value pair which sets the value
independent of the invocation environment. This option can be used multiple
times; for options given for the same variable, the latest wins, options for
different variables accumulate.
Tags:
action_command_lines

Determines whether C++ deps of Android rules will be linked dynamically when a
cc_binary does not explicitly create a shared library. 'default' means
bazel will choose whether to link dynamically. 'fully' means all
libraries will be linked dynamically. 'off' means that all libraries
will be linked in mostly static mode.
Tags:
affects_outputs, loading_and_analysis

If specified, Bazel will instrument code (using offline instrumentation where
possible) and will collect coverage information during tests. Only targets
that match --instrumentation_filter will be affected. Usually this option
should not be specified directly - 'bazel coverage' command should be
used instead.
Tags:
affects_outputs

This flag is experimental and may go away at any time. If true, dynamically
linked binary targets will build and link their own srcs as a dynamic library
instead of directly linking it in.
Tags:
loading_and_analysis, affects_outputs, experimental

Use FDO profile information to optimize compilation. Specify the name of the
zip file containing the .gcda file tree, or an afdo file containing an auto
profile. This flag also accepts files specified as labels, for example
//foo/bar:file.afdo. Such labels must refer to input files; you may need to add
an exports_files directive to the corresponding package to make the file
visible to Bazel. It also accepts a raw or an indexed LLVM profile file. This
flag will be superseded by fdo_profile rule.
Tags:
affects_outputs

The given features will be enabled or disabled by default for all packages.
Specifying -<feature> will disable the feature globally. Negative
features always override positive ones. This flag is used to enable rolling out
default feature changes without a Bazel release.
Tags:
changes_inputs, affects_outputs

When coverage is enabled, only rules with names included by the specified regex-
based filter will be instrumented. Rules prefixed with '-' are excluded
instead. Note that only non-test rules are instrumented unless --
instrument_test_targets is enabled.
Tags:
affects_outputs

When on, use --whole-archive for cc_binary rules that have linkshared=1 and
either linkstatic=1 or '-static' in linkopts. This is for backwards
compatibility only. A better alternative is to use alwayslink=1 where required.
Tags:
action_command_lines, affects_outputs

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to gcc when compiling certain files.
This option can be passed multiple times. Syntax: regex_filter@option_1,
option_2,...,option_n. Where regex_filter stands for a list of include and
exclude regular expression patterns (Also see --instrumentation_filter).
option_1 to option_n stand for arbitrary command line options. If an option
contains a comma it has to be quoted with a backslash. Options can contain @.
Only the first @ is used to split the string. Example: --per_file_copt=//foo/.
*\.cc,-//foo/bar\.cc@-O0 adds the -O0 command line option to the gcc command
line of all cc files in //foo/ except bar.cc.
Tags:
action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options&gt multiple uses are accumulated

Additional options to selectively pass to LTO backend (under --
features=thin_lto) when compiling certain backend objects. This option can be
passed multiple times. Syntax: regex_filter@option_1,option_2,...,option_n.
Where regex_filter stands for a list of include and exclude regular expression
patterns. option_1 to option_n stand for arbitrary command line options. If an
option contains a comma it has to be quoted with a backslash. Options can
contain @. Only the first @ is used to split the string. Example: --
per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 adds the -O0 command line
option to the LTO backend command line of all o files in //foo/ except bar.o.
Tags:
action_command_lines, affects_outputs

Use XbinaryFDO profile information to optimize compilation. Specify the name of
default cross binary profile. When the option is used together with --
fdo_instrument/--fdo_optimize/--fdo_profile, those options will always prevail
as if xbinary_fdo is never specified.
Tags:
affects_outputs

Flag to help transition from allowing to disallowing srcs-less android_library
rules with deps. The depot needs to be cleaned up to roll this out by default.
Tags:
eagerness_to_exit, loading_and_analysis

If this option is enabled, filesets crossing package boundaries are reported as
errors. It does not work when check_fileset_dependencies_recursively is
disabled.
Tags:
build_file_semantics, eagerness_to_exit

Certificate name to use for iOS signing. If not set will fall back to
provisioning profile. May be the certificate's keychain identity preference
or (substring) of the certificate's common name, as per codesign's man
page (SIGNING IDENTITIES).
Tags:
action_command_lines

Options that govern the behavior of the test environment or test runner:

If true, an analysis failure of a rule target results in the target's
propagation of an instance of AnalysisFailureInfo containing the error
description, instead of resulting in a build failure.
Tags:
loading_and_analysis, experimental

Sets the maximum number of transitive dependencies through a rule attribute
with a for_analysis_testing configuration transition. Exceeding this limit will
result in a rule error.
Tags:
loading_and_analysis

The device to simulate when running an iOS application in the simulator, e.g.
'iPhone 6'. You can get a list of devices by running 'xcrun simctl
list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The version of iOS to run on the simulator when running or testing. This is
ignored for ios_test rules if a target device is specified in the rule.
Tags:
test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once&gt multiple uses are accumulated

Specifies number of times to run each test. If any of those attempts fail for
any reason, the whole test would be considered failed. Normally the value
specified is just an integer. Example: --runs_per_test=3 will run all tests 3
times. Alternate syntax: regex_filter@runs_per_test. Where runs_per_test stands
for an integer value and regex_filter stands for a list of include and exclude
regular expression patterns (Also see --instrumentation_filter). Example: --
runs_per_test=//foo/.*,-//foo/bar/.*@3 runs all tests in //foo/ except those
under foo/bar three times. This option can be passed multiple times.

Specifies additional environment variables to be injected into the test runner
environment. Variables can be either specified by name, in which case its value
will be read from the Bazel client environment, or by the name=value pair. This
option can be used multiple times to specify several variables. Used only by
the 'bazel test' command.
Tags:
test_runner

Override the default test timeout values for test timeouts (in secs). If a
single positive integer value is specified it will override all categories. If
4 comma-separated integers are specified, they will override the timeouts for
short, moderate, long and eternal (in that order). In either form, a value of
-1 tells bazel to use its default timeouts for that category.

The device to simulate when running an tvOS application in the simulator, e.g.
'Apple TV 1080p'. You can get a list of devices by running 'xcrun
simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

The device to simulate when running an watchOS application in the simulator, e.
g. 'Apple Watch - 38mm'. You can get a list of devices by running '
xcrun simctl list devicetypes' on the machine the simulator will be run on.
Tags:
test_runner

How to resolve aspect dependencies when the output format is one of {xml,proto,
record}. 'off' means no aspect dependencies are resolved, '
conservative' (the default) means all declared aspect dependencies are
added regardless of whether they are given the rule class of direct
dependencies, 'precise' means that only those aspects are added that
are possibly active given the rule class of the direct dependencies. Note that
precise mode requires loading other packages to evaluate a single target thus
making it slower than the other modes. Also note that even precise mode is not
completely precise: the decision whether to compute an aspect is decided in the
analysis phase, which is not run during 'bazel query'.
Tags:
build_file_semantics

Query: If disabled, dependencies on 'host configuration' targets will
not be included in the dependency graph over which the query operates. A '
host configuration' dependency edge, such as the one from any '
proto_library' rule to the Protocol Compiler, usually points to a tool
executed during the build (on the host machine) rather than a part of the same
'target' program.
Cquery: If disabled, filters out all configured targets which cross a host
transition from the top-level target that discovered this configured target.
That means if the top-level target is in the target configuration, only
configured targets also in the target configuration will be returned. If the
top-level target is in the host configuration, only host configured targets
will be returned.
Tags:
build_file_semantics

If enabled, implicit dependencies will be included in the dependency graph over
which the query operates. An implicit dependency is one that is not explicitly
specified in the BUILD file but added by bazel.
Tags:
build_file_semantics

The format in which the cquery results should be printed. Allowed values for
cquery are: label, textproto, transitions, proto. If you select '
transitions', you also have to specify the --transitions=(lite|full) option.
Tags:
terminal_output

If enabled, configurable attributes created by select() are flattened. For list
types the flattened representation is a list containing each value of the
select map exactly once. Scalar types are flattened to null.
Tags:
build_file_semantics

If true, the location of BUILD files in xml and proto outputs will be relative.
By default, the location output is an absolute path and will not be consistent
across machines. You can set this option to true to have a consistent result
across machines.
Tags:
terminal_output

A comma-separated set of target patterns (additive and subtractive). The query
may be performed in the universe defined by the transitive closure of the
specified targets. This option is used for the query and cquery commands.
For cquery, the input to this option is the targets all answers are built under
and so this option may affect configurations and transitions. If this option is
not specified, the top-level targets are assumed to be the targets parsed from
the query expression. Note: For cquery, not specifying this option may cause
the build to break if targets parsed from the query expression are not
buildable with top-level options.
Tags:
loading_and_analysis

Build all the tools used during the build for a distinct configuration from
that used for the target program. When this is disabled, the same configuration
is used for host and target programs. This may cause undesirable rebuilds of
tools such as the protocol compiler (and then everything downstream) whenever a
minor change is made to the target configuration, such as setting the linker
options. When this is enabled (the default), a distinct configuration will be
used to build the tools, preventing undesired rebuilds. However, certain
libraries will then need to be compiled twice, once for each configuration,
which may cause some builds to be slower. As a rule of thumb, this option is
likely to benefit users that make frequent changes in configuration (e.g.
opt/dbg). Please read the user manual for the full explanation.
Tags:
loses_incremental_state, bazel_internal_configuration, loading_and_analysis

If enabled, the parse_headers feature verifies that a header module can be
built for the target in question instead of doing a separate compile of the
header.
Tags:
loading_and_analysis, changes_inputs

When enabled, test-related options will be cleared below the top level of the
build. When this flag is active, tests cannot be built as dependencies of non-
test rules, but changes to test-related options will not cause non-test rules
to be re-analyzed.
Tags:
loading_and_analysis, loses_incremental_state

If set to 'auto', Bazel reruns a test if and only if: (1) Bazel detects
changes in the test or its dependencies, (2) the test is marked as external,
(3) multiple test runs were requested with --runs_per_test, or(4) the test
previously failed. If set to 'yes', Bazel caches all test results
except for tests marked as external. If set to 'no', Bazel does not
cache any test results.

If true, Bazel uses an environment with a static value for PATH and does not
inherit LD_LIBRARY_PATH or TMPDIR. Use --action_env=ENV_VARIABLE if you want to
inherit specific environment variables from the client, but note that doing so
can prevent cross-user caching if a shared cache is used.
Tags:
loading_and_analysis, incompatible_change, triggered_by_all_incompatible_changes

Absolute path to the shell executable for Bazel to use. If this is unset, but
the BAZEL_SH environment variable is set on the first Bazel invocation (that
starts up a Bazel server), Bazel uses that. If neither is set, Bazel uses a
hard-coded default path depending on the operating system it runs on (Windows:
c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, all others:
/bin/bash). Note that using a shell that is not compatible with bash may lead
to build failures or runtime failures of the generated binaries.
Tags:
loading_and_analysis

Specifies additional options and arguments that should be passed to the test
executable. Can be used multiple times to specify several arguments. If
multiple tests are executed, each of them will receive identical arguments.
Used only by the 'bazel test' command.

Specify strategy for test sharding: 'explicit' to only use sharding if
the 'shard_count' BUILD attribute is present. 'disabled' to
never use test sharding. 'experimental_heuristic' to enable sharding on
remotely executed tests without an explicit 'shard_count' attribute
which link in a supported framework. Considered experimental.

Scale all timeouts in Starlark repository rules by this factor. In this way,
external repositories can be made working on machines that are slower than the
rule author expected, without changing the source code
Tags:
bazel_internal_configuration, experimental

Specifies the cache location of the downloaded values obtained during the
fetching of external repositories. An empty string as argument requests the
cache to be disabled.
Tags:
bazel_internal_configuration

Number of parallel threads to use for the loading/analysis phase. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors).
Tags:
bazel_internal_configuration

A comma-separated list of names of packages which the build system will
consider non-existent, even if they are visible somewhere on the package path.
Use this option when deleting a subpackage 'x/y' of an existing package
'x'. For example, after deleting x/y/BUILD in your client, the build
system may complain if it encounters a label '//x:y/z' if that is still
provided by another package_path entry. Specifying --deleted_packages x/y
avoids this problem.

--override_repository=<an equals-separated mapping of repository name to path&gt multiple uses are accumulated

A colon-separated list of where to look for packages. Elements beginning with
'%workspace%' are relative to the enclosing workspace. If omitted or
empty, the default is the output of 'bazel info default-package-path'.

adb binary to use for the 'mobile-install' command. If unspecified, the
one in the Android SDK specified by the --android_sdk command line option (or
the default SDK if --android_sdk is not specified) is used.
Tags:
changes_inputs

Whether to do an incremental install. If true, try to avoid unnecessary
additional work by reading the state of the device the code is to be installed
on and using that information to avoid unnecessary work. If false (the
default), always do a full install.
Tags:
loading_and_analysis

Scale all timeouts in Starlark repository rules by this factor. In this way,
external repositories can be made working on machines that are slower than the
rule author expected, without changing the source code
Tags:
bazel_internal_configuration, experimental

Specifies the cache location of the downloaded values obtained during the
fetching of external repositories. An empty string as argument requests the
cache to be disabled.
Tags:
bazel_internal_configuration

Number of parallel threads to use for the loading/analysis phase. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors).
Tags:
bazel_internal_configuration

How to resolve aspect dependencies when the output format is one of {xml,proto,
record}. 'off' means no aspect dependencies are resolved, '
conservative' (the default) means all declared aspect dependencies are
added regardless of whether they are given the rule class of direct
dependencies, 'precise' means that only those aspects are added that
are possibly active given the rule class of the direct dependencies. Note that
precise mode requires loading other packages to evaluate a single target thus
making it slower than the other modes. Also note that even precise mode is not
completely precise: the decision whether to compute an aspect is decided in the
analysis phase, which is not run during 'bazel query'.
Tags:
build_file_semantics

If true, then the graph will be emitted 'factored', i.e. topologically-
equivalent nodes will be merged together and their labels concatenated. This
option is only applicable to --output=graph.
Tags:
terminal_output

Query: If disabled, dependencies on 'host configuration' targets will
not be included in the dependency graph over which the query operates. A '
host configuration' dependency edge, such as the one from any '
proto_library' rule to the Protocol Compiler, usually points to a tool
executed during the build (on the host machine) rather than a part of the same
'target' program.
Cquery: If disabled, filters out all configured targets which cross a host
transition from the top-level target that discovered this configured target.
That means if the top-level target is in the target configuration, only
configured targets also in the target configuration will be returned. If the
top-level target is in the host configuration, only host configured targets
will be returned.
Tags:
build_file_semantics

If enabled, implicit dependencies will be included in the dependency graph over
which the query operates. An implicit dependency is one that is not explicitly
specified in the BUILD file but added by bazel.
Tags:
build_file_semantics

Output the results unordered (no), dependency-ordered (deps), or fully ordered
(full). The default is 'auto', meaning that results are output either
dependency-ordered or fully ordered, depending on the output formatter
(dependency-ordered for proto, minrank, maxrank, and graph, fully ordered for
all others). When output is fully ordered, nodes that would otherwise be
unordered by the output formatter are alphabetized before output.
Tags:
terminal_output

Output the results in dependency-ordered (default) or unordered fashion. The
unordered output is faster but only supported when --output is not minrank,
maxrank, or graph.
Expands to:--order_output=auto

If enabled, configurable attributes created by select() are flattened. For list
types the flattened representation is a list containing each value of the
select map exactly once. Scalar types are flattened to null.
Tags:
build_file_semantics

If true, the location of BUILD files in xml and proto outputs will be relative.
By default, the location output is an absolute path and will not be consistent
across machines. You can set this option to true to have a consistent result
across machines.
Tags:
terminal_output

A comma-separated set of target patterns (additive and subtractive). The query
may be performed in the universe defined by the transitive closure of the
specified targets. This option is used for the query and cquery commands.
For cquery, the input to this option is the targets all answers are built under
and so this option may affect configurations and transitions. If this option is
not specified, the top-level targets are assumed to be the targets parsed from
the query expression. Note: For cquery, not specifying this option may cause
the build to break if targets parsed from the query expression are not
buildable with top-level options.
Tags:
loading_and_analysis

A comma-separated list of names of packages which the build system will
consider non-existent, even if they are visible somewhere on the package path.
Use this option when deleting a subpackage 'x/y' of an existing package
'x'. For example, after deleting x/y/BUILD in your client, the build
system may complain if it encounters a label '//x:y/z' if that is still
provided by another package_path entry. Specifying --deleted_packages x/y
avoids this problem.

--override_repository=<an equals-separated mapping of repository name to path&gt multiple uses are accumulated

A colon-separated list of where to look for packages. Elements beginning with
'%workspace%' are relative to the enclosing workspace. If omitted or
empty, the default is the output of 'bazel info default-package-path'.

If set, write a shell script to the given file which invokes the target. If
this option is set, the target is not run from bazel. Use 'bazel
run --script_path=foo //foo && ./foo' to invoke target '
//foo' This differs from 'bazel run //foo' in that the %
{product} lock is released and the executable is connected to the terminal'
s stdin.
Tags:
affects_outputs, execution

Scale all timeouts in Starlark repository rules by this factor. In this way,
external repositories can be made working on machines that are slower than the
rule author expected, without changing the source code
Tags:
bazel_internal_configuration, experimental

Specifies the cache location of the downloaded values obtained during the
fetching of external repositories. An empty string as argument requests the
cache to be disabled.
Tags:
bazel_internal_configuration

Number of parallel threads to use for the loading/analysis phase. "
auto" means to use a reasonable value derived from the machine's
hardware profile (e.g. the number of processors).
Tags:
bazel_internal_configuration

A comma-separated list of names of packages which the build system will
consider non-existent, even if they are visible somewhere on the package path.
Use this option when deleting a subpackage 'x/y' of an existing package
'x'. For example, after deleting x/y/BUILD in your client, the build
system may complain if it encounters a label '//x:y/z' if that is still
provided by another package_path entry. Specifying --deleted_packages x/y
avoids this problem.

--override_repository=<an equals-separated mapping of repository name to path&gt multiple uses are accumulated

A colon-separated list of where to look for packages. Elements beginning with
'%workspace%' are relative to the enclosing workspace. If omitted or
empty, the default is the output of 'bazel info default-package-path'.

If true, when printing the path to a test log, use relative path that makes use
of the 'testlogs' convenience symlink. N.B. - A subsequent '
build'/'test'/etc invocation with a different configuration can
cause the target of this symlink to change, making the path printed previously
no longer useful.
Tags:
affects_outputs

When set we collect and publish used_heap_size_post_build from
build_event_stream.proto. This forces a full GC and is off by default.

Option Effect Tags

unknown

This option has unknown, or undocumented, effect.

no_op

This option has literally no effect.

loses_incremental_state

Changing the value of this option can cause significant loss of incremental state, which slows builds. State could be lost due to a server restart or to invalidation of a large part of the dependency graph.

changes_inputs

This option actively changes the inputs that bazel considers for the build, such as filesystem restrictions, repository versions, or other options.

affects_outputs

This option affects bazel's outputs. This tag is intentionally broad, can include transitive affects, and does not specify the type of output it affects.

build_file_semantics

This option affects the semantics of BUILD or .bzl files.

bazel_internal_configuration

This option affects settings of bazel-internal machinery. This tag does not, on its own, mean that build artifacts are affected.

loading_and_analysis

This option affects the loading and analysis of dependencies, and the building of the dependency graph.

execution

This option affects the execution phase, such as sandboxing or remote execution related options.

host_machine_resource_optimizations

This option triggers an optimization that may be machine specific and is not guaranteed to work on all machines. The optimization could include a tradeoff with other aspects of performance, such as memory or cpu cost.

eagerness_to_exit

This option changes how eagerly bazel will exit from a failure, where a choice between continuing despite the failure and ending the invocation exists.

bazel_monitoring

This option is used to monitor bazel's behavior and performance.

terminal_output

This option affects bazel's terminal output.

action_command_lines

This option changes the command line arguments of one or more build actions.

test_runner

This option changes the testrunner environment of the build.

Option Metadata Tags

experimental

This option triggers an experimental feature with no guarantees of functionality.

incompatible_change

This option triggers a breaking change. Use this option to test your migration readiness or get early access to the new feature

deprecated

This option is deprecated. It might be that the feature it affects is deprecated, or that another method of supplying the information is preferred.

triggered_by_all_incompatible_changes

This option is triggered by the expansion option --all_incompatible_changes.