此页面由 Cloud Translation API 翻译。

C / C++ 规则

规则

cc_binary
cc_import
cc_library
cc_proto_library
cc_shared_library
fdo_prefetch_hints
fdo_profile
memprof_profile
propeller_optimize
cc_test
cc_toolchain
cc_toolchain_suite

cc_binary

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

隐式输出目标

name.stripped（仅在明确请求时构建）：二进制文件的剥离版本。对二进制文件运行 strip -g 以移除调试符号。可以使用 --stripopt=-foo 在命令行中提供其他剥离选项。此输出仅在明确请求的情况下构建。
name.dwp（仅在明确请求时构建）：如果启用了 Fission：一个调试信息包文件，适用于调试远程部署的二进制文件。否则：一个空文件。

参数

属性
`name`	名称（必需）此目标的唯一名称。
`deps`	标签列表；默认值为 `[]` 要链接到二进制文件目标的其他库的列表。这些目标可以是 `cc_library` 或 `objc_library` 目标。
`srcs`	标签列表；默认值为 `[]` 为创建目标而处理的 C 和 C++ 文件的列表。这些是非生成的（常规源代码）或生成的 C/C++ 源文件和头文件。系统会编译所有 `.cc`、`.c` 和 `.cpp` 文件。这些可能是生成的文件：如果指定文件位于其他某条规则的 `outs` 中，则此规则将自动依赖于该规则。 `.h` 文件不会编译，但可供来源添加到此规则中。`.cc` 和 `.h` 文件都可以直接包含这些 `srcs` 或 `deps` 参数中列出的任何规则的 `hdrs` 中列出的标头。所有 `#include` 文件都必须在此规则的 `srcs` 属性中提及，或在所引用 `cc_library()` 的 `hdrs` 属性中提及。建议采用的样式是：与库相关联的头文件列在相应库的 `hdrs` 属性中，而与此规则的源关联的所有其余头文件均列在 `srcs` 中。如需查看详细说明，请参阅“标头包含项检查”。如果规则的名称位于 `srcs` 中，则此规则自动依赖于该名称。如果指定规则的 `outs` 是 C 或 C++ 源文件，它们会编译到此规则中；如果它们是库文件，则会链接到该规则。允许的 `srcs` 文件类型： C 和 C++ 源文件：`.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C 和 C++ 头文件：`.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` 使用 C 预处理器的汇编器：`.S` 归档：`.a`、`.pic.a` “始终链接”库：`.lo`、`.pic.lo` 已版本或未版本化的共享库：`.so`、`.so.version` 对象文件：`.o`、`.pic.o` ...以及生成这些文件的任何规则。根据 gcc 惯例，不同的扩展名表示不同的编程语言。
`additional_linker_inputs`	标签列表；默认值为 `[]` 将这些文件传递给 C++ 链接器命令。例如，您可以在此处提供已编译的 Windows .res 文件，以将其嵌入到二进制目标中。
`copts`	字符串列表；默认值为 `[]` 将这些选项添加到 C++ 编译命令中。取决于使用 "Make variable" 替换和 Bourne shell 令牌化。在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 `COPTS` 中。这些标志仅在编译此目标时有效，对其依赖项不起作用，因此请谨慎处理其他位置包含的头文件。所有路径都应该相对于工作区，而不是当前软件包。如果软件包声明 feature `no_copts_tokenization`，则 Bourne shell 令牌化仅适用于由单个“Make”变量组成的字符串。
`defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且会带有 `-D` 前缀，并会添加到此目标的编译命令行以及依赖于它的每条规则中。请务必小心，因为这可能会造成深远的影响。如果有疑问，请改为向 `local_defines` 添加定义值。
`includes`	字符串列表；默认值为 `[]` 要添加到编译行的 include 目录列表。需遵循替换 "Make variable" 的规定。每个字符串都带有 `-isystem` 前缀并添加到 `COPTS` 中。与 COPTS 不同，系统会为此规则以及依赖于它的每条规则添加这些标记。（注意：并非其所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如有疑问，请将“-I”标志添加到 COPTS。头文件必须添加到 srcs 或 hdrs，否则当编译采用沙盒机制（默认设置）时，从属规则将无法使用这些头文件。
`link_extra_lib`	标签；默认值为 `"@bazel_tools//tools/cpp:link_extra_lib"` 控制额外库的链接。默认情况下，C++ 二进制文件链接到 `//tools/cpp:link_extra_lib`，而默认情况下，后者依赖于标签标志 `//tools/cpp:link_extra_libs`。如果不设置此标记，此库默认为空。通过设置标签标志，您可以关联可选的依赖项，如弱符号替换、共享库函数的拦截器或特殊的运行时库（对于 malloc 替换，建议选择 `malloc` 或 `--custom_malloc`）。将此属性设置为 `None` 可停用此行为。
`linkopts`	字符串列表；默认值为 `[]` 将这些标志添加到 C++ 链接器命令中。受“Make”变量替换、 Bourne shell 令牌化和标签扩展的约束。此属性中的每个字符串都会在链接二进制目标之前添加到 `LINKOPTS` 中。此列表假定列表中每个不以 `$` 或 `-` 开头的元素都是 `deps` 中目标的标签。该目标生成的文件列表会附加到链接器选项中。如果标签无效或未在 `deps` 中声明，则会报告错误。
`linkshared`	布尔值；不可配置；默认值为 `False` 创建共享库。要启用此属性，请在您的规则中添加 `linkshared=True`。默认情况下，此选项处于关闭状态。如果存在此标志，则表示使用 `-shared` 标志链接到 `gcc`，并且生成的共享库适合加载到 Java 程序等程序中。不过，出于构建目的，该代码绝不会链接到依赖的二进制文件，因为系统会假定使用 cc_binary 规则构建的共享库仅由其他程序手动加载，因此不应将其视为 cc_library 规则的替代项。考虑到可伸缩性，我们建议完全避免此方法，改为让 `java_library` 依赖于 `cc_library` 规则。如果您同时指定 `linkopts=['-static']` 和 `linkshared=True`，则会获得一个完全独立的单元。如果您同时指定 `linkstatic=True` 和 `linkshared=True`，则会得到一个大多独立的单元。
`linkstatic`	布尔值；默认值为 `True` 对于 `cc_binary` 和 `cc_test`：在静态模式下关联二进制文件。对于 `cc_library.linkstatic`：请参阅下文。默认情况下，此选项会为 `cc_binary` 启用，并为其余功能关闭。如果启用，并且这是二进制文件或测试文件，则此选项会告知构建工具尽可能链接 `.a` 文件（而不是 `.so` 文件）。某些系统库仍可动态关联，就像没有静态库的库一样。因此，生成的可执行文件仍将保持动态关联，因此大多数情况下都是静态的。关联可执行文件其实有三种不同的方法：采用完全静态链接功能的 STATIC，其中所有内容均以静态方式链接；例如“`gcc -static foo.o libbar.a libbaz.a -lm`”。此模式可通过在 `features` 属性中指定 `fully_static_link` 启用。静态链接：所有用户库均静态链接（如果有静态版本），但系统库（不包括 C/C++ 运行时库）链接动态，例如“`gcc foo.o libfoo.a libbaz.a -lm`”。通过指定 `linkstatic=True` 即可启用此模式。动态 - 所有库都动态关联（如果有动态版本），例如“`gcc foo.o libfoo.so libbaz.so -lm`”。通过指定 `linkstatic=False` 即可启用此模式。如果用于 `cc_library()` 规则，`linkstatic` 属性具有不同的含义。对于 C++ 库，`linkstatic=True` 表示仅允许静态链接，因此不会生成任何 `.so`。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。如果为 `linkstatic=False`，构建工具将在 `*.runfiles` 区域中创建指向所依赖共享库的符号链接。
`local_defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且都会以 `-D` 作为前缀，并添加到此目标的编译命令行中，但不会添加到其依赖项中。
`malloc`	标签；默认值为 `"@bazel_tools//tools/cpp:malloc"` 替换 malloc 的默认依赖项。默认情况下，C++ 二进制文件链接到 `//tools/cpp:malloc`，这是一个空库，因此二进制文件最终会使用 libc malloc。此标签必须引用 `cc_library`。如果编译针对的是非 C++ 规则，则此选项不会产生任何影响。如果指定了 `linkshared=True`，此属性的值会被忽略。
`nocopts`	字符串；默认值为 `""` 从 C++ 编译命令中移除匹配选项。具体取决于替换“Make”变量。此属性的值会被解释为正则表达式。为了编译此规则，系统将从 `COPTS` 中移除与此正则表达式匹配的任何现有 `COPTS`（包括规则的 copts 属性中明确指定的值）。您应该很少需要此属性。
`stamp`	整数；默认值为 `-1` 是否将 build 信息编码到二进制文件中。可能的值包括： `stamp = 1`：始终将 build 信息标记到二进制文件中，即使在 `--nostamp` build 中也是如此。应避免使用此设置，因为它可能会终止二进制文件的远程缓存以及依赖于该文件的任何下游操作。 `stamp = 0`：始终用常量值替换 build 信息。这样可以提供良好的构建结果缓存。 `stamp = -1`：build 信息的嵌入由 `--[no]stamp` 标志控制。除非其依赖项发生变化，否则带时间戳的二进制文件不会被重新构建。
`win_def_file`	标签；默认值为 `None` 要传递给链接器的 Windows DEF 文件。仅当 Windows 是目标平台时，才应使用此属性。它可用于在关联共享库期间导出符号。

