C / C++ 规则

报告问题 查看源代码 每夜 build · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

规则

• 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 中列出的标头。 所有 #included 个文件都必须在 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 ...以及生成这些文件的任何规则。 不同的扩展表示不同的编程语言， 。
additional_linker_inputs	标签列表；默认值为 [] 将这些文件传递给 C++ 链接器命令。 例如，您可以在此处提供已编译的 Windows .res 文件，以便将其嵌入到二进制目标中。
copts	字符串列表；默认值为 [] 将这些选项添加到 C++ 编译命令中。 需遵循 "Make variable" 替换和 Bourne shell 令牌化。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅在编译此目标时有效，而不会在编译此目标时生效 因此请注意别处包含的头文件。所有路径都应相对于工作区，而不是相对于当前软件包。 如果该软件包声明了 feature， no_copts_tokenization，Bourne shell 标记化仅适用于字符串 其中包含一个“品牌”变量。
defines	字符串列表；默认值为 [] 要添加到编译行的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成， 前缀为 -D，并添加到编译命令行中， 以及依赖于该规则的每条规则请务必小心， 产生深远的影响。如果不确定，请改为向 local_defines 添加定义值。
includes	字符串列表；默认值为 [] 要添加到编译行的 include 目录列表。 需遵循“Make 变量”替换规则。 每个字符串都带有 -isystem 前缀，并添加到 COPTS 中。 与 COPTS 不同，系统会为此规则添加这些标记 以及依赖于它的每条规则（注意：并非其所依赖的规则！）是 必须格外小心，因为这可能会造成深远的影响。如果不确定，请改为向 COPTS 添加“-I”标志。 必须将头文件添加到 srcs 或 hdrs，否则在编译沙盒化（默认）时，依赖项规则将无法使用这些头文件。
link_extra_lib	标签；默认值为 "@bazel_tools//tools/cpp:link_extra_lib" 控制额外库的链接。 默认情况下，C++ 二进制文件会与 //tools/cpp:link_extra_lib 链接，而 //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）。 某些系统库可能仍会动态链接，没有静态库的库也是如此。因此生成的可执行文件仍会 处于关联状态，因此大部分都是静态的。 实际上，有三种不同的方式可以关联可执行文件： 具有 fully_static_link 功能的 STATIC，其中所有内容均以静态方式关联；例如“gcc -static foo.o libbar.a libbaz.a -lm”。 通过在 features 属性中指定 fully_static_link 即可启用此模式。 STATIC，其中所有用户库均以静态方式链接（如果 版本可用），但系统库（不包括 C/C++ 运行时库） 动态关联，例如“gcc foo.o libfoo.a libbaz.a -lm”。 通过指定 linkstatic=True 即可启用此模式。 DYNAMIC，其中所有库都将动态链接（如果有动态版本），例如“gcc foo.o libfoo.so libbaz.so -lm”。 通过指定 linkstatic=False 即可启用此模式。 如果将 linkstatic 属性用于 cc_library() 规则，其含义会有所不同。 对于 C++ 库，linkstatic=True 表示 允许使用静态链接，因此系统不会生成任何 .so。linkstatic=False 可以 不会阻止创建静态库。此属性用于控制动态库的创建。 如果为 linkstatic=False，则构建工具将在 *.runfiles 区域中创建指向依赖的共享库的符号链接。
local_defines	字符串列表；默认值为 [] 要添加到编译行中的定义列表。 受“品牌”的约束变量替换和 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++ 编译命令中移除匹配的选项。 受“品牌”的约束变量替换。 此属性的值会被解释为正则表达式。 与此正则表达式匹配的任何现有 COPTS （包括规则的 copts 属性中明确指定的值）将从 COPTS，以便编译此规则。 您应该很少需要此属性。
stamp	整数；默认为 -1 是否将 build 信息编码到二进制文件中。可能的值： stamp = 1：始终将 build 信息戳入二进制文件，即使在 --nostamp build 中也是如此。应避免使用此设置，因为它可能会终止二进制文件以及依赖于它的所有下游操作的远程缓存。 stamp = 0：始终用常量值替换 build 信息。这个 提供良好的构建结果缓存。 stamp = -1：--[no]stamp 标志用于控制 build 信息的嵌入。 除非其依赖项发生变化，否则带时间戳的二进制文件不会被重新构建。
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++ 的任何二进制文件 预编译的库会链接至静态库中归档的所有对象文件， 即使其中一些不包含二进制文件引用的符号，也是如此。 如果二进制文件中的代码未明确调用您的代码（例如，您的代码注册接收某些服务提供的回调），此方法会很有用。 如果 alwayslink 不适用于 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)

标头包含性检查

构建过程中使用的所有头文件都必须在 cc_* 规则的 hdrs 或 srcs 中声明。强制执行。

对于 cc_library 规则，hdrs 中的标头包含 库，并且可以直接包含在 hdrs 和 库本身的 srcs，以及 hdrs 和 cc_* 规则中的 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， 允许 turn 包含 baz-impl.h。从技术上讲 编译 .cc 文件可能会以传递方式包含任何头文件 文件放在 hdrs 或 srcs 传递 deps 闭包中的任何 cc_library。在 在这种情况下，编译器可能会读取 baz.h 和 baz-impl.h 编译 foo.cc 时，但 foo.cc 不得 包含“#include "baz.h"”。为此，必须将 baz 添加到 foo 的 deps。

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

参数

属性
name	姓名；必需 此目标的唯一名称。
deps	标签列表；默认值为 [] 要关联到二进制目标的其他库的列表。 这些值可以是 cc_library 或 objc_library 目标。
srcs	标签列表；默认值为 [] 用于创建目标而经过处理的 C 和 C++ 文件的列表。 这些是非生成的 C/C++ 源文件和头文件， 代码）。 系统会编译所有 .cc、.c 和 .cpp 文件。这些可能是生成的文件：如果某个命名文件位于某个其他规则的 outs 中，则此规则将自动依赖于该其他规则。 .h 文件不会进行编译，但可用于 按来源纳入此规则。.cc 和 .h 文件都可以直接包含这些 srcs 中列出的标头，也可以包含 deps 参数中列出的任何规则的 hdrs 中列出的标头。 所有 #included 文件都必须在本规则的 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	标签列表；默认值为 [] 您可能希望传递给编译器命令行的任何其他文件，例如沙盒过滤器列表。然后，您可以在 copts 中使用 $(location) 函数来使用此处指定的文件。
additional_linker_inputs	标签列表；默认值为 [] 将这些文件传递给 C++ 链接器命令。 例如，您可以在此处提供经过编译的 Windows .res 文件， 二进制目标。
alwayslink	布尔值；默认值为 False 如果为 1，则表示（直接或间接）依赖于此 C++ 的任何二进制文件 会链接至 srcs，即使其中一些不包含二进制文件引用的符号也是如此。 如果 二进制文件。例如，如果您的代码注册以接收一些回调 提供的数据 如果 alwayslink 无法用于 Windows 上的 VS 2017，原因在于 已知问题， 请将 VS 2017 升级到最新版本。
copts	字符串列表；默认值为 [] 将这些选项添加到 C++ 编译命令中。 会受到 “Make 变量”替换和 Bourne shell 令牌化的影响。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅对此目标的编译有效，而不会影响其依赖项，因此请注意其他位置包含的头文件。所有路径都应相对于工作区，而不是相对于当前软件包。 如果该软件包声明了 feature， no_copts_tokenization，Bourne shell 标记化仅适用于字符串 其中包含一个“品牌”变量。
defines	字符串列表；默认值为 [] 要添加到编译行的定义列表。 会受到 “Make”变量替换和 Bourne shell 令牌化的影响。 每个字符串都必须由单个 Bourne shell 令牌组成， 前缀为 -D，并添加到编译命令行中， 以及依赖于该规则的每条规则请务必谨慎，因为这可能会产生深远影响。如有疑问，请将定义值添加到 local_defines。
implementation_deps	标签列表；默认值为 [] 库目标依赖的其他库的列表。取消 deps，这些库（及其所有库）的头文件和 include 路径 传递依赖项）仅用于编译此库，而不会用于 一切都依赖于它使用 implementation_deps 指定的库仍会在依赖于此库的二进制目标中关联。 目前，此功能仅限于 cc_libraries，并由标志 --experimental_cc_implementation_deps 进行保护。
include_prefix	String;默认值为 "" 要添加到此规则标头的路径中的前缀。 设置后，此规则的 hdrs 属性中的标头可通过将此属性的值附加到其相对于代码库的路径来访问。 先移除 strip_include_prefix 属性中的前缀， 前缀。
includes	字符串列表；默认值为 [] 要添加到编译行的 include 目录列表。 需遵循“Make 变量”替换规则。 每个字符串都以 -isystem 开头，并添加到 COPTS。 与 COPTS 不同，系统会为此规则添加这些标记 以及依赖于它的所有规则（注意：并非其所依赖的规则！）是 必须格外小心，因为这可能会造成深远的影响。如果不确定，请改为向 COPTS 添加“-I”标志。 标头必须添加到 srcs 或 hdrs 中，否则它们将无法供从属使用 使用沙盒（默认）编译时应遵循的规则。
linkopts	字符串列表；默认值为 [] 将以下标志添加到 C++ 链接器命令。 会受到 “make”变量替换、Bourne shell 令牌化和标签展开的影响。 在此属性中的每个字符串都会在链接二进制目标之前添加到 LINKOPTS。 此列表中不以 $ 或 - 开头的每个元素都假定为 deps 中目标的标签。通过 该目标生成的文件的列表会附加到链接器 选项。如果标签无效或未在 deps 中声明，系统会报告错误。
linkstamp	标签；默认值为 None 将指定的 C++ 源文件同时编译并链接到最终二进制文件中。要引入时间戳，必须用这种伎俩 转换为二进制文件；如果我们将源文件编译为 对象文件，那么时间戳就会是错误的。 链接戳记编译不得包含任何 编译器标记，因此不应依赖于任何特定的 头文件、编译器选项或其他编译变量。 只有在 base 软件包。
linkstatic	布尔值；默认值为 False 适用于cc_binary和 cc_test：以静态方式关联二进制文件 模式。对于 cc_library.linkstatic：请参阅下文。 默认情况下，系统会为 cc_binary 启用此选项，为其余设备关闭此选项。 如果已启用，并且是二进制文件或测试文件，此选项将指示构建工具加入 尽可能为用户库使用 .a（而非 .so）。 某些系统库可能仍会动态链接，没有静态库的库也是如此。因此生成的可执行文件仍会 处于关联状态，因此大部分都是静态的。 关联可执行文件其实有三种不同的方法： 具有 fully_static_link 功能的 STATIC，其中所有内容均以静态方式关联；例如“gcc -static foo.o libbar.a libbaz.a -lm”。 通过在 features 属性中指定 fully_static_link 即可启用此模式。 STATIC，其中所有用户库均以静态方式链接（如果 版本可用），但系统库（不包括 C/C++ 运行时库） 动态关联，例如“gcc foo.o libfoo.a libbaz.a -lm”。 通过指定 linkstatic=True 即可启用此模式。 动态 - 所有库都动态关联（如果动态版本 可用），例如“gcc foo.o libfoo.so libbaz.so -lm”。 通过指定 linkstatic=False 即可启用此模式。 linkstatic 属性在用于 cc_library() 规则。 对于 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	标签列表；默认值为 [] proto_library 的列表 为其生成 C++ 代码的规则。

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 目标 。因此，它不属于deps cc_shared_library。如果此预编译动态库是某个 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），以决定在哪个cc_libraries 不应链接传递 deps，因为已提供 由另一位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	String;默认值为 "" 默认情况下，cc_shared_library 会根据目标的名称和平台为共享库输出文件使用名称。其中包括扩展名，有时还包括前缀。 有时您可能不需要默认名称，例如在加载 C++ 共享库时 对于 Python，通常不需要默认的 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_绝对_path_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 配置文件的文件，或者包含 AutoFDO 配置文件的 .afdo。
profile	标签；默认值为 None FDO 配置文件的标签或用于生成该配置文件的规则。FDO 文件可以包含 以下扩展名：.profraw 表示未编入索引的 LLVM 配置文件，.profdata 表示已编入索引的 LLVM 配置文件、包含 LLVM Profraw 配置文件的 .zip、用于 AutoFDO 配置文件的 .afdo、用于 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_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_绝对_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 中列出的标头。 所有 #included 个文件都必须在 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 ...以及生成这些文件的任何规则。 不同的扩展表示 。
additional_linker_inputs	标签列表；默认值为 [] 将这些文件传递给 C++ 链接器命令。 例如，您可以在此处提供已编译的 Windows .res 文件，以便将其嵌入到二进制目标中。
copts	字符串列表；默认值为 [] 将这些选项添加到 C++ 编译命令中。 需遵循 "Make variable" 替换和 Bourne shell 令牌化。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅对此目标的编译有效，而不会影响其依赖项，因此请注意其他位置包含的头文件。所有路径都应 相对于工作区，而不是当前软件包。 如果软件包声明了功能 no_copts_tokenization，Bourne shell 令牌化仅适用于由单个“Make”变量组成的字符串。
defines	字符串列表；默认值为 [] 要添加到编译行中的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成， 前缀为 -D，并添加到编译命令行中， 以及依赖于该规则的每条规则请务必小心， 产生深远的影响。如果不确定，请改为向 local_defines 添加定义值。
includes	字符串列表；默认值为 [] 要添加到编译行的 include 目录列表。 需遵循替换 "Make variable" 的规定。 每个字符串都以 -isystem 开头，并添加到 COPTS。 与 COPTS 不同，系统会为此规则添加这些标记 以及依赖于它的所有规则（注意：不是它依赖的规则！）请务必谨慎，因为这可能会产生深远影响。如果不确定，请改为向 COPTS 添加“-I”标志。 必须将标头添加到 srcs 或 hdrs 中，否则它们将无法供从属使用 使用沙盒（默认）编译时应遵循的规则。
link_extra_lib	标签；默认值为 "@bazel_tools//tools/cpp:link_extra_lib" 控制额外库的链接。 默认情况下，C++ 二进制文件会与 //tools/cpp:link_extra_lib 链接，而 //tools/cpp:link_extra_lib 默认依赖于标签标志 //tools/cpp:link_extra_libs。 如果未设置此标志，此库默认为空。设置标签标志后，您可以关联可选依赖项，例如弱符号的替换项、共享库函数的拦截器或特殊运行时库（对于 malloc 替换项，最好使用 malloc 或 --custom_malloc）。将此属性设置为 None 会停用此行为。
linkopts	字符串列表；默认值为 [] 将以下标志添加到 C++ 链接器命令。 受“品牌”的约束变量替换， Bourne shell 标记化 标签扩展。 在此属性中的每个字符串都会在链接二进制目标之前添加到 LINKOPTS。 此列表中将出现每个不以 $ 或 - 开头的元素 假定为 deps 中目标的标签。通过 该目标生成的文件的列表会附加到链接器 选项。如果标签无效，或者 未在 deps 中声明。
linkstatic	布尔值；默认值为 False 对于 cc_binary 和 cc_test：在静态模式下关联二进制文件。对于 cc_library.linkstatic：请参阅下文。 默认情况下，系统会为 cc_binary 启用此选项，为其余设备关闭此选项。 如果已启用，并且是二进制文件或测试文件，此选项将指示构建工具加入 尽可能为用户库使用 .a（而非 .so）。 某些系统库可能仍会动态链接，没有静态库的库也是如此。因此生成的可执行文件仍会 处于关联状态，因此大部分都是静态的。 实际上，有三种不同的方式可以关联可执行文件： 具有 fully_static_link 功能的 STATIC，其中所有内容均以静态方式关联；例如“gcc -static foo.o libbar.a libbaz.a -lm”。 通过在 features 属性中指定 fully_static_link 即可启用此模式。 STATIC，其中所有用户库均以静态方式链接（如果 版本可用），但系统库（不包括 C/C++ 运行时库） 动态关联，例如“gcc foo.o libfoo.a libbaz.a -lm”。 通过指定 linkstatic=True 即可启用此模式。 动态 - 所有库都动态关联（如果动态版本 可用），例如“gcc foo.o libfoo.so libbaz.so -lm”。 通过指定 linkstatic=False 即可启用此模式。 如果将 linkstatic 属性用于 cc_library() 规则，其含义会有所不同。 对于 C++ 库，linkstatic=True 表示 允许使用静态链接，因此系统不会生成任何 .so。linkstatic=False 可以 不会阻止创建静态库。此属性用于控制动态库的创建。 如果为 linkstatic=False，则构建工具将在 *.runfiles 区域中创建指向依赖的共享库的符号链接。
local_defines	字符串列表；默认值为 [] 要添加到编译行中的定义列表。 受“品牌”的约束变量替换和 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++ 编译命令中移除匹配的选项。 受“品牌”的约束变量替换。 此属性的值会被解释为正则表达式。 与此正则表达式匹配的任何现有 COPTS （包括规则的 copts 属性中明确指定的值）将从 COPTS，以便编译此规则。 您很少需要使用此属性。
stamp	Integer;默认值为 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 收集编译操作所需的所有 cc_toolchain 工件，以防支持输入发现（目前仅限 Google）。
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 支持使用 param 文件进行关联操作时，将其设置为 True。
toolchain_config	标签；必需 提供 cc_toolchain_config_info 的规则的标签。
toolchain_identifier	String;不可配置；默认值为 "" 用于将此 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	将字符串映射到 labels 的字典；不可配置；必需 将“<cpu>”或“<cpu>|<compiler>”字符串映射到 cc_toolchain 标签的映射。“<cpu>”只有 --cpu 时使用 会传递到 Bazel，并且“<cpu>|<compiler>”指定的两个条件 --cpu 和 --compiler 会传递给 Bazel。示例： cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )