bazel选项的部分翻译，希望给编译tf的童鞋参考

（1）bazel的选项解释

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打印出所有的选项，大多数选项只可以指定一次，当指定多次时，最后一次的指定才算数。可以指定多次的选项可以在帮助中看到：即说明该选项可以被指定多次。

1）指定包的位置的选项
See also the 

--show_package_location

 option.

--package_path

This option specifies the set of directories that are searched to find the
BUILD file for a given package.
该选项指定搜索BUILD文件的目录集合

--deleted_packages

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.
该选项以逗号为分隔符来指定那些包bazel需要忽略，这个选项并不是真的删除包，而是忽略某个或者某些包

2）错误检查选项

Error checking options

These options control Bazel's error-checking and/or warnings.
错误检查选项，该选项控制bazel的错误检查或者告警信息

--check_constraint constraint

该选项的输入指定那些限制应该被检查，bazel将会对每个规则执行特别的检查，支持的限制包括public
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.

--[no]check_visibility

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.
该选择如果设置为false，则不会告警，默认是true，需要检查可见性

--experimental_action_listener=label

 

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.

--experimental_extra_action_filter=regex

 

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/... \

  --experimental_extra_action_filter=.*/bar/.*

--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.

--[no]analysis_warnings_as_errors

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.

3）标志选项

Flags options

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

--copt gcc-option

该选项指定给gcc传递什么参数
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

该选项指定在host上进行编译时，给gcc在处理源码文件的时候需要传递给gcc的参数
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

该选项在gcc编辑c文件的时候需要传递给gcc的参数
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

该选项在gcc编辑c++文件的时候需要传递给gcc的参数
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

该选项在gcc进行链接的时候需要传递给gcc的参数
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_files

directive
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

.

--[no]output_symbol_counts

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

传递给jvm的选项
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

传递给javac的选项
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.

-extra_checks[:(off|on)]

是否打开额外的正确性检查
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:off

completely disables the analysis. When this
option is not specified, the default behavior is used.

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

控制是否javac是否需要检查是否丢失直接的依赖
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.

default

, 

strict

 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)

是否显示java在编译过程中的警告
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.

4）语义选项

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 

fastbuild

, 

dbg

 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

指定目标gpu的架构
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.

--experimental_skip_static_outputs

静态链接C++的二进制文件作为输出
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 

.pb.cc

 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 

file.cc

.

--dynamic_mode mode

是否将C++二进制文件进行动态链接
Determines whether C++ binaries will be linked dynamically, interacting with the linkstatic
attribute on build rules.

Modes:

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

.

--force_ignore_dash_static

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.

--[no]force_pic

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:

--cpu

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 (

JAVABASE

, 

JAVA

, 

JAVAC

 and

JAR

)
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

该命令不仅仅要删除输出文件的目录树，还要删除Bazel产生的所有临时文件，包括下载的临时文件也要删除

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:

而不带--expunge的则只是删除编译项目的编译过程中产生的目录树，而不删除bazel产生的临时文件

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.

（2）bazel的几个阶段

1）加载阶段：

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.
加载阶段主要就是读取所有的BUILD文件，
所出现的错误主要就是：
包没有找到，目标找不到，BUILD文件的语法或者词法错误，验证错误等等

2）分析阶段

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.
分析阶段主要对每个构建规则进行语法分析和验证，产生构建依赖图，并且确定在构建的每一步当中需要做什么工作。在分析阶段bazel可以将某个构建的依赖图缓存到下一次来进行使用，而只分析所需要分析的那部分，这能够是的增量构建特别快。
这一阶段所报的错误主要就是：不合理的依赖，规则中无效的输入，以及其他所有的与规则相关的错误信息

3）执行阶段

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.

执行阶段保证在构建的过程中每一步的输出和输入一致，这一过程中可能需要不断地运行编译链接工具。这一阶段占据了大部分时间。

本阶段的错误包括：

丢失源码，工具执行的过程中产生的错误，工具无法产生所期望的输出。

转载请注明出处：http://blog.csdn.net/xizero00