The following sections describe the options available during a build. When --long is used on a help command, the on-line help messages provide summary information about the meaning, type and default value for each option.

Most options can only be specified once. When specified multiple times, the last instance wins. Options that can be specified multiple times are identified in the on-line help with the text 'may be used multiple times'.
可以使用 bazel --long打印出所有的选项,大多数选项只可以指定一次,当指定多次时,最后一次的指定才算数。可以指定多次的选项可以在帮助中看到:即说明该选项可以被指定多次。

See also the --show_package_location option.


This option specifies the set of directories that are searched to find the BUILD file for a given package.


This option specifies a comma-separated list of packages which Bazel should consider deleted, and not attempt to load from any directory on the package path. This can be used to simulate the deletion of packages without actually deleting them.


Error checking options

These options control Bazel's error-checking and/or warnings.

--check_constraint constraint
This option takes an argument that specifies which constraint should be checked.

Bazel performs special checks on each rule that is annotated with the given constraint.

The supported constraints and their checks are as follows:

  • public: Verify that all java_libraries marked with constraints = ['public'] only depend on java_libraries that are marked as constraints = ['public'] too. If bazel finds a dependency that does not conform to this rule, bazel will issue an error.


If this option is set to false, visibility checks are demoted to warnings. The default value of this option is true, so that by default, visibility checking is done.


The experimental_action_listener option instructs Bazel to use details from the action_listener rule specified by label to insert extra_actions into the build graph.


The experimental_extra_action_filter option instructs Bazel to filter the set of targets to schedule extra_actions for.

This flag is only applicable in combination with the --experimental_action_listener flag.

By default all extra_actions in the transitive closure of the requested targets-to-build get scheduled for execution. --experimental_extra_action_filter will restrict scheduling to extra_actions of which the owner's label matches the specified regular expression.

The following example will limit scheduling of extra_actions to only apply to actions of which the owner's label contains '/bar/':

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

--output_filter regex
The --output_filter option will only show build and compilation warnings for targets that match the regular expression. If a target does not match the given regular expression and its execution succeeds, its standard output and standard error are thrown away. This option is intended to be used to help focus efforts on fixing warnings in packages under development. Here are some typical values for this option:
--output_filter= Show all output.
--output_filter='^//(first/project|second/project):' Show the output for the specified packages.
--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$' Don't show output for the specified packages.
--output_filter=DONT_MATCH_ANYTHING Don't show output.


When this option is enabled, visible analysis warnings (as specified by the output filter) are treated as errors, effectively preventing the build phase from starting. This feature can be used to enable strict builds that do not allow new warnings to creep into a project.


Flags options

These options control which options Bazel will pass to other tools.

--copt gcc-option
This option takes an argument which is to be passed to gcc. The argument will be passed to gcc whenever gcc is invoked for preprocessing, compiling, and/or assembling C, C++, or assembler code. It will not be passed when linking.
This option can be used multiple times. For example:
  % bazel build --copt="-g0" --copt="-fpic" //foo

will compile the foo library without debug tables, generating position-independent code.

Note that changing --copt settings will force a recompilation of all affected object files. Also note that copts values listed in specific cc_library or cc_binary build rules will be placed on the gcc command line after these options.

Warning: C++-specific options (such as -fno-implicit-templates) should be specified in --cxxopt, not in --copt. Likewise, C-specific options (such as -Wstrict-prototypes) should be specified in --conlyopt, not in copt. Similarly, gcc options that only have an effect at link time (such as -l) should be specified in --linkopt, not in --copt.

--host_copt gcc-option
This option takes an argument which is to be passed to gcc for source files that are compiled in the host configuration. This is analogous to the --copt option, but applies only to the host configuration.

--conlyopt gcc-option

This option takes an argument which is to be passed to gcc when compiling C source files.

This is similar to --copt, but only applies to C compilation, not to C++ compilation or linking. So you can pass C-specific options (such as -Wno-pointer-sign) using --conlyopt.