cc_import

查看规则来源

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

cc_import 规则允许用户导入预编译的 C/C++ 库。

以下是典型的用例：
1. 关联静态库

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,
)

2. 关联共享库 (Unix)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)

3. 将共享库与接口库相关联 (Windows)

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 will be available for runtime
  shared_library = "mylib.dll",
)

4. 使用 system_provided=True 关联共享库 (Windows)

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,
)

5. 链接到静态库或共享库
在 Unix 上：

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,
)

在 Windows 上：

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,
)

cc_import 支持 include 属性。例如：

  cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = [ "vendor/curl/include" ],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

参数

属性
`name`	名称（必需）此目标的唯一名称。
`deps`	标签列表；默认值为 `[]` 目标所依赖的其他库的列表。请参阅大多数构建规则定义的典型属性中有关 `deps` 的一般注释。
`hdrs`	标签列表；默认值为 `[]` 由此预编译库发布的将由源代码直接包含在依赖规则中的头文件列表。
`alwayslink`	布尔值；默认值为 `False` 如果为 1，则（直接或间接）依赖于此 C++ 预编译库的任何二进制文件都将链接到静态库中归档的所有对象文件中，即使某些文件不包含二进制文件引用的符号也是如此。如果您的代码没有被二进制文件中的代码明确调用（例如，您的代码注册以接收某项服务提供的某种回调），那么这种做法非常有用。如果由于已知问题而导致始终链接无法用于 Windows 上的 VS 2017，请将 VS 2017 升级到最新版本。
`interface_library`	标签；默认值为 `None` 用于关联共享库的单个接口库。允许的文件类型：`.ifso`、`.tbd`、`.lib`、`.so` 或 `.dylib`
`shared_library`	标签；默认值为 `None` 单个预编译的共享库。Bazel 可确保在运行时可供依赖于它的二进制文件使用。允许的文件类型：`.so`、`.dll` 或 `.dylib`
`static_library`	标签；默认值为 `None` 单个预编译的静态库。允许的文件类型：`.a`、`.pic.a` 或 `.lib`
`system_provided`	布尔值；默认值为 `False` 如果为 1，则表示运行时所需的共享库由系统提供。在这种情况下，应指定 `interface_library`，`shared_library` 应为空。

cc_library

查看规则来源

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

标头包含性检查

build 中使用的所有头文件必须在 cc_* 规则的 hdrs 或 srcs 中声明。系统会强制执行此要求。

对于 cc_library 规则，hdrs 中的头文件包含库的公共接口，可以直接从库本身的 hdrs 和 srcs 中的文件以及 cc_* 规则的 hdrs 和 srcs 的 srcs 中的文件（在 deps 中列出库）直接包含头文件。 srcs 中的头文件只能直接从库本身的 hdrs 和 srcs 内的文件中添加。在决定是将标头放入 hdrs 还是 srcs 时，您应该询问您是否希望此库的使用方能够直接包含该标头。这与编程语言中 public 到 private 可见性的决定大致相同。

cc_binary 和 cc_test 规则没有导出的接口，因此它们也不具有 hdrs 属性。所有属于二进制文件或直接测试的头文件都应在 srcs 中列出。

为了说明这些规则，请看以下示例。

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"],
)

下表列出了此示例中允许的直接包含项。例如，foo.cc 可以直接包含 foo.h 和 bar.h，但不能包含 baz.h。

包括文件	允许的包含项
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h，baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

包含项检查规则仅适用于直接包含项。在上面的示例中，foo.cc 可以包含 bar.h，其中可能包括 baz.h，而后者又可以包含 baz-impl.h。从技术上讲，编译 .cc 文件时，可能会传递性 deps 闭包内任何 cc_library 内的 hdrs 或 srcs 内包含的任何头文件。在这种情况下，编译器在编译 foo.cc 时可以读取 baz.h 和 baz-impl.h，但 foo.cc 不得包含 #include "baz.h"。若要允许该行为，必须将 baz 添加到 foo 的 deps 中。

Bazel 依赖于工具链支持来强制执行包含检查规则。layering_check 功能必须受到工具链支持，并且必须明确请求，例如通过 --features=layering_check 命令行标志或 package 函数的 features 参数进行请求。在 Unix 和 macOS 上，Bazel 提供的工具链仅支持通过 clang 使用此功能。

参数

