Common definitions
This section defines various terms and concepts that are common to many functions or build rules.
Contents
Bourne shell tokenization
Certain string attributes of some rules are split into multiple words according to the tokenization rules of the Bourne shell: unquoted spaces delimit separate words, and single- and double-quotes characters and backslashes are used to prevent tokenization.
Those attributes that are subject to this tokenization are explicitly indicated as such in their definitions in this document.
Attributes subject to "Make" variable expansion and Bourne shell
tokenization are typically used for passing arbitrary options to
compilers and other tools. Examples of such attributes are
cc_library.copts and java_library.javacopts.
Together these substitutions allow a
single string variable to expand into a configuration-specific list
of option words.
Label expansion
Some string attributes of a very few rules are subject to label
expansion: if those strings contain a valid label as a
substring, such as //mypkg:target, and that label is a
declared prerequisite of the current rule, it is expanded into the
pathname of the file represented by the
target
//mypkg:target.
Example attributes include genrule.cmd and
cc_binary.linkopts. The details may vary significantly in
each case, over such issues as: whether relative labels are
expanded; how labels that expand to multiple files are
treated, etc. Consult the rule attribute documentation for
specifics.
Typical attributes defined by most build rules
This section describes attributes that are defined by many build rules, but not all.
| Attribute | Description |
|---|---|
data |
Files needed by this rule at runtime. May list file or rule targets. Generally allows any target.
The default outputs and runfiles of targets in the
New rules should define a |
deps |
Dependencies for this target. Generally should only list rule targets. (Though
some rules permit files to be listed directly in Language-specific rules generally limit the listed targets to those with specific providers.
The precise semantics of what it means for a target to depend on another using
Most often, a |
licenses |
A list of license-type strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
srcs |
Files processed or included by this rule. Generally lists files directly, but
may list rule targets (like Language-specific rules often require that the listed files have particular file extensions. |
Attributes common to all build rules
This section describes attributes that are implicitly added to all build rules.
| Attribute | Description |
|---|---|
compatible_with |
The list of environments this target can be built for, in addition to default-supported environments. This is part of Bazel's constraint system, which lets users declare which targets can and cannot depend on each other. For example, externally deployable binaries shouldn't depend on libraries with company-secret code. See ConstraintSemantics for details. |
deprecation |
An explanatory warning message associated with this target. Typically this is used to notify users that a target has become obsolete, or has become superseded by another rule, is private to a package, or is perhaps considered harmful for some reason. It is a good idea to include some reference (like a webpage, a bug number or example migration CLs) so that one can easily find out what changes are required to avoid the message. If there is a new target that can be used as a drop in replacement, it is a good idea to just migrate all users of the old target.
This attribute has no effect on the way things are built, but it
may affect a build tool's diagnostic output. The build tool issues a
warning when a rule with a Intra-package dependencies are exempt from this warning, so that, for example, building the tests of a deprecated rule does not encounter a warning. If a deprecated target depends on another deprecated target, no warning message is issued. Once people have stopped using it, the target can be removed. |
distribs |
A list of distribution-method strings to be used for this particular target. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
exec_compatible_with |
A list of
|
exec_properties |
A dictionary of strings that will be added to the If a key is present in both the platform and target-level properties, the value will be taken from the target. |
features |
A feature is string tag that can be enabled or disabled on a target. The meaning of a feature depends on the rule itself. This |
restricted_to |
The list of environments this target can be built for, instead of default-supported environments.
This is part of Bazel's constraint system. See
|
tags |
Tags can be used on any rule. Tags on test and
Bazel modifies the behavior of its sandboxing code if it finds the following
keywords in the
Tags on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.
Bazel modifies test running behavior if it finds the following keywords in the
|
target_compatible_with |
A list of
Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing. An empty list (which is the default) signifies that the target is compatible with all platforms.
All rules other than Workspace Rules support this
attribute.
For some rules this attribute has no effect. For example, specifying
See the Platforms page for more information about incompatible target skipping. |
testonly |
If True, only testonly targets (such as tests) can depend on this target.
Equivalently, a rule that is not
Tests ( This attribute is intended to mean that the target should not be contained in binaries that are released to production. Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
toolchains |
The set of targets whose Make variables this target is
allowed to access. These targets are either instances of rules that provide
Note that this is distinct from the concept of
toolchain resolution
that is used by rule implementations for platform-dependent configuration. You cannot use this
attribute to determine which specific |
visibility |
The |
Attributes common to all test rules (*_test)
This section describes attributes that are common to all test rules.
| Attribute | Description | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
args |
Command line arguments that Bazel passes to the target when it is
executed with
These arguments are passed before any |
||||||||||||||||||||
env |
Specifies additional environment variables to set when the test is executed by
This attribute only applies to native rules, like |
||||||||||||||||||||
env_inherit |
Specifies additional environment variables to inherit from the
external environment when the test is executed by
This attribute only applies to native rules, like |
||||||||||||||||||||
size |
Specifies a test's "heaviness": how much time/resources it needs to run. Unit tests are considered "small", integration tests "medium", and end-to-end tests "large" or
"enormous". Bazel uses the size to determine a default timeout, which can be overridden using the
Test sizes correspond to the following default timeouts and assumed peak local resource usages:
The environment variable
|
||||||||||||||||||||
timeout |
How long the test is expected to run before returning.
While a test's size attribute controls resource estimation, a test's
timeout may be set independently. If not explicitly specified, the
timeout is based on the test's size. The test
timeout can be overridden with the
For times other than the above, the test timeout can be overridden with the
The environment variable
|
||||||||||||||||||||
flaky |
Marks test as flaky. If set, executes the test up to three times, marking it as failed only if it fails each time. By default, this attribute is set to False and the test is executed only once. Note, that use of this attribute is generally discouraged - tests should pass reliably when their assertions are upheld. |
||||||||||||||||||||
shard_count |
Specifies the number of parallel shards to use to run the test. This value will override any heuristics used to determine the number of
parallel shards with which to run the test. Note that for some test
rules, this parameter may be required to enable sharding
in the first place. Also see If test sharding is enabled, the environment variable
Sharding requires the test runner to support the test sharding protocol. If it does not, then it will most likely run every test in every shard, which is not what you want. See Test Sharding in the Test Encyclopedia for details on sharding. |
||||||||||||||||||||
local |
Forces the test to be run locally, without sandboxing. Setting this to True is equivalent to providing "local" as a tag
( |
Attributes common to all binary rules (*_binary)
This section describes attributes that are common to all binary rules.
| Attribute | Description |
|---|---|
args |
Command line arguments that Bazel will pass to the target when it is executed
either by the
NOTE: The arguments are not passed when you run the target
outside of Bazel (for example, by manually executing the binary in
|
env |
Specifies additional environment variables to set when the target is
executed by
This attribute only applies to native rules, like
NOTE: The environment variables are not set when you run the target
outside of Bazel (for example, by manually executing the binary in
|
output_licenses |
The licenses of the output files that this binary generates. This is part of a deprecated licensing API that Bazel no longer uses. Don't use this. |
Configurable attributes
Most attributes are "configurable", meaning that their values may change when the target is built in different ways. Specifically, configurable attributes may vary based on the flags passed to the Bazel command line, or what downstream dependency is requesting the target. This can be used, for instance, to customize the target for multiple platforms or compilation modes.
The following example declares different sources for different target
architectures. Running bazel build :multiplatform_lib --cpu x86
will build the target using x86_impl.cc, while substituting
--cpu arm will instead cause it to use arm_impl.cc.
cc_library(
name = "multiplatform_lib",
srcs = select({
":x86_mode": ["x86_impl.cc"],
":arm_mode": ["arm_impl.cc"]
})
)
config_setting(
name = "x86_mode",
values = { "cpu": "x86" }
)
config_setting(
name = "arm_mode",
values = { "cpu": "arm" }
)
The select() function
chooses among different alternative values for a configurable attribute based
on which config_setting
or constraint_value
criteria the target's configuration satisfies.
Bazel evaluates configurable attributes after processing macros and before
processing rules (technically, between the
loading and analysis phases).
Any processing before select() evaluation doesn't know which
branch the select() chooses. Macros, for example, can't change
their behavior based on the chosen branch, and bazel query can
only make conservative guesses about a target's configurable dependencies. See
this FAQ
for more on using select() with rules and macros.
Attributes marked nonconfigurable in their documentation cannot
use this feature. Usually an attribute is nonconfigurable because Bazel
internally needs to know its value before it can determine how to resolve a
select().
See Configurable Build Attributes for a detailed overview.
Implicit output targets
Implicit outputs in C++ are deprecated. Please refrain from using it in other languages where possible. We don't have a deprecation path yet but they will eventually be deprecated too.
When you define a build rule in a BUILD file, you are explicitly
declaring a new, named rule target in a package. Many build rule
functions also implicitly entail one or more output file
targets, whose contents and meaning are rule-specific.
For example, when you explicitly declare a
java_binary(name='foo', ...) rule, you are also
implicitly declaring an output file
target foo_deploy.jar as a member of the same package.
(This particular target is a self-contained Java archive suitable
for deployment.)
Implicit output targets are first-class members of the global
target graph. Just like other targets, they are built on demand,
either when specified in the top-level built command, or when they
are necessary prerequisites for other build targets. They can be
referenced as dependencies in BUILD files, and can be observed in
the output of analysis tools such as bazel query.
For each kind of build rule, the rule's documentation contains a special section detailing the names and contents of any implicit outputs entailed by a declaration of that kind of rule.
An important but somewhat subtle distinction between the
two namespaces used by the build system:
labels identify targets,
which may be rules or files, and file targets may be divided into
either source (or input) file targets and derived (or output) file
targets. These are the things you can mention in BUILD files,
build from the command-line, or examine using bazel query;
this is the target namespace. Each file target corresponds
to one actual file on disk (the "file system namespace"); each rule
target may correspond to zero, one or more actual files on disk.
There may be files on disk that have no corresponding target; for
example, .o object files produced during C++ compilation
cannot be referenced from within BUILD files or from the command line.
In this way, the build tool may hide certain implementation details of
how it does its job. This is explained more fully in
the BUILD Concept Reference.