Note that copts parameters listed in specific cc_library or cc_binary build rules will be placed on the gcc command line after these options.

--cxxopt gcc-option

This option takes an argument which is to be passed to gcc when compiling C++ source files.

This is similar to --copt, but only applies to C++ compilation, not to C compilation or linking. So you can pass C++-specific options (such as -fpermissive or -fno-implicit-templates) using --cxxopt. For example:

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

Note that copts parameters listed in specific cc_library or cc_binary build rules will be placed on the gcc command line after these options.

--linkopt linker-option
This option takes an argument which is to be passed to gcc when linking.

This is similar to --copt, but only applies to linking, not to compilation. So you can pass gcc options that only make sense at link time (such as -lssp or -Wl,--wrap,abort) using --linkopt. For example:

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

Build rules can also specify link options in their attributes. This option's settings always take precedence. Also seecc_library.linkopts.

--strip (always|never|sometimes)

This option determines whether Bazel will strip debugging information from all binaries and shared libraries, by invoking the linker with the -Wl,--strip-debug option. --strip=always means always strip debugging information. --strip=never means never strip debugging information. The default value of --strip=sometimes means strip iff the --compilation_mode is fastbuild.
  % bazel build --strip=always //foo:bar

will compile the target while stripping debugging information from all generated binaries.

Note that if you want debugging information, it's not enough to disable stripping; you also need to make sure that the debugging information was generated by the compiler, which you can do by using either -c dbg or --copt -g.

Note also that Bazel's --strip option corresponds with ld's --strip-debug option: it only strips debugging information. If for some reason you want to strip all symbols, not just debug symbols, you would need to use ld's --strip-all option, which you can do by passing --linkopt=-Wl,--strip-all to Bazel.

--stripopt strip-option

An additional option to pass to the strip command when generating a *.stripped binary. The default is -S -p. This option can be used multiple times.

Note that --stripopt does not apply to the stripping of the main binary with --strip=(always|sometimes).

--fdo_instrument profile-output-dir

The --fdo_instrument option enables the generation of FDO (feedback directed optimization) profile output when the built C/C++ binary is executed. For GCC, the argument provided is used as a directory prefix for a per-object file directory tree of .gcda files containing profile information for each .o file.

Once the profile data tree has been generated, the profile tree should be zipped up, and provided to the --fdo_optimize=profile-zip Bazel option to enable the FDO optimized compilation.

For the LLVM compiler the argument is also the directory under which the raw LLVM profile data file(s) is dumped, e.g. --fdo_instrument=/path/to/rawprof/dir/.

The options --fdo_instrument and --fdo_optimize cannot be used at the same time.

--fdo_optimize profile-zip

The --fdo_optimize option enables the use of the per-object file profile information to perform FDO (feedback directed optimization) optimizations when compiling. For GCC, the argument provided is the zip file containing the previously-generated file tree of .gcda files containing profile information for each .o file.

Alternatively, the argument provided can point to an auto profile identified by the extension .afdo.

Note that this option also accepts labels that resolve to source files. You may need to add an exports_filesdirective to the corresponding package to make the file visible to Bazel.

For the LLVM compiler the argument provided should point to the indexed LLVM profile output file prepared by the llvm-profdata tool, and should have a .profdata extension.

The options --fdo_instrument and --fdo_optimize cannot be used at the same time.

--lipo (off|binary)

The --lipo=binary option enables LIPO (Lightweight Inter-Procedural Optimization). LIPO is an extended C/C++ optimization technique that optimizes code across different object files. It involves compiling each C/C++ source file differently for every binary. This is in contrast to normal compilation where compilation outputs are reused. This means that LIPO is more expensive than normal compilation.

This option only has an effect when FDO is also enabled (see the --fdo_instrument and --fdo_options). Currently LIPO is only supported when building a single cc_binary rule.