属性
`name`	名称（必需）此目标的唯一名称。
`deps`	标签列表；默认值为 `[]` 要链接到二进制文件目标的其他库的列表。这些目标可以是 `cc_library` 或 `objc_library` 目标。
`srcs`	标签列表；默认值为 `[]` 为创建目标而处理的 C 和 C++ 文件的列表。这些是非生成的（常规源代码）或生成的 C/C++ 源文件和头文件。系统会编译所有 `.cc`、`.c` 和 `.cpp` 文件。这些可能是生成的文件：如果指定文件位于其他某条规则的 `outs` 中，则此规则将自动依赖于该规则。 `.h` 文件不会编译，但可供来源添加到此规则中。`.cc` 和 `.h` 文件都可以直接包含这些 `srcs` 或 `deps` 参数中列出的任何规则的 `hdrs` 中列出的标头。所有 `#include` 文件都必须在此规则的 `srcs` 属性中提及，或在所引用 `cc_library()` 的 `hdrs` 属性中提及。建议采用的样式是：与库相关联的头文件列在相应库的 `hdrs` 属性中，而与此规则的源关联的所有其余头文件均列在 `srcs` 中。如需查看详细说明，请参阅“标头包含项检查”。如果规则的名称位于 `srcs` 中，则此规则自动依赖于该名称。如果指定规则的 `outs` 是 C 或 C++ 源文件，它们会编译到此规则中；如果它们是库文件，则会链接到该规则。允许的 `srcs` 文件类型： C 和 C++ 源文件：`.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C 和 C++ 头文件：`.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` 使用 C 预处理器的汇编器：`.S` 归档：`.a`、`.pic.a` “始终链接”库：`.lo`、`.pic.lo` 已版本或未版本化的共享库：`.so`、`.so.version` 对象文件：`.o`、`.pic.o` ...以及生成这些文件的任何规则。根据 gcc 惯例，不同的扩展名表示不同的编程语言。
`hdrs`	标签列表；默认值为 `[]` 由此库发布的将由来源直接包含在依赖规则中的头文件列表。此位置是声明用于描述库接口的头文件的位置。这些标头将可供此规则或依赖规则中的来源包含。不应纳入此库的客户端的标头应改为列在 `srcs` 属性中，即使它们包含在已发布的标头中也是如此。如需查看详细说明，请参阅“标头包含检查”。
`additional_compiler_inputs`	标签列表；默认值为 `[]` 您可能希望传递给编译器命令行的任何其他文件，例如排错程序 ignorelist。然后，此处指定的文件即可在 copts 中通过 $(location) 函数使用。
`additional_linker_inputs`	标签列表；默认值为 `[]` 将这些文件传递给 C++ 链接器命令。例如，您可以在此处提供已编译的 Windows .res 文件，以将其嵌入到二进制目标中。
`alwayslink`	布尔值；默认值为 `False` 如果为 1，则（直接或间接）依赖此 C++ 库的任何二进制文件都将链接到 `srcs` 中列出的文件的所有对象文件中，即使其中某些文件不包含二进制文件引用的符号也是如此。如果您的代码没有被二进制文件中的代码明确调用（例如，您的代码注册以接收某项服务提供的某种回调），那么这种做法非常有用。如果由于已知问题而导致始终链接无法用于 Windows 上的 VS 2017，请将 VS 2017 升级到最新版本。
`copts`	字符串列表；默认值为 `[]` 将这些选项添加到 C++ 编译命令中。取决于使用 "Make variable" 替换和 Bourne shell 令牌化。在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 `COPTS` 中。这些标志仅在编译此目标时有效，对其依赖项不起作用，因此请谨慎处理其他位置包含的头文件。所有路径都应该相对于工作区，而不是当前软件包。如果软件包声明 feature `no_copts_tokenization`，则 Bourne shell 令牌化仅适用于由单个“Make”变量组成的字符串。
`defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且会带有 `-D` 前缀，并会添加到此目标的编译命令行以及依赖于它的每条规则中。请务必小心，因为这可能会造成深远的影响。如果有疑问，请改为向 `local_defines` 添加定义值。
`implementation_deps`	标签列表；默认值为 `[]` 库目标所依赖的其他库的列表。与 `deps` 不同，这些库（及其所有传递依赖项）的头文件和 include 路径仅用于此库的编译，而不用于依赖于此库的库。使用 `implementation_deps` 指定的库仍会在依赖于此库的二进制文件目标中链接。目前，此用法仅限于 cc_libraries，并通过 `--experimental_cc_implementation_deps` 标志进行保护。
`include_prefix`	字符串；默认值为 `""` 要添加到此规则标头的路径中的前缀。设置后，此规则的 `hdrs` 属性中的标头可通过此属性的值（加在代码库相对路径前面）访问。在添加此前缀之前，系统会先移除 `strip_include_prefix` 属性中的前缀。
`includes`	字符串列表；默认值为 `[]` 要添加到编译行的 include 目录列表。需遵循替换 "Make variable" 的规定。每个字符串都带有 `-isystem` 前缀并添加到 `COPTS` 中。与 COPTS 不同，系统会为此规则以及依赖于它的每条规则添加这些标记。（注意：并非其所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如有疑问，请将“-I”标志添加到 COPTS。头文件必须添加到 srcs 或 hdrs，否则当编译采用沙盒机制（默认设置）时，从属规则将无法使用这些头文件。
`linkopts`	字符串列表；默认值为 `[]` 将这些标志添加到 C++ 链接器命令中。受“Make”变量替换、 Bourne shell 令牌化和标签扩展的约束。此属性中的每个字符串都会在链接二进制目标之前添加到 `LINKOPTS` 中。此列表假定列表中每个不以 `$` 或 `-` 开头的元素都是 `deps` 中目标的标签。该目标生成的文件列表会附加到链接器选项中。如果标签无效或未在 `deps` 中声明，则会报告错误。
`linkstamp`	标签；默认值为 `None` 同时编译指定的 C++ 源文件并将其关联到最终二进制文件。要想将时间戳信息引入二进制文件，就必须使用这种伎俩；如果我们以常规方式将源文件编译到对象文件中，那么时间戳就会出错。 Linkstamp 编译可能不包含任何特定的编译器标志集，因此不应依赖于任何特定的头文件、编译器选项或其他构建变量。只有 `base` 软件包中才需要此选项。
`linkstatic`	布尔值；默认值为 `False` 对于 `cc_binary` 和 `cc_test`：在静态模式下关联二进制文件。对于 `cc_library.linkstatic`：请参阅下文。默认情况下，此选项会为 `cc_binary` 启用，并为其余功能关闭。如果启用，并且这是二进制文件或测试文件，则此选项会告知构建工具尽可能链接 `.a` 文件（而不是 `.so` 文件）。某些系统库仍可动态关联，就像没有静态库的库一样。因此，生成的可执行文件仍将保持动态关联，因此大多数情况下都是静态的。关联可执行文件其实有三种不同的方法：采用完全静态链接功能的 STATIC，其中所有内容均以静态方式链接；例如“`gcc -static foo.o libbar.a libbaz.a -lm`”。此模式可通过在 `features` 属性中指定 `fully_static_link` 启用。静态链接：所有用户库均静态链接（如果有静态版本），但系统库（不包括 C/C++ 运行时库）链接动态，例如“`gcc foo.o libfoo.a libbaz.a -lm`”。通过指定 `linkstatic=True` 即可启用此模式。动态 - 所有库都动态关联（如果有动态版本），例如“`gcc foo.o libfoo.so libbaz.so -lm`”。通过指定 `linkstatic=False` 即可启用此模式。如果用于 `cc_library()` 规则，`linkstatic` 属性具有不同的含义。对于 C++ 库，`linkstatic=True` 表示仅允许静态链接，因此不会生成任何 `.so`。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。如果为 `linkstatic=False`，构建工具将在 `*.runfiles` 区域中创建指向所依赖共享库的符号链接。
`local_defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且都会以 `-D` 作为前缀，并添加到此目标的编译命令行中，但不会添加到其依赖项中。
`nocopts`	字符串；默认值为 `""` 从 C++ 编译命令中移除匹配选项。具体取决于替换“Make”变量。此属性的值会被解释为正则表达式。为了编译此规则，系统将从 `COPTS` 中移除与此正则表达式匹配的任何现有 `COPTS`（包括规则的 copts 属性中明确指定的值）。您应该很少需要此属性。
`strip_include_prefix`	字符串；默认值为 `""` 要从此规则标头的路径中删除的前缀。设置后，此规则的 `hdrs` 属性中的标头可以在其路径上访问，并且此前缀被截断。如果是相对路径，则会被当作软件包相对路径。如果它是绝对路径，则会被理解为代码库相对路径。 `include_prefix` 属性中的前缀是在去除此前缀之后添加的。
`textual_hdrs`	标签列表；默认值为 `[]` 此库发布的头文件列表，将由来源以文本形式包含在依赖规则中。这是用于声明无法自行编译的头文件的位置；也就是说，它们始终需要由其他源文件以文本形式包含才能构建有效代码。
`win_def_file`	标签；默认值为 `None` 要传递给链接器的 Windows DEF 文件。仅当 Windows 是目标平台时，才应使用此属性。它可用于在关联共享库期间导出符号。

cc_proto_library

查看规则来源

cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

cc_proto_library 从 .proto 文件生成 C++ 代码。

deps 必须指向 proto_library 规则。

例如：

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

参数

属性

name

名称（必需）

此目标的唯一名称。

deps

标签列表；默认值为 []

要为其生成 C++ 代码的 proto_library 规则列表。

cc_shared_library

查看规则来源

cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

它会生成一个共享库。

示例

cc_shared_library(
    name = "foo_shared",
    deps = [
        ":foo",
    ],
    dynamic_deps = [
        ":bar_shared",
    ],
    additional_linker_inputs = [
        ":foo.lds",
    ],
    user_link_flags = [
        "-Wl,--version-script=$(location :foo.lds)",
    ],
)
cc_library(
    name = "foo",
    srcs = ["foo.cc"],
    hdrs = ["foo.h"],
    deps = [
        ":bar",
        ":baz",
    ],
)
cc_shared_library(
    name = "bar_shared",
    shared_lib_name = "bar.so",
    deps = [":bar"],
)
cc_library(
    name = "bar",
    srcs = ["bar.cc"],
    hdrs = ["bar.h"],
)
cc_library(
    name = "baz",
    srcs = ["baz.cc"],
    hdrs = ["baz.h"],
)

在该示例中，foo_shared 静态链接 foo 和 baz，后者是传递依赖项。它不关联 bar，因为它已由 dynamic_dep bar_shared 动态提供。

foo_shared 使用链接器脚本 *.lds 文件来控制应导出哪些符号。cc_shared_library 规则逻辑不控制要导出哪些符号，它仅使用假定要导出的内容，以便在分析阶段出现错误，前提是两个共享库导出相同的目标。

cc_shared_library 的每个直接依赖项都假定为导出。因此，Bazel 在分析期间假定 foo_shared 正在导出 foo。baz 不假定由 foo_shared 导出。与 exports_filter 匹配的每个目标也都假定被导出。

示例中的每个 cc_library 最多只能出现在一个 cc_shared_library 中。如果我们还想将 baz 也关联到 bar_shared，则需要将 tags = ["LINKABLE_MORE_THAN_ONCE"] 添加到 baz。

由于 shared_lib_name 属性，由 bar_shared 生成的文件的名称将为 bar.so，而不是其在 Linux 上默认使用的名称 libbar.so。

错误

`Two shared libraries in dependencies export the same symbols.`

每当您使用两个导出相同目标的不同 cc_shared_library 依赖项创建目标时，就会发生这种情况。如需解决此问题，您需要停止在某个 cc_shared_library 依赖项中导出库。

`Two shared libraries in dependencies link the same library statically`

每当您使用两个不同的 cc_shared_library 依赖项（以静态方式链接同一目标）创建新的 cc_shared_library 时，就会发生这种情况。类似于导出错误。

解决此问题的一种方法是停止将库关联到其中一个 cc_shared_library 依赖项。同时，仍然关联它的库需要导出库，以便未关联库的库可以保持符号的可见性。另一种方法是提取用于导出目标的第三个库。第三种方法是使用 LINKABLE_MORE_THAN_ONCE 标记导致问题的 cc_library，但这种修复应该很少见，您应该绝对确保 cc_library 确实可以安全地链接多次。

'//foo:foo' is already linked statically in '//bar:bar' but not exported`

这意味着，deps 的传递闭包中的库无需通过某个 cc_shared_library 依赖项即可访问，但已链接到 dynamic_deps 中的其他 cc_shared_library，并且不会导出。

解决方案是从 cc_shared_library 依赖项中导出该依赖项，或者提取用于导出该依赖项的第三个 cc_shared_library。

`Do not place libraries which only contain a precompiled dynamic library in deps.`

如果您有预编译的动态库，则无需执行此操作，也无法以静态方式链接到您当前正在创建的当前 cc_shared_library 目标。因此，它不属于 cc_shared_library 的 deps。如果此预编译动态库是某个 cc_libraries 的依赖项，则 cc_library 需要直接依赖于它。

`Trying to export a library already exported by a different shared library`

如果您要在当前规则中声明要导出一个已由某个动态依赖项导出的目标，则会看到此错误。

如需解决此问题，请从 deps 中移除目标，并且仅在动态依赖项中依赖它，或者确保 exports_filter 不会捕获此目标。

参数

属性
`name`	名称（必需）此目标的唯一名称。
`deps`	标签列表；默认值为 `[]` 完全归档后将无条件静态关联到共享库的顶级库。这些直接依赖项的任何传递库依赖项都将链接到此共享库，前提是它们尚未被 `dynamic_deps` 中的 `cc_shared_library` 关联。在分析期间，规则实现会将 `deps` 中列出的任何目标视为由共享库导出，以便在多个 `cc_shared_libraries` 导出相同的目标时报错。规则实现并不负责通知链接器应由共享对象导出哪些符号。用户应通过链接器脚本或源代码中的可见性声明来完成此操作。每当同一库以静态方式链接到多个 `cc_shared_library` 时，该实现也会触发错误。为避免发生这种情况，可以将 `"LINKABLE_MORE_THAN_ONCE"` 添加到 `cc_library.tags` 中，或将“cc_library”列为其中一个共享库的导出内容，以使其中一个共享库成为另一个共享库的 `dynamic_dep`。
`additional_linker_inputs`	标签列表；默认值为 `[]` 您可能想要传递给链接器的任何其他文件，例如链接器脚本。您必须单独传递链接器为知晓此文件而需要的所有链接器标记。您可以通过 `user_link_flags` 属性执行此操作。
`dynamic_deps`	标签列表；默认值为 `[]` 这些是当前目标所依赖的其他 `cc_shared_library` 依赖项。 `cc_shared_library` 实现将使用 `dynamic_deps` 列表（即，也是当前目标的 `dynamic_deps` 的 `dynamic_deps`）来确定不应关联传递 `deps` 中的哪个 `cc_libraries`，因为它们已由其他 `cc_shared_library` 提供。
`exports_filter`	字符串列表；默认值为 `[]` 此属性包含声称由当前共享库导出的目标列表。任何目标 `deps` 都已理解为由共享库导出。此属性应该用于列出共享库导出、但属于 `deps` 的传递依赖项的所有目标。请注意，此属性实际上并不会向这些目标添加依赖边缘，依赖边缘应由 `deps` 创建。此属性中的条目只是字符串。请注意，在此属性中放置目标时，系统会将此声明视为共享库从该目标导出符号的声明。`cc_shared_library` 逻辑实际上并不会负责告知链接器应导出哪些符号。允许使用以下语法： `//foo:__package__`，用于解释 foo/BUILD 中的任何目标 `//foo:__subpackages__`，用于解释 foo/BUILD 中的任何目标或 foo/ 下的任何其他软件包（例如 foo/bar/BUILD）
`shared_lib_name`	字符串；默认值为 `""` 默认情况下，cc_shared_library 将根据目标名称和平台使用共享库输出文件的名称。这包括扩展名，有时还包括前缀。有时您可能不需要默认名称，例如，在加载 Python 版 C++ 共享库时，通常不需要默认 lib* 前缀，在这种情况下，您可以使用此属性选择自定义名称。
`user_link_flags`	字符串列表；默认值为 `[]` 您可能想要传递给链接器的任何其他标志。例如，如需让链接器知晓通过 additional_linker_inputs 传递的链接器脚本，则可以使用以下代码： cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )
`win_def_file`	标签；默认值为 `None` 要传递给链接器的 Windows DEF 文件。仅当 Windows 是目标平台时，才应使用此属性。它可用于在关联共享库期间导出符号。

fdo_prefetch_hints

查看规则来源

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

表示工作区中或指定绝对路径中的 FDO 预提取提示配置文件。示例：

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

参数

属性

name

名称（必需）

此目标的唯一名称。

profile

标签；默认值为 None

提示分析的标签。提示文件的扩展名为 .afdo。该标签还可以指向 fdo_绝对路径_profile 规则。

fdo_profile

查看规则来源

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

表示工作区或指定绝对路径中的 FDO 配置文件。示例：

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

参数

属性
`name`	名称（必需）此目标的唯一名称。
`absolute_path_profile`	字符串；默认值为 `""` FDO 配置文件的绝对路径。FDO 文件可以使用以下扩展名之一：.profraw（表示未编入索引的 LLVM 配置文件）、.profdata（表示已编入索引的 LLVM 配置文件）、.zip（包含 LLVM Profraw 配置文件）或 .afdo（表示 AutoFDO 配置文件）。
`profile`	标签；默认值为 `None` FDO 配置文件的标签或生成该配置文件的规则。FDO 文件可以使用以下扩展名之一：.profraw（表示未编入索引的 LLVM 配置文件）、.profdata（表示已编入索引的 LLVM 配置文件）、.zip（包含 LLVM Profraw 配置文件）、.afdo 表示 AutoFDO 配置文件、.xfdo 表示 XBinary 配置文件。该标签还可以指向 fdo_absolute_path_profile 规则。
`proto_profile`	标签；默认值为 `None` protobuf 配置文件的标签。

memprof_profile

查看规则来源

memprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

表示工作区或指定绝对路径中的 MEMPROF 配置文件。示例：

memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

参数

属性

name

名称（必需）

此目标的唯一名称。

absolute_path_profile

字符串；默认值为 ""

MEMPROF 配置文件的绝对路径。该文件只能采用 .profdata 或 .zip 扩展名（其中 zip 文件必须包含 memprof.profdata 文件）。

profile

标签；默认值为 None

MEMPROF 配置文件的标签。该配置文件应具有 .profdata 扩展名（对于已编入索引/符号化的 memprof 配置文件），或 .zip 扩展名（对于包含 memprof.profdata 文件的 zip 文件）。该标签还可以指向 fdo_absolute_path_profile 规则。

propeller_optimize

查看规则来源

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

表示工作区中的 Propeller 优化配置文件。例如：

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"
)

参数

属性

name

名称（必需）

此目标的唯一名称。

ld_profile

标签；默认值为 None

传递给关联操作的个人资料的标签。此文件的扩展名是 .txt。

cc_test

查看规则来源

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, link_extra_lib, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

参数

