Google Git
Sign in
bazel/bazel/a640dc240f79ef811fb4089436f1ba6d84ea6bc9/./docs/versions/6.2.0/reference/be/c-cpp.mdx
blob: 4a59ecb73d409b6fcd3aa7e99baef852350a7317 [file]
<html devsite>
<head>
<meta name="project_path" value="/_project.yaml">
<meta name="book_path" value="/versions/6.2.0/_book.yaml">
</head>
<body>
<!--
This document is synchronized with Bazel releases.
To edit, submit changes to the Bazel source code.
-->
<!-- Generated by //src/main/java/com/google/devtools/build/docgen:build-encyclopedia.zip -->
<html>
<body>
<h1 class="page-title">C / C++ Rules</h1>
<h2>Rules</h2>
<ul>
<li>
<a href="#cc_binary">
cc_binary </a>
</li>
<li>
<a href="#cc_import">
cc_import </a>
</li>
<li>
<a href="#cc_library">
cc_library </a>
</li>
<li>
<a href="#cc_proto_library">
cc_proto_library </a>
</li>
<li>
<a href="#fdo_prefetch_hints">
fdo_prefetch_hints </a>
</li>
<li>
<a href="#fdo_profile">
fdo_profile </a>
</li>
<li>
<a href="#propeller_optimize">
propeller_optimize </a>
</li>
<li>
<a href="#cc_test">
cc_test </a>
</li>
<li>
<a href="#cc_toolchain">
cc_toolchain </a>
</li>
<li>
<a href="#cc_toolchain_suite">
cc_toolchain_suite </a>
</li>
</ul>
<h2 id="cc_binary">
cc_binary
</h2>
<pre class="rule-signature">cc_binary(<a href="#cc_binary.name">name</a>, <a href="#cc_binary.deps">deps</a>, <a href="#cc_binary.srcs">srcs</a>, <a href="common-definitions.html#typical.data">data</a>, <a href="#cc_binary.additional_linker_inputs">additional_linker_inputs</a>, <a href="common-definitions.html#binary.args">args</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="#cc_binary.copts">copts</a>, <a href="#cc_binary.defines">defines</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#binary.env">env</a>, <a href="common-definitions.html#common.exec_compatible_with">exec_compatible_with</a>, <a href="common-definitions.html#common.exec_properties">exec_properties</a>, <a href="common-definitions.html#common.features">features</a>, <a href="#cc_binary.includes">includes</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#cc_binary.linkopts">linkopts</a>, <a href="#cc_binary.linkshared">linkshared</a>, <a href="#cc_binary.linkstatic">linkstatic</a>, <a href="#cc_binary.local_defines">local_defines</a>, <a href="#cc_binary.malloc">malloc</a>, <a href="#cc_binary.nocopts">nocopts</a>, <a href="common-definitions.html#binary.output_licenses">output_licenses</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="#cc_binary.stamp">stamp</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.toolchains">toolchains</a>, <a href="common-definitions.html#common.visibility">visibility</a>, <a href="#cc_binary.win_def_file">win_def_file</a>)</pre>
<h4 id="cc_binary_implicit_outputs">Implicit output targets</h4>
<ul>
<li><code><var>name</var>.stripped</code> (only built if explicitly requested): A stripped
version of the binary. <code>strip -g</code> is run on the binary to remove debug
symbols. Additional strip options can be provided on the command line using
<code>--stripopt=-foo</code>. This output is only built if explicitly requested.</li>
<li><code><var>name</var>.dwp</code> (only built if explicitly requested): If
<a href="https://gcc.gnu.org/wiki/DebugFission">Fission</a> is enabled: a debug
information package file suitable for debugging remotely deployed binaries. Else: an
empty file.</li>
</ul>
<h3 id="cc_binary_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_binary.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_binary.deps">
<code>deps</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of other libraries to be linked in to the binary target.
<p>These can be <code>cc_library</code> or <code>objc_library</code>
targets.</p>
</td>
</tr>
<tr>
<td id="cc_binary.srcs">
<code>srcs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of C and C++ files that are processed to create the target.
These are C/C++ source and header files, either non-generated (normal source
code) or generated.
<p>All <code>.cc</code>, <code>.c</code>, and <code>.cpp</code> files will
be compiled. These might be generated files: if a named file is in
the <code>outs</code> of some other rule, this rule
will automatically depend on that other rule.
</p>
<p>A <code>.h</code> file will not be compiled, but will be available for
inclusion by sources in this rule. Both <code>.cc</code> and
<code>.h</code> files can directly include headers listed in
these <code>srcs</code> or in the <code>hdrs</code> of any rule listed in
the <code>deps</code> argument.
</p>
<p>All <code>#include</code>d files must be mentioned in the
<code>srcs</code> attribute of this rule, or in the
<code>hdrs</code> attribute of referenced <code>cc_library()</code>s.
The recommended style is for headers associated with a library to be
listed in that library's <code>hdrs</code> attribute, and any remaining
headers associated with this rule's sources to be listed in
<code>srcs</code>. See <a href="#hdrs">"Header inclusion checking"</a>
for a more detailed description.
</p>
<p>If a rule's name is in the <code>srcs</code>,
then this rule automatically depends on that one.
If the named rule's <code>outs</code> are C or C++
source files, they are compiled into this rule;
if they are library files, they are linked in.
</p>
<p>
Permitted <code>srcs</code> file types:
</p>
<ul>
<li>C and C++ source files: <code>.c</code>, <code>.cc</code>, <code>.cpp</code>,
<code>.cxx</code>, <code>.c++</code>, <code>.C</code></li>
<li>C and C++ header files: <code>.h</code>, <code>.hh</code>, <code>.hpp</code>,
<code>.hxx</code>, <code>.inc</code>, <code>.inl</code>, <code>.H</code></li>
<li>Assembler with C preprocessor: <code>.S</code></li>
<li>Archive: <code>.a</code>, <code>.pic.a</code></li>
<li>"Always link" library: <code>.lo</code>, <code>.pic.lo</code></li>
<li>Shared library, versioned or unversioned: <code>.so</code>,
<code>.so.<i>version</i></code></li>
<li>Object file: <code>.o</code>, <code>.pic.o</code></li>
</ul>
<p>
...and any rules that produce those files.
Different extensions denote different programming languages in
accordance with gcc convention.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.additional_linker_inputs">
<code>additional_linker_inputs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
Pass these files to the C++ linker command.
<p>
For example, compiled Windows .res files can be provided here to be embedded in
the binary target.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.copts">
<code>copts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these options to the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
<p>
Each string in this attribute is added in the given order to <code>COPTS</code> before
compiling the binary target. The flags take effect only for compiling this target, not
its dependencies, so be careful about header files included elsewhere. All paths should
be relative to the workspace, not to the current package.
</p>
<p>
If the package declares the <a href="/versions/6.2.0/reference/be/functions.html#package.features">feature</a>
<code>no_copts_tokenization</code>, Bourne shell tokenization applies only to strings
that consist of a single "Make" variable.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.defines">
<code>defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line to this target,
as well as to every rule that depends on it. Be very careful, since this may have
far-reaching effects. When in doubt, add define values to
<a href="#cc_binary.local_defines"><code>local_defines</code></a> instead.
</td>
</tr>
<tr>
<td id="cc_binary.includes">
<code>includes</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of include dirs to be added to the compile line.
<p>
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution.
Each string is prepended with <code>-isystem</code> and added to <code>COPTS</code>.
Unlike <a href="#cc_binary.copts">COPTS</a>, these flags are added for this rule
and every rule that depends on it. (Note: not the rules it depends upon!) Be
very careful, since this may have far-reaching effects. When in doubt, add
"-I" flags to <a href="#cc_binary.copts">COPTS</a> instead.
</p>
<p>
Headers must be added to srcs or hdrs, otherwise they will not be available to dependent
rules when compilation is sandboxed (the default).
</p>
</td>
</tr>
<tr>
<td id="cc_binary.linkopts">
<code>linkopts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these flags to the C++ linker command.
Subject to <a href="make-variables.html">"Make" variable</a> substitution,
<a href="common-definitions.html#sh-tokenization">
Bourne shell tokenization</a> and
<a href="common-definitions.html#label-expansion">label expansion</a>.
Each string in this attribute is added to <code>LINKOPTS</code> before
linking the binary target.
<p>
Each element of this list that does not start with <code>$</code> or <code>-</code> is
assumed to be the label of a target in <code>deps</code>. The
list of files generated by that target is appended to the linker
options. An error is reported if the label is invalid, or is
not declared in <code>deps</code>.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.linkshared">
<code>linkshared</code>
</td>
<td>
<p><code>Boolean; optional; <a href="common-definitions.html#configurable-attributes">nonconfigurable</a>; default is False</code></p>
Create a shared library.
To enable this attribute, include <code>linkshared=True</code> in your rule. By default
this option is off.
<p>
The presence of this flag means that linking occurs with the <code>-shared</code> flag
to <code>gcc</code>, and the resulting shared library is suitable for loading into for
example a Java program. However, for build purposes it will never be linked into the
dependent binary, as it is assumed that shared libraries built with a
<a href="#cc_binary">cc_binary</a> rule are only loaded manually by other programs, so
it should not be considered a substitute for the <a href="#cc_library">cc_library</a>
rule. For sake of scalability we recommend avoiding this approach altogether and
simply letting <code>java_library</code> depend on <code>cc_library</code> rules
instead.
</p>
<p>
If you specify both <code>linkopts=['-static']</code> and <code>linkshared=True</code>,
you get a single completely self-contained unit. If you specify both
<code>linkstatic=True</code> and <code>linkshared=True</code>, you get a single, mostly
self-contained unit.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.linkstatic">
<code>linkstatic</code>
</td>
<td>
<p><code>Boolean; optional; default is True</code></p>
For <a href="/versions/6.2.0/reference/be/c-cpp.html#cc_binary"><code>cc_binary</code></a> and
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_test"><code>cc_test</code></a>: link the binary in static
mode. For <code>cc_library.linkstatic</code>: see below.
<p>
By default this option is on for <code>cc_binary</code> and off for the rest.
</p>
<p>
If enabled and this is a binary or test, this option tells the build tool to link in
<code>.a</code>'s instead of <code>.so</code>'s for user libraries whenever possible.
Some system libraries may still be linked dynamically, as are libraries for which
there is no static library. So the resulting executable will still be dynamically
linked, hence only <i>mostly</i> static.
</p>
<p>There are really three different ways to link an executable:</p>
<ul>
<li> STATIC with fully_static_link feature, in which everything is linked statically;
e.g. "<code>gcc -static foo.o libbar.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>fully_static_link</code> in the
<a href="/versions/6.2.0/reference/be/common-definitions#features"><code>features</code></a> attribute.</li>
<li> STATIC, in which all user libraries are linked statically (if a static
version is available), but where system libraries (excluding C/C++ runtime libraries)
are linked dynamically, e.g. "<code>gcc foo.o libfoo.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=True</code>.</li>
<li> DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is
available), e.g. "<code>gcc foo.o libfoo.so libbaz.so -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=False</code>.</li>
</ul>
<p>
The <code>linkstatic</code> attribute has a different meaning if used on a
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_library"><code>cc_library()</code></a> rule.
For a C++ library, <code>linkstatic=True</code> indicates that only
static linking is allowed, so no <code>.so</code> will be produced. linkstatic=False does
not prevent static libraries from being created. The attribute is meant to control the
creation of dynamic libraries.
</p>
<p>
If <code>linkstatic=False</code>, then the build tool will create symlinks to
depended-upon shared libraries in the <code>*.runfiles</code> area.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.local_defines">
<code>local_defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line for this target,
but not to its dependents.
</td>
</tr>
<tr>
<td id="cc_binary.malloc">
<code>malloc</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional; default is <code>@bazel_tools//tools/cpp:malloc</code></code></p>
Override the default dependency on malloc.
<p>
By default, C++ binaries are linked against <code>//tools/cpp:malloc</code>,
which is an empty library so the binary ends up using libc malloc.
This label must refer to a <code>cc_library</code>. If compilation is for a non-C++
rule, this option has no effect. The value of this attribute is ignored if
<code>linkshared=True</code> is specified.
</p>
</td>
</tr>
<tr>
<td id="cc_binary.nocopts">
<code>nocopts</code>
</td>
<td>
<p><code>String; optional</code></p>
Remove matching options from the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution.
The value of this attribute is interpreted as a regular expression.
Any preexisting <code>COPTS</code> that match this regular expression
(including values explicitly specified in the rule's <a
href="#cc_binary.copts">copts</a> attribute) will be removed from
<code>COPTS</code> for purposes of compiling this rule.
This attribute should rarely be needed.
</td>
</tr>
<tr>
<td id="cc_binary.stamp">
<code>stamp</code>
</td>
<td>
<p><code>Integer; optional; default is -1</code></p>
Whether to encode build information into the binary. Possible values:
<ul>
<li>
<code>stamp = 1</code>: Always stamp the build information into the binary, even in
<a href="/versions/6.2.0/docs/user-manual#flag--stamp"><code>--nostamp</code></a> builds. <b>This
setting should be avoided</b>, since it potentially kills remote caching for the
binary and any downstream actions that depend on it.
</li>
<li>
<code>stamp = 0</code>: Always replace build information by constant values. This
gives good build result caching.
</li>
<li>
<code>stamp = -1</code>: Embedding of build information is controlled by the
<a href="/versions/6.2.0/docs/user-manual#flag--stamp"><code>--[no]stamp</code></a> flag.
</li>
</ul>
<p>Stamped binaries are <em>not</em> rebuilt unless their dependencies change.</p>
</td>
</tr>
<tr>
<td id="cc_binary.win_def_file">
<code>win_def_file</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
The Windows DEF file to be passed to linker.
<p>This attribute should only be used when Windows is the target platform.
It can be used to <a href="https://msdn.microsoft.com/en-us/library/d91k01sh.aspx">
export symbols</a> during linking a shared library.</p>
</td>
</tr>
</tbody>
</table>
<h2 id="cc_import">
cc_import
</h2>
<pre class="rule-signature">cc_import(<a href="#cc_import.name">name</a>, <a href="common-definitions.html#typical.data">data</a>, <a href="#cc_import.hdrs">hdrs</a>, <a href="#cc_import.alwayslink">alwayslink</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="#cc_import.interface_library">interface_library</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="#cc_import.shared_library">shared_library</a>, <a href="#cc_import.static_library">static_library</a>, <a href="#cc_import.system_provided">system_provided</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>
<code>cc_import</code> rules allows users to import precompiled C/C++ libraries.
</p>
<p>
The following are the typical use cases: <br/>
1. Linking a static library
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.a",
# If alwayslink is turned on,
# libmylib.a will be forcely linked into any binary that depends on it.
# alwayslink = 1,
)
</pre>
2. Linking a shared library (Unix)
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
shared_library = "libmylib.so",
)
</pre>
3. Linking a shared library with interface library (Windows)
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
# mylib.lib is a import library for mylib.dll which will be passed to linker
interface_library = "mylib.lib",
# mylib.dll will be available for runtime
shared_library = "mylib.dll",
)
</pre>
4. Linking a shared library with <code>system_provided=True</code> (Windows)
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
# mylib.lib is an import library for mylib.dll which will be passed to linker
interface_library = "mylib.lib",
# mylib.dll is provided by system environment, for example it can be found in PATH.
# This indicates that Bazel is not responsible for making mylib.dll available.
system_provided = 1,
)
</pre>
5. Linking to static or shared library <br/>
On Unix:
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.a",
shared_library = "libmylib.so",
)
# first will link to libmylib.a
cc_binary(
name = "first",
srcs = ["first.cc"],
deps = [":mylib"],
linkstatic = 1, # default value
)
# second will link to libmylib.so
cc_binary(
name = "second",
srcs = ["second.cc"],
deps = [":mylib"],
linkstatic = 0,
)
</pre>
On Windows:
<pre class="code">
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.lib", # A normal static library
interface_library = "mylib.lib", # An import library for mylib.dll
shared_library = "mylib.dll",
)
# first will link to libmylib.lib
cc_binary(
name = "first",
srcs = ["first.cc"],
deps = [":mylib"],
linkstatic = 1, # default value
)
# second will link to mylib.dll through mylib.lib
cc_binary(
name = "second",
srcs = ["second.cc"],
deps = [":mylib"],
linkstatic = 0,
)
</pre>
</p>
<h3 id="cc_import_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_import.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_import.hdrs">
<code>hdrs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of header files published by
this precompiled library to be directly included by sources in dependent rules.
</td>
</tr>
<tr>
<td id="cc_import.alwayslink">
<code>alwayslink</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
If 1, any binary that depends (directly or indirectly) on this C++
precompiled library will link in all the object files archived in the static library,
even if some contain no symbols referenced by the binary.
This is useful if your code isn't explicitly called by code in
the binary, e.g., if your code registers to receive some callback
provided by some service.
<p>If alwayslink doesn't work with VS 2017 on Windows, that is due to a
<a href="https://github.com/bazelbuild/bazel/issues/3949">known issue</a>,
please upgrade your VS 2017 to the latest version.</p>
</td>
</tr>
<tr>
<td id="cc_import.interface_library">
<code>interface_library</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
A single interface library for linking the shared library.
<p> Permitted file types:
<code>.ifso</code>,
<code>.tbd</code>,
<code>.lib</code>,
<code>.so</code>
or <code>.dylib</code>
</p>
</td>
</tr>
<tr>
<td id="cc_import.shared_library">
<code>shared_library</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
A single precompiled shared library. Bazel ensures it is available to the
binary that depends on it during runtime.
<p> Permitted file types:
<code>.so</code>,
<code>.dll</code>
or <code>.dylib</code>
</p>
</td>
</tr>
<tr>
<td id="cc_import.static_library">
<code>static_library</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
A single precompiled static library.
<p> Permitted file types:
<code>.a</code>,
<code>.pic.a</code>
or <code>.lib</code>
</p>
</td>
</tr>
<tr>
<td id="cc_import.system_provided">
<code>system_provided</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
If 1, it indicates the shared library required at runtime is provided by the system. In
this case, <code>interface_library</code> should be specified and
<code>shared_library</code> should be empty.
</td>
</tr>
</tbody>
</table>
<h2 id="cc_library">
cc_library
</h2>
<pre class="rule-signature">cc_library(<a href="#cc_library.name">name</a>, <a href="#cc_library.deps">deps</a>, <a href="#cc_library.srcs">srcs</a>, <a href="common-definitions.html#typical.data">data</a>, <a href="#cc_library.hdrs">hdrs</a>, <a href="#cc_library.alwayslink">alwayslink</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="#cc_library.copts">copts</a>, <a href="#cc_library.defines">defines</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.exec_compatible_with">exec_compatible_with</a>, <a href="common-definitions.html#common.exec_properties">exec_properties</a>, <a href="common-definitions.html#common.features">features</a>, <a href="#cc_library.implementation_deps">implementation_deps</a>, <a href="#cc_library.include_prefix">include_prefix</a>, <a href="#cc_library.includes">includes</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#cc_library.linkopts">linkopts</a>, <a href="#cc_library.linkstamp">linkstamp</a>, <a href="#cc_library.linkstatic">linkstatic</a>, <a href="#cc_library.local_defines">local_defines</a>, <a href="#cc_library.nocopts">nocopts</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="#cc_library.strip_include_prefix">strip_include_prefix</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="#cc_library.textual_hdrs">textual_hdrs</a>, <a href="common-definitions.html#common.toolchains">toolchains</a>, <a href="common-definitions.html#common.visibility">visibility</a>, <a href="#cc_library.win_def_file">win_def_file</a>)</pre>
<h4 id="hdrs">Header inclusion checking</h4>
<p>
All header files that are used in the build must be declared in the <code>hdrs</code> or
<code>srcs</code> of <code>cc_*</code> rules. This is enforced.
</p>
<p>
For <code>cc_library</code> rules, headers in <code>hdrs</code> comprise the public interface of
the library and can be directly included both from the files in <code>hdrs</code> and
<code>srcs</code> of the library itself as well as from files in <code>hdrs</code> and
<code>srcs</code> of <code>cc_*</code> rules that list the library in their <code>deps</code>.
Headers in <code>srcs</code> must only be directly included from the files in <code>hdrs</code>
and <code>srcs</code> of the library itself. When deciding whether to put a header into
<code>hdrs</code> or <code>srcs</code>, you should ask whether you want consumers of this library
to be able to directly include it. This is roughly the same decision as between
<code>public</code> and <code>private</code> visibility in programming languages.
</p>
<p>
<code>cc_binary</code> and <code>cc_test</code> rules do not have an exported interface, so they
also do not have a <code>hdrs</code> attribute. All headers that belong to the binary or test
directly should be listed in the <code>srcs</code>.
</p>
<p>
To illustrate these rules, look at the following example.
</p>
<pre class="code">
cc_binary(
name = "foo",
srcs = [
"foo.cc",
"foo.h",
],
deps = [":bar"],
)
cc_library(
name = "bar",
srcs = [
"bar.cc",
"bar-impl.h",
],
hdrs = ["bar.h"],
deps = [":baz"],
)
cc_library(
name = "baz",
srcs = [
"baz.cc",
"baz-impl.h",
],
hdrs = ["baz.h"],
)
</pre>
<p>
The allowed direct inclusions in this example are listed in the table below. For example
<code>foo.cc</code> is allowed to directly include <code>foo.h</code> and <code>bar.h</code>, but
not <code>baz.h</code>.
</p>
<table class="table table-striped table-bordered table-condensed">
<thead>
<tr><th>Including file</th><th>Allowed inclusions</th></tr>
</thead>
<tbody>
<tr><td>foo.h</td><td>bar.h</td></tr>
<tr><td>foo.cc</td><td>foo.h bar.h</td></tr>
<tr><td>bar.h</td><td>bar-impl.h baz.h</td></tr>
<tr><td>bar-impl.h</td><td>bar.h baz.h</td></tr>
<tr><td>bar.cc</td><td>bar.h bar-impl.h baz.h</td></tr>
<tr><td>baz.h</td><td>baz-impl.h</td></tr>
<tr><td>baz-impl.h</td><td>baz.h</td></tr>
<tr><td>baz.cc</td><td>baz.h baz-impl.h</td></tr>
</tbody>
</table>
<p>
The inclusion checking rules only apply to <em>direct</em>
inclusions. In the example above <code>foo.cc</code> is allowed to
include <code>bar.h</code>, which may include <code>baz.h</code>, which in
turn is allowed to include <code>baz-impl.h</code>. Technically, the
compilation of a <code>.cc</code> file may transitively include any header
file in the <code>hdrs</code> or <code>srcs</code> in
any <code>cc_library</code> in the transitive <code>deps</code> closure. In
this case the compiler may read <code>baz.h</code> and <code>baz-impl.h</code>
when compiling <code>foo.cc</code>, but <code>foo.cc</code> must not
contain <code>#include "baz.h"</code>. For that to be
allowed, <code>baz</code> must be added to the <code>deps</code>
of <code>foo</code>.
</p>
<p>
Unfortunately Bazel currently cannot distinguish between direct and transitive
inclusions, so it cannot detect error cases where a file illegally includes a
header directly that is only allowed to be included transitively. For example,
Bazel would not complain if in the example above <code>foo.cc</code> directly
includes <code>baz.h</code>. This would be illegal, because <code>foo</code>
does not directly depend on <code>baz</code>. Currently, no error is produced
in that case, but such error checking may be added in the future.
</p>
<h3 id="cc_library_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_library.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_library.deps">
<code>deps</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of other libraries to be linked in to the binary target.
<p>These can be <code>cc_library</code> or <code>objc_library</code>
targets.</p>
</td>
</tr>
<tr>
<td id="cc_library.srcs">
<code>srcs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of C and C++ files that are processed to create the target.
These are C/C++ source and header files, either non-generated (normal source
code) or generated.
<p>All <code>.cc</code>, <code>.c</code>, and <code>.cpp</code> files will
be compiled. These might be generated files: if a named file is in
the <code>outs</code> of some other rule, this rule
will automatically depend on that other rule.
</p>
<p>A <code>.h</code> file will not be compiled, but will be available for
inclusion by sources in this rule. Both <code>.cc</code> and
<code>.h</code> files can directly include headers listed in
these <code>srcs</code> or in the <code>hdrs</code> of any rule listed in
the <code>deps</code> argument.
</p>
<p>All <code>#include</code>d files must be mentioned in the
<code>srcs</code> attribute of this rule, or in the
<code>hdrs</code> attribute of referenced <code>cc_library()</code>s.
The recommended style is for headers associated with a library to be
listed in that library's <code>hdrs</code> attribute, and any remaining
headers associated with this rule's sources to be listed in
<code>srcs</code>. See <a href="#hdrs">"Header inclusion checking"</a>
for a more detailed description.
</p>
<p>If a rule's name is in the <code>srcs</code>,
then this rule automatically depends on that one.
If the named rule's <code>outs</code> are C or C++
source files, they are compiled into this rule;
if they are library files, they are linked in.
</p>
<p>
Permitted <code>srcs</code> file types:
</p>
<ul>
<li>C and C++ source files: <code>.c</code>, <code>.cc</code>, <code>.cpp</code>,
<code>.cxx</code>, <code>.c++</code>, <code>.C</code></li>
<li>C and C++ header files: <code>.h</code>, <code>.hh</code>, <code>.hpp</code>,
<code>.hxx</code>, <code>.inc</code>, <code>.inl</code>, <code>.H</code></li>
<li>Assembler with C preprocessor: <code>.S</code></li>
<li>Archive: <code>.a</code>, <code>.pic.a</code></li>
<li>"Always link" library: <code>.lo</code>, <code>.pic.lo</code></li>
<li>Shared library, versioned or unversioned: <code>.so</code>,
<code>.so.<i>version</i></code></li>
<li>Object file: <code>.o</code>, <code>.pic.o</code></li>
</ul>
<p>
...and any rules that produce those files.
Different extensions denote different programming languages in
accordance with gcc convention.
</p>
</td>
</tr>
<tr>
<td id="cc_library.hdrs">
<code>hdrs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of header files published by
this library to be directly included by sources in dependent rules.
<p>This is the strongly preferred location for declaring header files that
describe the interface for the library. These headers will be made
available for inclusion by sources in this rule or in dependent rules.
Headers not meant to be included by a client of this library should be
listed in the <code>srcs</code> attribute instead, even if they are
included by a published header. See <a href="#hdrs">"Header inclusion
checking"</a> for a more detailed description. </p>
</td>
</tr>
<tr>
<td id="cc_library.alwayslink">
<code>alwayslink</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
If 1, any binary that depends (directly or indirectly) on this C++
library will link in all the object files for the files listed in
<code>srcs</code>, even if some contain no symbols referenced by the binary.
This is useful if your code isn't explicitly called by code in
the binary, e.g., if your code registers to receive some callback
provided by some service.
<p>If alwayslink doesn't work with VS 2017 on Windows, that is due to a
<a href="https://github.com/bazelbuild/bazel/issues/3949">known issue</a>,
please upgrade your VS 2017 to the latest version.</p>
</td>
</tr>
<tr>
<td id="cc_library.copts">
<code>copts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these options to the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
<p>
Each string in this attribute is added in the given order to <code>COPTS</code> before
compiling the binary target. The flags take effect only for compiling this target, not
its dependencies, so be careful about header files included elsewhere. All paths should
be relative to the workspace, not to the current package.
</p>
<p>
If the package declares the <a href="/versions/6.2.0/reference/be/functions.html#package.features">feature</a>
<code>no_copts_tokenization</code>, Bourne shell tokenization applies only to strings
that consist of a single "Make" variable.
</p>
</td>
</tr>
<tr>
<td id="cc_library.defines">
<code>defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line to this target,
as well as to every rule that depends on it. Be very careful, since this may have
far-reaching effects. When in doubt, add define values to
<a href="#cc_binary.local_defines"><code>local_defines</code></a> instead.
</td>
</tr>
<tr>
<td id="cc_library.implementation_deps">
<code>implementation_deps</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of other libraries that the library target depends on. Unlike with
<code>deps</code>, the headers and include paths of these libraries (and all their
transitive deps) are only used for compilation of this library, and not libraries that
depend on it. Libraries specified with <code>implementation_deps</code> are still linked in
binary targets that depend on this library.
<p>For now usage is limited to cc_libraries and guarded by the flag
<code>--experimental_cc_implementation_deps</code>.</p>
</td>
</tr>
<tr>
<td id="cc_library.include_prefix">
<code>include_prefix</code>
</td>
<td>
<p><code>String; optional</code></p>
The prefix to add to the paths of the headers of this rule.
<p>When set, the headers in the <code>hdrs</code> attribute of this rule are accessible
at is the value of this attribute prepended to their repository-relative path.
<p>The prefix in the <code>strip_include_prefix</code> attribute is removed before this
prefix is added.
</td>
</tr>
<tr>
<td id="cc_library.includes">
<code>includes</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of include dirs to be added to the compile line.
<p>
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution.
Each string is prepended with <code>-isystem</code> and added to <code>COPTS</code>.
Unlike <a href="#cc_binary.copts">COPTS</a>, these flags are added for this rule
and every rule that depends on it. (Note: not the rules it depends upon!) Be
very careful, since this may have far-reaching effects. When in doubt, add
"-I" flags to <a href="#cc_binary.copts">COPTS</a> instead.
</p>
<p>
Headers must be added to srcs or hdrs, otherwise they will not be available to dependent
rules when compilation is sandboxed (the default).
</p>
</td>
</tr>
<tr>
<td id="cc_library.linkopts">
<code>linkopts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these flags to the C++ linker command.
Subject to <a href="make-variables.html">"Make" variable</a> substitution,
<a href="common-definitions.html#sh-tokenization">
Bourne shell tokenization</a> and
<a href="common-definitions.html#label-expansion">label expansion</a>.
Each string in this attribute is added to <code>LINKOPTS</code> before
linking the binary target.
<p>
Each element of this list that does not start with <code>$</code> or <code>-</code> is
assumed to be the label of a target in <code>deps</code>. The
list of files generated by that target is appended to the linker
options. An error is reported if the label is invalid, or is
not declared in <code>deps</code>.
</p>
</td>
</tr>
<tr>
<td id="cc_library.linkstamp">
<code>linkstamp</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Simultaneously compiles and links the specified C++ source file into the final
binary. This trickery is required to introduce timestamp
information into binaries; if we compiled the source file to an
object file in the usual way, the timestamp would be incorrect.
A linkstamp compilation may not include any particular set of
compiler flags and so should not depend on any particular
header, compiler option, or other build variable.
<em class='harmful'>This option should only be needed in the
<code>base</code> package.</em>
</td>
</tr>
<tr>
<td id="cc_library.linkstatic">
<code>linkstatic</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
For <a href="/versions/6.2.0/reference/be/c-cpp.html#cc_binary"><code>cc_binary</code></a> and
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_test"><code>cc_test</code></a>: link the binary in static
mode. For <code>cc_library.linkstatic</code>: see below.
<p>
By default this option is on for <code>cc_binary</code> and off for the rest.
</p>
<p>
If enabled and this is a binary or test, this option tells the build tool to link in
<code>.a</code>'s instead of <code>.so</code>'s for user libraries whenever possible.
Some system libraries may still be linked dynamically, as are libraries for which
there is no static library. So the resulting executable will still be dynamically
linked, hence only <i>mostly</i> static.
</p>
<p>There are really three different ways to link an executable:</p>
<ul>
<li> STATIC with fully_static_link feature, in which everything is linked statically;
e.g. "<code>gcc -static foo.o libbar.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>fully_static_link</code> in the
<a href="/versions/6.2.0/reference/be/common-definitions#features"><code>features</code></a> attribute.</li>
<li> STATIC, in which all user libraries are linked statically (if a static
version is available), but where system libraries (excluding C/C++ runtime libraries)
are linked dynamically, e.g. "<code>gcc foo.o libfoo.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=True</code>.</li>
<li> DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is
available), e.g. "<code>gcc foo.o libfoo.so libbaz.so -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=False</code>.</li>
</ul>
<p>
The <code>linkstatic</code> attribute has a different meaning if used on a
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_library"><code>cc_library()</code></a> rule.
For a C++ library, <code>linkstatic=True</code> indicates that only
static linking is allowed, so no <code>.so</code> will be produced. linkstatic=False does
not prevent static libraries from being created. The attribute is meant to control the
creation of dynamic libraries.
</p>
<p>
If <code>linkstatic=False</code>, then the build tool will create symlinks to
depended-upon shared libraries in the <code>*.runfiles</code> area.
</p>
</td>
</tr>
<tr>
<td id="cc_library.local_defines">
<code>local_defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line for this target,
but not to its dependents.
</td>
</tr>
<tr>
<td id="cc_library.nocopts">
<code>nocopts</code>
</td>
<td>
<p><code>String; optional</code></p>
Remove matching options from the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution.
The value of this attribute is interpreted as a regular expression.
Any preexisting <code>COPTS</code> that match this regular expression
(including values explicitly specified in the rule's <a
href="#cc_binary.copts">copts</a> attribute) will be removed from
<code>COPTS</code> for purposes of compiling this rule.
This attribute should rarely be needed.
</td>
</tr>
<tr>
<td id="cc_library.strip_include_prefix">
<code>strip_include_prefix</code>
</td>
<td>
<p><code>String; optional</code></p>
The prefix to strip from the paths of the headers of this rule.
<p>When set, the headers in the <code>hdrs</code> attribute of this rule are accessible
at their path with this prefix cut off.
<p>If it's a relative path, it's taken as a package-relative one. If it's an absolute one,
it's understood as a repository-relative path.
<p>The prefix in the <code>include_prefix</code> attribute is added after this prefix is
stripped.
</td>
</tr>
<tr>
<td id="cc_library.textual_hdrs">
<code>textual_hdrs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of header files published by
this library to be textually included by sources in dependent rules.
<p>This is the location for declaring header files that cannot be compiled on their own;
that is, they always need to be textually included by other source files to build valid
code.</p>
</td>
</tr>
<tr>
<td id="cc_library.win_def_file">
<code>win_def_file</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
The Windows DEF file to be passed to linker.
<p>This attribute should only be used when Windows is the target platform.
It can be used to <a href="https://msdn.microsoft.com/en-us/library/d91k01sh.aspx">
export symbols</a> during linking a shared library.</p>
</td>
</tr>
</tbody>
</table>
<h2 id="cc_proto_library">
cc_proto_library
</h2>
<pre class="rule-signature">cc_proto_library(<a href="#cc_proto_library.name">name</a>, <a href="#cc_proto_library.deps">deps</a>, <a href="common-definitions.html#typical.data">data</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.exec_compatible_with">exec_compatible_with</a>, <a href="common-definitions.html#common.exec_properties">exec_properties</a>, <a href="common-definitions.html#common.features">features</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>
<code>cc_proto_library</code> generates C++ code from <code>.proto</code> files.
</p>
<p>
<code>deps</code> must point to <a href="protocol-buffer.html#proto_library"><code>proto_library
</code></a> rules.
</p>
<p>
Example:
</p>
<pre class="code">
cc_library(
name = "lib",
deps = [":foo_cc_proto"],
)
cc_proto_library(
name = "foo_cc_proto",
deps = [":foo_proto"],
)
proto_library(
name = "foo_proto",
)
</pre>
<h3 id="cc_proto_library_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_proto_library.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_proto_library.deps">
<code>deps</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of <a href="protocol-buffer.html#proto_library"><code>proto_library</code></a>
rules to generate C++ code for.
</td>
</tr>
</tbody>
</table>
<h2 id="fdo_prefetch_hints">
fdo_prefetch_hints
</h2>
<pre class="rule-signature">fdo_prefetch_hints(<a href="#fdo_prefetch_hints.name">name</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#fdo_prefetch_hints.profile">profile</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>Represents an FDO prefetch hints profile that is either in the workspace or at a specified
absolute path.
Examples:</p>
<pre class="code">
fdo_prefetch_hints(
name = "hints",
profile = "//path/to/hints:profile.afdo",
)
fdo_profile(
name = "hints_abs",
absolute_path_profile = "/absolute/path/profile.afdo",
)
</pre>
<h3 id="fdo_prefetch_hints_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="fdo_prefetch_hints.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="fdo_prefetch_hints.profile">
<code>profile</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Label of the hints profile. The hints file has the .afdo extension
The label can also point to an fdo_absolute_path_profile rule.
</td>
</tr>
</tbody>
</table>
<h2 id="fdo_profile">
fdo_profile
</h2>
<pre class="rule-signature">fdo_profile(<a href="#fdo_profile.name">name</a>, <a href="#fdo_profile.absolute_path_profile">absolute_path_profile</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#fdo_profile.profile">profile</a>, <a href="#fdo_profile.proto_profile">proto_profile</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>Represents an FDO profile that is either in the workspace or at a specified absolute path.
Examples:</p>
<pre class="code">
fdo_profile(
name = "fdo",
profile = "//path/to/fdo:profile.zip",
)
fdo_profile(
name = "fdo_abs",
absolute_path_profile = "/absolute/path/profile.zip",
)
</pre>
<h3 id="fdo_profile_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="fdo_profile.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="fdo_profile.absolute_path_profile">
<code>absolute_path_profile</code>
</td>
<td>
<p><code>String; optional</code></p>
Absolute path to the FDO profile. The FDO file can have one of the following extensions:
.profraw for unindexed LLVM profile, .profdata for indexed LLVM profile, .zip
that holds an LLVM profraw profile, or .afdo for AutoFDO profile.
</td>
</tr>
<tr>
<td id="fdo_profile.profile">
<code>profile</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Label of the FDO profile or a rule which generates it. The FDO file can have one of the
following extensions: .profraw for unindexed LLVM profile, .profdata for indexed LLVM
profile, .zip that holds an LLVM profraw profile, .afdo for AutoFDO profile, .xfdo for
XBinary profile. The label can also point to an fdo_absolute_path_profile rule.
</td>
</tr>
<tr>
<td id="fdo_profile.proto_profile">
<code>proto_profile</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Label of the protobuf profile.
</td>
</tr>
</tbody>
</table>
<h2 id="propeller_optimize">
propeller_optimize
</h2>
<pre class="rule-signature">propeller_optimize(<a href="#propeller_optimize.name">name</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="#propeller_optimize.ld_profile">ld_profile</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>Represents a Propeller optimization profile in the workspace.
Example:</p>
<pre class="code">
propeller_optimize(
name = "layout",
cc_profile = "//path:cc_profile.txt",
ld_profile = "//path:ld_profile.txt"
)
propeller_optimize(
name = "layout_absolute",
absolute_cc_profile = "/absolute/cc_profile.txt",
absolute_ld_profile = "/absolute/ld_profile.txt"
)
</pre>
<h3 id="propeller_optimize_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="propeller_optimize.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="propeller_optimize.ld_profile">
<code>ld_profile</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Label of the profile passed to the link action. This file has
the .txt extension.
</td>
</tr>
</tbody>
</table>
<h2 id="cc_test">
cc_test
</h2>
<pre class="rule-signature">cc_test(<a href="#cc_test.name">name</a>, <a href="#cc_test.deps">deps</a>, <a href="#cc_test.srcs">srcs</a>, <a href="common-definitions.html#typical.data">data</a>, <a href="#cc_test.additional_linker_inputs">additional_linker_inputs</a>, <a href="common-definitions.html#test.args">args</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="#cc_test.copts">copts</a>, <a href="#cc_test.defines">defines</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#test.env">env</a>, <a href="common-definitions.html#test.env_inherit">env_inherit</a>, <a href="common-definitions.html#common.exec_compatible_with">exec_compatible_with</a>, <a href="common-definitions.html#common.exec_properties">exec_properties</a>, <a href="common-definitions.html#common.features">features</a>, <a href="common-definitions.html#test.flaky">flaky</a>, <a href="#cc_test.includes">includes</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#cc_test.linkopts">linkopts</a>, <a href="#cc_test.linkstatic">linkstatic</a>, <a href="common-definitions.html#test.local">local</a>, <a href="#cc_test.local_defines">local_defines</a>, <a href="#cc_test.malloc">malloc</a>, <a href="#cc_test.nocopts">nocopts</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#test.shard_count">shard_count</a>, <a href="common-definitions.html#test.size">size</a>, <a href="#cc_test.stamp">stamp</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="common-definitions.html#test.timeout">timeout</a>, <a href="common-definitions.html#common.toolchains">toolchains</a>, <a href="common-definitions.html#common.visibility">visibility</a>, <a href="#cc_test.win_def_file">win_def_file</a>)</pre>
<h3 id="cc_test_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_test.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_test.deps">
<code>deps</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of other libraries to be linked in to the binary target.
<p>These can be <code>cc_library</code> or <code>objc_library</code>
targets.</p>
</td>
</tr>
<tr>
<td id="cc_test.srcs">
<code>srcs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
The list of C and C++ files that are processed to create the target.
These are C/C++ source and header files, either non-generated (normal source
code) or generated.
<p>All <code>.cc</code>, <code>.c</code>, and <code>.cpp</code> files will
be compiled. These might be generated files: if a named file is in
the <code>outs</code> of some other rule, this rule
will automatically depend on that other rule.
</p>
<p>A <code>.h</code> file will not be compiled, but will be available for
inclusion by sources in this rule. Both <code>.cc</code> and
<code>.h</code> files can directly include headers listed in
these <code>srcs</code> or in the <code>hdrs</code> of any rule listed in
the <code>deps</code> argument.
</p>
<p>All <code>#include</code>d files must be mentioned in the
<code>srcs</code> attribute of this rule, or in the
<code>hdrs</code> attribute of referenced <code>cc_library()</code>s.
The recommended style is for headers associated with a library to be
listed in that library's <code>hdrs</code> attribute, and any remaining
headers associated with this rule's sources to be listed in
<code>srcs</code>. See <a href="#hdrs">"Header inclusion checking"</a>
for a more detailed description.
</p>
<p>If a rule's name is in the <code>srcs</code>,
then this rule automatically depends on that one.
If the named rule's <code>outs</code> are C or C++
source files, they are compiled into this rule;
if they are library files, they are linked in.
</p>
<p>
Permitted <code>srcs</code> file types:
</p>
<ul>
<li>C and C++ source files: <code>.c</code>, <code>.cc</code>, <code>.cpp</code>,
<code>.cxx</code>, <code>.c++</code>, <code>.C</code></li>
<li>C and C++ header files: <code>.h</code>, <code>.hh</code>, <code>.hpp</code>,
<code>.hxx</code>, <code>.inc</code>, <code>.inl</code>, <code>.H</code></li>
<li>Assembler with C preprocessor: <code>.S</code></li>
<li>Archive: <code>.a</code>, <code>.pic.a</code></li>
<li>"Always link" library: <code>.lo</code>, <code>.pic.lo</code></li>
<li>Shared library, versioned or unversioned: <code>.so</code>,
<code>.so.<i>version</i></code></li>
<li>Object file: <code>.o</code>, <code>.pic.o</code></li>
</ul>
<p>
...and any rules that produce those files.
Different extensions denote different programming languages in
accordance with gcc convention.
</p>
</td>
</tr>
<tr>
<td id="cc_test.additional_linker_inputs">
<code>additional_linker_inputs</code>
</td>
<td>
<p><code>List of <a href="/versions/6.2.0/concepts/labels">labels</a>; optional</code></p>
Pass these files to the C++ linker command.
<p>
For example, compiled Windows .res files can be provided here to be embedded in
the binary target.
</p>
</td>
</tr>
<tr>
<td id="cc_test.copts">
<code>copts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these options to the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
<p>
Each string in this attribute is added in the given order to <code>COPTS</code> before
compiling the binary target. The flags take effect only for compiling this target, not
its dependencies, so be careful about header files included elsewhere. All paths should
be relative to the workspace, not to the current package.
</p>
<p>
If the package declares the <a href="/versions/6.2.0/reference/be/functions.html#package.features">feature</a>
<code>no_copts_tokenization</code>, Bourne shell tokenization applies only to strings
that consist of a single "Make" variable.
</p>
</td>
</tr>
<tr>
<td id="cc_test.defines">
<code>defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line to this target,
as well as to every rule that depends on it. Be very careful, since this may have
far-reaching effects. When in doubt, add define values to
<a href="#cc_binary.local_defines"><code>local_defines</code></a> instead.
</td>
</tr>
<tr>
<td id="cc_test.includes">
<code>includes</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of include dirs to be added to the compile line.
<p>
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make variable"</a> substitution.
Each string is prepended with <code>-isystem</code> and added to <code>COPTS</code>.
Unlike <a href="#cc_binary.copts">COPTS</a>, these flags are added for this rule
and every rule that depends on it. (Note: not the rules it depends upon!) Be
very careful, since this may have far-reaching effects. When in doubt, add
"-I" flags to <a href="#cc_binary.copts">COPTS</a> instead.
</p>
<p>
Headers must be added to srcs or hdrs, otherwise they will not be available to dependent
rules when compilation is sandboxed (the default).
</p>
</td>
</tr>
<tr>
<td id="cc_test.linkopts">
<code>linkopts</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
Add these flags to the C++ linker command.
Subject to <a href="make-variables.html">"Make" variable</a> substitution,
<a href="common-definitions.html#sh-tokenization">
Bourne shell tokenization</a> and
<a href="common-definitions.html#label-expansion">label expansion</a>.
Each string in this attribute is added to <code>LINKOPTS</code> before
linking the binary target.
<p>
Each element of this list that does not start with <code>$</code> or <code>-</code> is
assumed to be the label of a target in <code>deps</code>. The
list of files generated by that target is appended to the linker
options. An error is reported if the label is invalid, or is
not declared in <code>deps</code>.
</p>
</td>
</tr>
<tr>
<td id="cc_test.linkstatic">
<code>linkstatic</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
For <a href="/versions/6.2.0/reference/be/c-cpp.html#cc_binary"><code>cc_binary</code></a> and
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_test"><code>cc_test</code></a>: link the binary in static
mode. For <code>cc_library.linkstatic</code>: see below.
<p>
By default this option is on for <code>cc_binary</code> and off for the rest.
</p>
<p>
If enabled and this is a binary or test, this option tells the build tool to link in
<code>.a</code>'s instead of <code>.so</code>'s for user libraries whenever possible.
Some system libraries may still be linked dynamically, as are libraries for which
there is no static library. So the resulting executable will still be dynamically
linked, hence only <i>mostly</i> static.
</p>
<p>There are really three different ways to link an executable:</p>
<ul>
<li> STATIC with fully_static_link feature, in which everything is linked statically;
e.g. "<code>gcc -static foo.o libbar.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>fully_static_link</code> in the
<a href="/versions/6.2.0/reference/be/common-definitions#features"><code>features</code></a> attribute.</li>
<li> STATIC, in which all user libraries are linked statically (if a static
version is available), but where system libraries (excluding C/C++ runtime libraries)
are linked dynamically, e.g. "<code>gcc foo.o libfoo.a libbaz.a -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=True</code>.</li>
<li> DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is
available), e.g. "<code>gcc foo.o libfoo.so libbaz.so -lm</code>".<br/>
This mode is enabled by specifying <code>linkstatic=False</code>.</li>
</ul>
<p>
The <code>linkstatic</code> attribute has a different meaning if used on a
<a href="/versions/6.2.0/reference/be/c-cpp.html#cc_library"><code>cc_library()</code></a> rule.
For a C++ library, <code>linkstatic=True</code> indicates that only
static linking is allowed, so no <code>.so</code> will be produced. linkstatic=False does
not prevent static libraries from being created. The attribute is meant to control the
creation of dynamic libraries.
</p>
<p>
If <code>linkstatic=False</code>, then the build tool will create symlinks to
depended-upon shared libraries in the <code>*.runfiles</code> area.
</p>
</td>
</tr>
<tr>
<td id="cc_test.local_defines">
<code>local_defines</code>
</td>
<td>
<p><code>List of strings; optional</code></p>
List of defines to add to the compile line.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution and
<a href="/versions/6.2.0/reference/be/common-definitions#sh-tokenization">Bourne shell tokenization</a>.
Each string, which must consist of a single Bourne shell token,
is prepended with <code>-D</code> and added to the compile command line for this target,
but not to its dependents.
</td>
</tr>
<tr>
<td id="cc_test.malloc">
<code>malloc</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional; default is <code>@bazel_tools//tools/cpp:malloc</code></code></p>
Override the default dependency on malloc.
<p>
By default, C++ binaries are linked against <code>//tools/cpp:malloc</code>,
which is an empty library so the binary ends up using libc malloc.
This label must refer to a <code>cc_library</code>. If compilation is for a non-C++
rule, this option has no effect. The value of this attribute is ignored if
<code>linkshared=True</code> is specified.
</p>
</td>
</tr>
<tr>
<td id="cc_test.nocopts">
<code>nocopts</code>
</td>
<td>
<p><code>String; optional</code></p>
Remove matching options from the C++ compilation command.
Subject to <a href="/versions/6.2.0/reference/be/make-variables">"Make" variable</a> substitution.
The value of this attribute is interpreted as a regular expression.
Any preexisting <code>COPTS</code> that match this regular expression
(including values explicitly specified in the rule's <a
href="#cc_binary.copts">copts</a> attribute) will be removed from
<code>COPTS</code> for purposes of compiling this rule.
This attribute should rarely be needed.
</td>
</tr>
<tr>
<td id="cc_test.stamp">
<code>stamp</code>
</td>
<td>
<p><code>Integer; optional; default is 0</code></p>
Whether to encode build information into the binary. Possible values:
<ul>
<li>
<code>stamp = 1</code>: Always stamp the build information into the binary, even in
<a href="/versions/6.2.0/docs/user-manual#flag--stamp"><code>--nostamp</code></a> builds. <b>This
setting should be avoided</b>, since it potentially kills remote caching for the
binary and any downstream actions that depend on it.
</li>
<li>
<code>stamp = 0</code>: Always replace build information by constant values. This
gives good build result caching.
</li>
<li>
<code>stamp = -1</code>: Embedding of build information is controlled by the
<a href="/versions/6.2.0/docs/user-manual#flag--stamp"><code>--[no]stamp</code></a> flag.
</li>
</ul>
<p>Stamped binaries are <em>not</em> rebuilt unless their dependencies change.</p>
</td>
</tr>
<tr>
<td id="cc_test.win_def_file">
<code>win_def_file</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
The Windows DEF file to be passed to linker.
<p>This attribute should only be used when Windows is the target platform.
It can be used to <a href="https://msdn.microsoft.com/en-us/library/d91k01sh.aspx">
export symbols</a> during linking a shared library.</p>
</td>
</tr>
</tbody>
</table>
<h2 id="cc_toolchain">
cc_toolchain
</h2>
<pre class="rule-signature">cc_toolchain(<a href="#cc_toolchain.name">name</a>, <a href="#cc_toolchain.all_files">all_files</a>, <a href="#cc_toolchain.ar_files">ar_files</a>, <a href="#cc_toolchain.as_files">as_files</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="#cc_toolchain.compiler">compiler</a>, <a href="#cc_toolchain.compiler_files">compiler_files</a>, <a href="#cc_toolchain.compiler_files_without_includes">compiler_files_without_includes</a>, <a href="#cc_toolchain.coverage_files">coverage_files</a>, <a href="#cc_toolchain.cpu">cpu</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="#cc_toolchain.dwp_files">dwp_files</a>, <a href="#cc_toolchain.dynamic_runtime_lib">dynamic_runtime_lib</a>, <a href="#cc_toolchain.exec_transition_for_inputs">exec_transition_for_inputs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="#cc_toolchain.libc_top">libc_top</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="#cc_toolchain.linker_files">linker_files</a>, <a href="#cc_toolchain.module_map">module_map</a>, <a href="#cc_toolchain.objcopy_files">objcopy_files</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="#cc_toolchain.static_runtime_lib">static_runtime_lib</a>, <a href="#cc_toolchain.strip_files">strip_files</a>, <a href="#cc_toolchain.supports_header_parsing">supports_header_parsing</a>, <a href="#cc_toolchain.supports_param_files">supports_param_files</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="#cc_toolchain.toolchain_config">toolchain_config</a>, <a href="#cc_toolchain.toolchain_identifier">toolchain_identifier</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>Represents a C++ toolchain.</p>
<p>
This rule is responsible for:
<ul>
<li>
Collecting all artifacts needed for C++ actions to run. This is done by
attributes such as <code>all_files</code>, <code>compiler_files</code>,
<code>linker_files</code>, or other attributes ending with <code>_files</code>). These are
most commonly filegroups globbing all required files.
</li>
<li>
Generating correct command lines for C++ actions. This is done using
<code>CcToolchainConfigInfo</code> provider (details below).
</li>
</ul>
</p>
<p>
Use <code>toolchain_config</code> attribute to configure the C++ toolchain.
See also this
<a href="https://bazel.build/versions/6.2.0/docs/cc-toolchain-config-reference">
page
</a> for elaborate C++ toolchain configuration and toolchain selection documentation.
</p>
<p>
Use <code>tags = ["manual"]</code> in order to prevent toolchains from being built and configured
unnecessarily when invoking <code>bazel build //...</code>
</p>
<h3 id="cc_toolchain_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_toolchain.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.all_files">
<code>all_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts. These artifacts will be added as inputs to all
rules_cc related actions (with the exception of actions that are using more precise sets of
artifacts from attributes below). Bazel assumes that <code>all_files</code> is a superset
of all other artifact-providing attributes (e.g. linkstamp compilation needs both compile
and link files, so it takes <code>all_files</code>).
<p>
This is what <code>cc_toolchain.files</code> contains, and this is used by all Starlark
rules using C++ toolchain.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.ar_files">
<code>ar_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
<p>Collection of all cc_toolchain artifacts required for archiving actions.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.as_files">
<code>as_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
<p>Collection of all cc_toolchain artifacts required for assembly actions.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.compiler">
<code>compiler</code>
</td>
<td>
<p><code>String; optional; <a href="common-definitions.html#configurable-attributes">nonconfigurable</a></code></p>
Deprecated. Use <code>toolchain_identifier</code> attribute instead. It will be a noop
after
<a href="https://github.com/bazelbuild/bazel/issues/5380">
CROSSTOOL migration to Starlark
</a>, and will be removed by
<a href="https://github.com/bazelbuild/bazel/issues/7075">#7075</a>.
<p>When set, it will be used to perform crosstool_config.toolchain selection. It will take
precedence over --cpu Bazel option.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.compiler_files">
<code>compiler_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts required for compile actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.compiler_files_without_includes">
<code>compiler_files_without_includes</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Collection of all cc_toolchain artifacts required for compile actions in case when
input discovery is supported (currently Google-only).
</td>
</tr>
<tr>
<td id="cc_toolchain.coverage_files">
<code>coverage_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Collection of all cc_toolchain artifacts required for coverage actions. If not specified,
all_files are used.
</td>
</tr>
<tr>
<td id="cc_toolchain.cpu">
<code>cpu</code>
</td>
<td>
<p><code>String; optional; <a href="common-definitions.html#configurable-attributes">nonconfigurable</a></code></p>
Deprecated. Use toolchain_identifier attribute instead. It will be a noop after
<a href="https://github.com/bazelbuild/bazel/issues/5380">CROSSTOOL migration to Starlark
</a>, and will be removed by
<a href="https://github.com/bazelbuild/bazel/issues/7075">#7075</a>.
<p>When set, it will be used to perform crosstool_config.toolchain selection. It will take
precedence over --cpu Bazel option.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.dwp_files">
<code>dwp_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts required for dwp actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.dynamic_runtime_lib">
<code>dynamic_runtime_lib</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Dynamic library artifact for the C++ runtime library (e.g. libstdc++.so).
<p>This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking
dependencies dynamically.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.exec_transition_for_inputs">
<code>exec_transition_for_inputs</code>
</td>
<td>
<p><code>Boolean; optional; default is True</code></p>
Set to True to build all file inputs to cc_toolchain for the exec platform,
instead of having no transition (i.e. target platform by default).
</td>
</tr>
<tr>
<td id="cc_toolchain.libc_top">
<code>libc_top</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
A collection of artifacts for libc passed as inputs to compile/linking actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.linker_files">
<code>linker_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts required for linking actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.module_map">
<code>module_map</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Module map artifact to be used for modular builds.
</td>
</tr>
<tr>
<td id="cc_toolchain.objcopy_files">
<code>objcopy_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts required for objcopy actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.static_runtime_lib">
<code>static_runtime_lib</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; optional</code></p>
Static library artifact for the C++ runtime library (e.g. libstdc++.a).
<p>This will be used when 'static_link_cpp_runtimes' feature is enabled, and we're linking
dependencies statically.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain.strip_files">
<code>strip_files</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
Collection of all cc_toolchain artifacts required for strip actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.supports_header_parsing">
<code>supports_header_parsing</code>
</td>
<td>
<p><code>Boolean; optional; default is False</code></p>
Set to True when cc_toolchain supports header parsing actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.supports_param_files">
<code>supports_param_files</code>
</td>
<td>
<p><code>Boolean; optional; default is True</code></p>
Set to True when cc_toolchain supports using param files for linking actions.
</td>
</tr>
<tr>
<td id="cc_toolchain.toolchain_config">
<code>toolchain_config</code>
</td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels">Label</a>; required</code></p>
The label of the rule providing <code>cc_toolchain_config_info</code>.
</td>
</tr>
<tr>
<td id="cc_toolchain.toolchain_identifier">
<code>toolchain_identifier</code>
</td>
<td>
<p><code>String; optional; <a href="common-definitions.html#configurable-attributes">nonconfigurable</a></code></p>
The identifier used to match this cc_toolchain with the corresponding
crosstool_config.toolchain.
<p>
Until issue <a href="https://github.com/bazelbuild/bazel/issues/5380">#5380</a> is fixed
this is the recommended way of associating <code>cc_toolchain</code> with
<code>CROSSTOOL.toolchain</code>. It will be replaced by the <code>toolchain_config</code>
attribute (<a href="https://github.com/bazelbuild/bazel/issues/5380">#5380</a>).</p>
</td>
</tr>
</tbody>
</table>
<h2 id="cc_toolchain_suite">
cc_toolchain_suite
</h2>
<pre class="rule-signature">cc_toolchain_suite(<a href="#cc_toolchain_suite.name">name</a>, <a href="common-definitions.html#common.compatible_with">compatible_with</a>, <a href="common-definitions.html#common.deprecation">deprecation</a>, <a href="common-definitions.html#common.distribs">distribs</a>, <a href="common-definitions.html#common.features">features</a>, <a href="common-definitions.html#typical.licenses">licenses</a>, <a href="common-definitions.html#common.restricted_to">restricted_to</a>, <a href="common-definitions.html#common.tags">tags</a>, <a href="common-definitions.html#common.target_compatible_with">target_compatible_with</a>, <a href="common-definitions.html#common.testonly">testonly</a>, <a href="#cc_toolchain_suite.toolchains">toolchains</a>, <a href="common-definitions.html#common.visibility">visibility</a>)</pre>
<p>Represents a collections of C++ toolchains.</p>
<p>
This rule is responsible for:
<ul>
<li>Collecting all relevant C++ toolchains.</li>
<li>
Selecting one toolchain depending on <code>--cpu</code> and <code>--compiler</code> options
passed to Bazel.
</li>
</ul>
</p>
<p>
See also this
<a href="https://bazel.build/versions/6.2.0/docs/cc-toolchain-config-reference">
page
</a> for elaborate C++ toolchain configuration and toolchain selection documentation.
</p>
<h3 id="cc_toolchain_suite_args">Arguments</h3>
<table class="table table-condensed table-bordered table-params">
<colgroup>
<col class="col-param" />
<col class="param-description" />
</colgroup>
<thead>
<tr>
<th colspan="2">Attributes</th>
</tr>
</thead>
<tbody>
<tr>
<td id="cc_toolchain_suite.name"><code>name</code></td>
<td>
<p><code><a href="/versions/6.2.0/concepts/labels#target-names">Name</a>; required</code></p>
<p>A unique name for this target.</p>
</td>
</tr>
<tr>
<td id="cc_toolchain_suite.toolchains">
<code>toolchains</code>
</td>
<td>
<p><code>Dictionary mapping strings to <a href="/versions/6.2.0/concepts/labels">labels</a>; required; <a href="common-definitions.html#configurable-attributes">nonconfigurable</a></code></p>
A map from "&lt;cpu&gt;" or "&lt;cpu&gt;|&lt;compiler&gt;" strings to
a <code>cc_toolchain</code> label. "&lt;cpu&gt;" will be used when only <code>--cpu</code>
is passed to Bazel, and "&lt;cpu&gt;|&lt;compiler&gt;" will be used when both
<code>--cpu</code> and <code>--compiler</code> are passed to Bazel. Example:
<p>
<pre>
cc_toolchain_suite(
name = "toolchain",
toolchains = {
"piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
"piii": ":my_cc_toolchain_for_piii_using_default_compiler",
},
)
</pre>
</p>
</td>
</tr>
</tbody>
</table>
<!-- Generated footer -->
</body>
</html>