Setting --lipo=binary implicitly sets --dynamic_mode=off.

--lipo_context context-binary

Specifies the label of a cc_binary rule that was used to generate the profile information for LIPO that was given to the --fdo_optimize option.

Specifying the context is mandatory when --lipo=binary is set. Using this option implicitly also sets --linkopt=-Wl,--warn-unresolved-symbols.


If enabled, each gold-invoked link of a C++ executable binary will also output a symbol counts file (via the --print-symbol-counts gold option) that logs the number of symbols from each .o input that were used in the binary. This can be used to track unnecessary link dependencies. The symbol counts file is written to the binary's output path with the name [targetname].sc.

This option is disabled by default.

--jvmopt jvm-option

This option allows option arguments to be passed to the Java VM. It can be used with one big argument, or multiple times with individual arguments. For example:
  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

will use the server VM for launching all Java binaries and set the startup heap size for the VM to 256 MB.

--javacopt javac-option

This option allows option arguments to be passed to javac. It can be used with one big argument, or multiple times with individual arguments. For example:
  % bazel build --javacopt="-g:source,lines" //myprojects:prog

will rebuild a java_binary with the javac default debug info (instead of the bazel default).

The option is passed to javac after the Bazel built-in default options for javac and before the per-rule options. The last specification of any option to javac wins. The default options for javac are:

  -source 8 -target 8 -encoding UTF-8

Note that changing --javacopt settings will force a recompilation of all affected classes. Also note that javacopts parameters listed in specific java_library or java_binary build rules will be placed on the javac command line afterthese options.

This javac option enables extra correctness checks. Any problems found will be presented as errors. Either -extra_checks or -extra_checks:on may be used to force the checks to be turned on. -extra_checks:offcompletely disables the analysis. When this option is not specified, the default behavior is used.

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

This option controls whether javac checks for missing direct dependencies. Java targets must explicitly declare all directly used targets as dependencies. This flag instructs javac to determine the jars actually used for type checking each java file, and warn/error if they are not the output of a direct dependency of the current target.
  • off means checking is disabled.
  • warn means javac will generate standard java warnings of type [strict] for each missing direct dependency.
  • defaultstrict and error all mean javac will generate errors instead of warnings, causing the current target to fail to build if any missing direct dependencies are found. This is also the default behavior when the flag is unspecified.

--javawarn (all|cast|deprecation|empty|unchecked|fallthrough|path|rawtypes|serial|finally|overrides)

This option is used to enable Java warnings across an entire build. It takes an argument which is a javac warning to be enabled, overriding any other Java options that disable the given warning. The arguments to this option are appended to the "-Xlint:" flag to javac, and must be exactly one of the listed warnings.

For example:

  % bazel build --javawarn="deprecation" --javawarn="unchecked" //java/...
Note that changing --javawarn settings will force a recompilation of all affected classes.


Semantics options

These options affect the build commands and/or the output file contents.

--compilation_mode (fastbuild|opt|dbg) (-c)
This option takes an argument of fastbuilddbg or opt, and affects various C/C++ code-generation options, such as the level of optimization and the completeness of debug tables. Bazel uses a different output directory for each different compilation mode, so you can switch between modes without needing to do a full rebuild every time.
  • fastbuild means build as fast as possible: generate minimal debugging information (-gmlt -Wl,-S), and don't optimize. This is the default. Note: -DNDEBUG will not be set.
  • dbg means build with debugging enabled (-g), so that you can use gdb (or another debugger).
  • opt means build with optimization enabled and with assert() calls disabled (-O2 -DNDEBUG). Debugging information will not be generated in opt mode unless you also pass --copt -g.

--cpu cpu

This option specifies the target CPU architecture to be used for the compilation of binaries during the build.

Note that a particular combination of crosstool version, compiler version, libc version, and target CPU is allowed only if it has been specified in the currently used CROSSTOOL file.

--host_cpu cpu
指定编译的机器的cpu架构,用于编译host 上的工具
This option specifies the name of the CPU architecture that should be used to build host tools.

The --experimental_skip_static_outputs option causes all statically-linked C++ binaries to not be output in any meaningful way.

If you set this flag, you must also set --distinct_host_configuration. It is also inherently incompatible with running tests — don't use it for that. This option is experimental and may go away at any time.

--per_file_copt [+-]regex[,[+-]regex]...@option[,option]...
任意符合正则表达式的C++ 文件指定编译选项
When present, any C++ file with a label or an execution path matching one of the inclusion regex expressions and not matching any of the exclusion expressions will be built with the given options. The label matching uses the canonical form of the label (i.e //package:label_name). The execution path is the relative path to your workspace directory including the base name (including extension) of the C++ file. It also includes any platform dependent prefixes. Note, that if only one of the label or the execution path matches the options will be used.

Notes: To match the generated files (e.g. genrule outputs) Bazel can only use the execution path. In this case the regexp shouldn't start with '//' since that doesn't match any execution paths. Package names can be used like this: --per_file_copt=base/.*\.pb\.cc@-g0. This will match every file under a directory called base.

This option can be used multiple times.

The option is applied regardless of the compilation mode used. I.e. it is possible to compile with --compilation_mode=opt and selectively compile some files with stronger optimization turned on, or with optimization disabled.

Caveat: If some files are selectively compiled with debug symbols the symbols might be stripped during linking. This can be prevented by setting --strip=never.

Syntax[+-]regex[,[+-]regex]...@option[,option]... Where regex stands for a regular expression that can be prefixed with a + to identify include patterns and with - to identify exclude patterns. option stands for an arbitrary option that is passed to the C++ compiler. If an option contains a , it has to be quoted like so \,. Options can also contain @, since only the first @ is used to separate regular expressions from options.

Example--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs adds the -O0 and the -fprofile-arcs options to the command line of the C++ compiler for all .cc files in //foo/ except

--dynamic_mode mode
Determines whether C++ binaries will be linked dynamically, interacting with the linkstatic attribute on build rules.


  • auto: Translates to a platform-dependent mode; default for linux and off for cygwin.
  • default: Allows bazel to choose whether to link dynamically. See linkstatic for more information.
  • fully: Links all targets dynamically. This will speed up linking time, and reduce the size of the resulting binaries.
  • off: Links all targets in mostly static mode. If -static is set in linkopts, targets will change to fully static.

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

Enables Fission, which writes C++ debug information to dedicated .dwo files instead of .o files, where it would otherwise go. This substantially reduces the input size to links and can reduce link times.

When set to [dbg][,opt][,fastbuild] (example: --fission=dbg,fastbuild), Fission is enabled only for the specified set of compilation modes. This is useful for bazelrc settings. When set to yes, Fission is enabled universally. When set to no, Fission is disabled universally. Default is dbg.


If this flag is set, any -static options in linkopts of cc_* rules BUILD files are ignored. This is only intended as a workaround for C++ hardening builds.


If enabled, all C++ compilations produce position-independent code ("-fPIC"), links prefer PIC pre-built libraries over non-PIC libraries, and links produce position-independent executables ("-pie"). Default is disabled.

Note that dynamically linked binaries (i.e. --dynamic_mode fully) generate PIC code regardless of this flag's setting. So this flag is for cases where users want PIC code explicitly generated for static links.

--custom_malloc malloc-library-target

When specified, always use the given malloc implementation, overriding all malloc="target" attributes, including in those targets that use the default (by not specifying any malloc).

--crosstool_top label

This option specifies the location of the crosstool compiler suite to be used for all C++ compilation during a build. Bazel will look in that location for a CROSSTOOL file and uses that to automatically determine settings for --compiler.

--host_crosstool_top label

If not specified, bazel uses the value of --crosstool_top to compile code in the host configuration, i.e., tools run during the build. The main purpose of this flag is to enable cross-compilation.

--compiler version

This option specifies the C/C++ compiler version (e.g. gcc-4.1.0) to be used for the compilation of binaries during the build. If you want to build with a custom crosstool, you should use a CROSSTOOL file instead of specifying this flag.

Note that only certain combinations of crosstool version, compiler version, libc version, and target CPU are allowed.

--glibc version

This option specifies the version of glibc that the target should be linked against. If you want to build with a custom crosstool, you should use a CROSSTOOL file instead of specifying this flag. In that case, Bazel will use the CROSSTOOL file and the following options where appropriate:

Note that only certain combinations of crosstool version, compiler version, glibc version, and target CPU are allowed.

--java_toolchain label

This option specifies the label of the java_toolchain used to compile Java source files.

--javabase (path|label)

This option sets the label or the path of the base Java installation to use for running JavaBuilder, SingleJar, for bazel run and bazel test, and for Java binaries built by java_binary and java_test rules. A path must be to a JDK or JRE directory that contains bin/java. The various "Make" variables for Java (JAVABASEJAVAJAVAC andJAR) are derived from this option.

This does not select the Java compiler that is used to compile Java source files. The compiler can be selected by settings the --java_toolchain option.

(1)bazel clean的解释

bazel clean --expunge
To completely remove the entire working tree created by a Bazel instance, you can specify the --expunge option. When executed with --expunge, the clean command simply removes the entire output base tree which, in addition to the build output, contains all temp files created by Bazel. It also stops the Bazel server after the clean, equivalent to the shutdown command. For example, to clean up all disk and memory traces of a Bazel instance, you could specify:

Bazel has a clean command, analogous to that of Make. It deletes the output directories for all build configurations performed by this Bazel instance, or the entire working tree created by this Bazel instance, and resets internal caches. If executed without any command-line options, then the output directory for all configurations will be cleaned.
Recall that each Bazel instance is associated with a single workspace, thus the clean command will delete all outputs from all builds you've done with that Bazel instance in that workspace.
The clean command is provided primarily as a means of reclaiming disk space for workspaces that are no longer needed. However, we recognize that Bazel's incremental rebuilds might not be perfect; clean may be used to recover a consistent state when problems arise.


The first is loading during which all the necessary BUILD files for the initial targets, and their transitive closure of dependencies, are loaded, parsed, evaluated and cached.

For the first build after a Bazel server is started, the loading phase typically takes many seconds as many BUILD files are loaded from the file system. In subsequent builds, especially if no BUILD files have changed, loading occurs very quickly.

Errors reported during this phase include: package not found, target not found, lexical and grammatical errors in a BUILD file, and evaluation errors.


The second phase, analysis, involves the semantic analysis and validation of each build rule, the construction of a build dependency graph, and the determination of exactly what work is to be done in each step of the build.

Like loading, analysis also takes several seconds when computed in its entirety. However, Bazel caches the dependency graph from one build to the next and only reanalyzes what it has to, which can make incremental builds extremely fast in the case where the packages haven't changed since the previous build.

Errors reported at this stage include: inappropriate dependencies, invalid inputs to a rule, and all rule-specific error messages.

The loading and analysis phases are fast because Bazel avoids unnecessary file I/O at this stage, reading only BUILD files in order to determine the work to be done. This is by design, and makes Bazel a good foundation for analysis tools, such as Bazel's query command, which is implemented atop the loading phase.

The third and final phase of the build is execution. This phase ensures that the outputs of each step in the build are consistent with its inputs, re-running compilation/linking/etc. tools as necessary. This step is where the build spends the majority of its time, ranging from a few seconds to over an hour for a large build. Errors reported during this phase include: missing source files, errors in a tool executed by some build action, or failure of a tool to produce the expected set of outputs.


发布了95 篇原创文章 · 获赞 239 · 访问量 81万+


©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客