属性
`name`	名称（必需）此目标的唯一名称。
`deps`	标签列表；默认值为 `[]` 要链接到二进制文件目标的其他库的列表。这些目标可以是 `cc_library` 或 `objc_library` 目标。
`srcs`	标签列表；默认值为 `[]` 为创建目标而处理的 C 和 C++ 文件的列表。这些是非生成的（常规源代码）或生成的 C/C++ 源文件和头文件。系统会编译所有 `.cc`、`.c` 和 `.cpp` 文件。这些可能是生成的文件：如果指定文件位于其他某条规则的 `outs` 中，则此规则将自动依赖于该规则。 `.h` 文件不会编译，但可供来源添加到此规则中。`.cc` 和 `.h` 文件都可以直接包含这些 `srcs` 或 `deps` 参数中列出的任何规则的 `hdrs` 中列出的标头。所有 `#include` 文件都必须在此规则的 `srcs` 属性中提及，或在所引用 `cc_library()` 的 `hdrs` 属性中提及。建议采用的样式是：与库相关联的头文件列在相应库的 `hdrs` 属性中，而与此规则的源关联的所有其余头文件均列在 `srcs` 中。如需查看详细说明，请参阅“标头包含项检查”。如果规则的名称位于 `srcs` 中，则此规则自动依赖于该名称。如果指定规则的 `outs` 是 C 或 C++ 源文件，它们会编译到此规则中；如果它们是库文件，则会链接到该规则。允许的 `srcs` 文件类型： C 和 C++ 源文件：`.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C 和 C++ 头文件：`.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` 使用 C 预处理器的汇编器：`.S` 归档：`.a`、`.pic.a` “始终链接”库：`.lo`、`.pic.lo` 已版本或未版本化的共享库：`.so`、`.so.version` 对象文件：`.o`、`.pic.o` ...以及生成这些文件的任何规则。根据 gcc 惯例，不同的扩展名表示不同的编程语言。
`additional_linker_inputs`	标签列表；默认值为 `[]` 将这些文件传递给 C++ 链接器命令。例如，您可以在此处提供已编译的 Windows .res 文件，以将其嵌入到二进制目标中。
`copts`	字符串列表；默认值为 `[]` 将这些选项添加到 C++ 编译命令中。取决于使用 "Make variable" 替换和 Bourne shell 令牌化。在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 `COPTS` 中。这些标志仅在编译此目标时有效，对其依赖项不起作用，因此请谨慎处理其他位置包含的头文件。所有路径都应该相对于工作区，而不是当前软件包。如果软件包声明 feature `no_copts_tokenization`，则 Bourne shell 令牌化仅适用于由单个“Make”变量组成的字符串。
`defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且会带有 `-D` 前缀，并会添加到此目标的编译命令行以及依赖于它的每条规则中。请务必小心，因为这可能会造成深远的影响。如果有疑问，请改为向 `local_defines` 添加定义值。
`includes`	字符串列表；默认值为 `[]` 要添加到编译行的 include 目录列表。需遵循替换 "Make variable" 的规定。每个字符串都带有 `-isystem` 前缀并添加到 `COPTS` 中。与 COPTS 不同，系统会为此规则以及依赖于它的每条规则添加这些标记。（注意：并非其所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如有疑问，请将“-I”标志添加到 COPTS。头文件必须添加到 srcs 或 hdrs，否则当编译采用沙盒机制（默认设置）时，从属规则将无法使用这些头文件。
`link_extra_lib`	标签；默认值为 `"@bazel_tools//tools/cpp:link_extra_lib"` 控制额外库的链接。默认情况下，C++ 二进制文件链接到 `//tools/cpp:link_extra_lib`，而默认情况下，后者依赖于标签标志 `//tools/cpp:link_extra_libs`。如果不设置此标记，此库默认为空。通过设置标签标志，您可以关联可选的依赖项，如弱符号替换、共享库函数的拦截器或特殊的运行时库（对于 malloc 替换，建议选择 `malloc` 或 `--custom_malloc`）。将此属性设置为 `None` 可停用此行为。
`linkopts`	字符串列表；默认值为 `[]` 将这些标志添加到 C++ 链接器命令中。受“Make”变量替换、 Bourne shell 令牌化和标签扩展的约束。此属性中的每个字符串都会在链接二进制目标之前添加到 `LINKOPTS` 中。此列表假定列表中每个不以 `$` 或 `-` 开头的元素都是 `deps` 中目标的标签。该目标生成的文件列表会附加到链接器选项中。如果标签无效或未在 `deps` 中声明，则会报告错误。
`linkstatic`	布尔值；默认值为 `False` 对于 `cc_binary` 和 `cc_test`：在静态模式下关联二进制文件。对于 `cc_library.linkstatic`：请参阅下文。默认情况下，此选项会为 `cc_binary` 启用，并为其余功能关闭。如果启用，并且这是二进制文件或测试文件，则此选项会告知构建工具尽可能链接 `.a` 文件（而不是 `.so` 文件）。某些系统库仍可动态关联，就像没有静态库的库一样。因此，生成的可执行文件仍将保持动态关联，因此大多数情况下都是静态的。关联可执行文件其实有三种不同的方法：采用完全静态链接功能的 STATIC，其中所有内容均以静态方式链接；例如“`gcc -static foo.o libbar.a libbaz.a -lm`”。此模式可通过在 `features` 属性中指定 `fully_static_link` 启用。静态链接：所有用户库均静态链接（如果有静态版本），但系统库（不包括 C/C++ 运行时库）链接动态，例如“`gcc foo.o libfoo.a libbaz.a -lm`”。通过指定 `linkstatic=True` 即可启用此模式。动态 - 所有库都动态关联（如果有动态版本），例如“`gcc foo.o libfoo.so libbaz.so -lm`”。通过指定 `linkstatic=False` 即可启用此模式。如果用于 `cc_library()` 规则，`linkstatic` 属性具有不同的含义。对于 C++ 库，`linkstatic=True` 表示仅允许静态链接，因此不会生成任何 `.so`。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。如果为 `linkstatic=False`，构建工具将在 `*.runfiles` 区域中创建指向所依赖共享库的符号链接。
`local_defines`	字符串列表；默认值为 `[]` 要添加到编译行的定义列表。取决于使用“Make”变量替换和 Bourne shell 令牌化的方式。每个字符串都必须包含单个 Bourne shell 令牌，并且都会以 `-D` 作为前缀，并添加到此目标的编译命令行中，但不会添加到其依赖项中。
`malloc`	标签；默认值为 `"@bazel_tools//tools/cpp:malloc"` 替换 malloc 的默认依赖项。默认情况下，C++ 二进制文件链接到 `//tools/cpp:malloc`，这是一个空库，因此二进制文件最终会使用 libc malloc。此标签必须引用 `cc_library`。如果编译针对的是非 C++ 规则，则此选项不会产生任何影响。如果指定了 `linkshared=True`，此属性的值会被忽略。
`nocopts`	字符串；默认值为 `""` 从 C++ 编译命令中移除匹配选项。具体取决于替换“Make”变量。此属性的值会被解释为正则表达式。为了编译此规则，系统将从 `COPTS` 中移除与此正则表达式匹配的任何现有 `COPTS`（包括规则的 copts 属性中明确指定的值）。您应该很少需要此属性。
`stamp`	整数；默认值为 `0` 是否将 build 信息编码到二进制文件中。可能的值包括： `stamp = 1`：始终将 build 信息标记到二进制文件中，即使在 `--nostamp` build 中也是如此。应避免使用此设置，因为它可能会终止二进制文件的远程缓存以及依赖于该文件的任何下游操作。 `stamp = 0`：始终用常量值替换 build 信息。这样可以提供良好的构建结果缓存。 `stamp = -1`：build 信息的嵌入由 `--[no]stamp` 标志控制。除非其依赖项发生变化，否则带时间戳的二进制文件不会被重新构建。
`win_def_file`	标签；默认值为 `None` 要传递给链接器的 Windows DEF 文件。仅当 Windows 是目标平台时，才应使用此属性。它可用于在关联共享库期间导出符号。

cc_toolchain

查看规则来源

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

表示 C++ 工具链。

该规则负责：

收集运行 C++ 操作所需的所有工件。这通过 all_files、compiler_files、linker_files 等属性或以 _files 结尾的其他属性完成。这些是最常见的文件组，用于传播所有必需的文件。
为 C++ 操作生成正确的命令行。这可通过 CcToolchainConfigInfo 提供程序完成（详情如下）。

使用 toolchain_config 属性配置 C++ 工具链。另请参阅此页面，查看详细的 C++ 工具链配置和工具链选择文档。

使用 tags = ["manual"] 可防止在调用 bazel build //... 时不必要地构建和配置工具链

参数

属性
`name`	名称（必需）此目标的唯一名称。
`all_files`	标签（必需）所有 cc_toolchain 工件的集合。这些工件将作为输入添加到所有与 rules_cc 相关的操作（使用下面属性中的更精确工件集的操作除外）。Bazel 假定 `all_files` 是所有其他提供工件的属性的超集（例如，linktamp 编译需要编译和链接文件，因此需要 `all_files`）。这是 `cc_toolchain.files` 包含的内容，使用 C++ 工具链的所有 Starlark 规则都会使用它。
`ar_files`	标签；默认值为 `None` 归档操作所需的所有 cc_toolchain 工件的集合。
`as_files`	标签；默认值为 `None` 组装操作所需的所有 cc_toolchain 工件的集合。
`compiler_files`	标签（必需）编译操作所需的所有 cc_toolchain 工件的集合。
`compiler_files_without_includes`	标签；默认值为 `None` 在支持输入发现（目前仅限 Google）的情况下，编译操作所需的所有 cc_toolchain 工件的集合。
`coverage_files`	标签；默认值为 `None` 覆盖率操作所需的所有 cc_toolchain 工件的集合。如果未指定，系统会使用 all_files。
`dwp_files`	标签（必需） dwp 操作所需的所有 cc_toolchain 工件的集合。
`dynamic_runtime_lib`	标签；默认值为 `None` C++ 运行时库的动态库工件（例如 libstdc++.so）。当“static_link_cpp_runtimes”功能处于启用状态，并且我们正在动态关联依赖项时，将使用此属性。
`exec_transition_for_inputs`	布尔值；默认值为 `True` 如果设置为 True，则针对 exec 平台，将所有文件输入构建到 cc_toolchain，而不是不进行转换（即默认情况下为目标平台）。
`libc_top`	标签；默认值为 `None` 作为输入传递给编译/链接操作的 libc 工件集合。
`linker_files`	标签（必需）关联操作所需的所有 cc_toolchain 工件的集合。
`module_map`	标签；默认值为 `None` 用于模块化 build 的模块映射工件。
`objcopy_files`	标签（必需） objcopy 操作所需的所有 cc_toolchain 工件的集合。
`static_runtime_lib`	标签；默认值为 `None` C++ 运行时库的静态库工件（例如 libstdc++.a）。当“static_link_cpp_runtimes”功能处于启用状态，并且我们以静态方式关联依赖项时，将使用此属性。
`strip_files`	标签（必需）剥离操作所需的所有 cc_toolchain 工件的集合。
`supports_header_parsing`	布尔值；默认值为 `False` 如果 cc_toolchain 支持标头解析操作，请将此项设为 True。
`supports_param_files`	布尔值；默认值为 `True` 如果 cc_toolchain 支持使用参数文件执行链接操作，请将此属性设为 True。
`toolchain_config`	标签（必需）提供 `cc_toolchain_config_info` 的规则的标签。
`toolchain_identifier`	字符串；不可配置；默认值为 `""` 用于将此 cc_toolchain 与相应的 crosstool_config.toolchain 匹配的标识符。在问题 #5380 得到解决之前，建议使用将 `cc_toolchain` 与 `CROSSTOOL.toolchain` 相关联的方法。它将被 `toolchain_config` 属性取代 (#5380)。

cc_toolchain_suite

查看规则来源

cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

表示 C++ 工具链的集合。

该规则负责：

收集所有相关的 C++ 工具链。
根据传递给 Bazel 的 --cpu 和 --compiler 选项选择一个工具链。

另请参阅此页面，查看详细的 C++ 工具链配置和工具链选择文档。

参数

属性

name

名称（必需）

此目标的唯一名称。

toolchains

将字符串映射到标签的字典；不可配置；必需

从“<cpu>”或“<cpu>|<compiler>”字符串到 cc_toolchain 标签的映射。当仅将 --cpu 传递给 Bazel 时，将使用“<cpu>”；当 --cpu 和 --compiler 都传递给 Bazel 时，将使用“<cpu>|<compiler>”。示例：

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )