C / C++ 规则

规则

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• fdo_prefetch_hints
• fdo_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, 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	Name; required 此目标的唯一名称。
deps	List of labels; optional 要链接到二进制目标的其他库的列表。 这些可以是 cc_library 或 objc_library 目标。
srcs	List of labels; optional 为创建目标而处理的 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 惯例，不同的扩展名表示不同的编程语言。
additional_linker_inputs	List of labels; optional 将这些文件传递给 C++ 链接器命令。 例如，可在此处提供已编译的 Windows .res 文件，以将其嵌入二进制目标中。
copts	List of strings; optional 将这些选项添加到 C++ 编译命令。可以使用“Make 变量”替换和 Bourne shell 令牌化。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅在编译此目标时生效，而不会对其依赖项生效，因此要注意别处包含的头文件。所有路径都应该相对于工作区（而不是当前软件包）。 如果软件包声明功能 no_copts_tokenization，则 Bourne shell 令牌化仅适用于包含单个“Make”变量的字符串。
defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D，并添加到此目标以及依赖于它的每条规则的编译命令行中。请务必小心，因为这可能会造成深远的影响。如有疑问，请改为将定义值添加到 local_defines。
includes	List of strings; optional 要添加到编译行的 include dir 列表。 可使用“生成变量”替换值。 每个字符串都会以 -isystem 为前缀，并添加到 COPTS 中。与 COPTS 不同，这些标志是为此规则以及依赖于它的所有规则添加的。（注意：并非它所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如果您有疑问，请改为向 COPTS 添加“-I”标志。 必须将头文件添加到 src 或 hdrs，否则当编译被沙盒化（默认设置）时，这些头文件将不适用于相关规则。
linkopts	List of strings; optional 将这些标志添加到 C++ 链接器命令。 受限于“Make”变量替换、 Bourne shell 令牌化和标签扩展。 在链接二进制目标之前，此属性中的每个字符串都会添加到 LINKOPTS。 此列表中不以 $ 或 - 开头的每个元素都被假定为 deps 中目标的标签。该目标生成的文件列表会附加到链接器选项。如果标签无效，或未在 deps 中声明，则会报告错误。
linkshared	Boolean; optional; nonconfigurable; default is False 创建共享库。 如需启用此属性，请在您的规则中添加 linkshared=True。默认情况下，此选项处于关闭状态。 此标志的存在意味着通过 -shared 标志链接到 gcc，并且生成的共享库适合加载到 Java 程序等对象。不过，出于构建目的，它绝不会链接到相关的二进制文件，因为使用 cc_binary 规则构建的共享库只能由其他程序手动加载，因此不应将其视为 cc_library 规则的替代项。出于可伸缩性方面的考虑，我们建议完全不要使用此方法，而让 java_library 依赖于 cc_library 规则。 如果您同时指定 linkopts=['-static'] 和 linkshared=True，则会获得一个完全独立的单元。如果您同时指定 linkstatic=True 和 linkshared=True，则会得到一个基本上独立的单元。
linkstatic	Boolean; optional; default is True 对于 cc_binary 和 cc_test：在静态模式下链接二进制文件。对于 cc_library.linkstatic：请参阅下文。 默认情况下，系统会针对 cc_binary 启用此选项，针对其余各项停用此选项。 启用后，如果这是一个二进制文件或测试，此选项会指示构建工具尽可能关联 .a 的（而不是 .so 的）以进行用户库。 某些系统库可能仍然会动态关联，正如没有静态库的库一样。因此，生成的可执行文件仍将动态链接，因此基本上只有静态。 链接可执行文件的方法实际上有三种： 具有 full_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 可启用此模式。 在 cc_library() 规则中使用 linkstatic 属性时，其含义会有所不同。对于 C++ 库，linkstatic=True 表示仅允许静态链接，因此不会生成 .so。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。 如果为 linkstatic=False，构建工具将在 *.runfiles 区域创建指向依赖共享库的符号链接。
local_defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D 并添加到此目标的编译命令行中，但不会添加到其依赖性。
malloc	Label; optional; default is @bazel_tools//tools/cpp:malloc 替换 malloc 的默认依赖项。 默认情况下，C++ 二进制文件链接到 //tools/cpp:malloc，后者是一个空库，因此二进制文件最终会使用 libc malloc。 此标签必须引用 cc_library。如果编译是针对非 C++ 规则，则此选项无效。如果指定了 linkshared=True，系统将忽略此属性的值。
nocopts	String; optional 从 C++ 编译命令中移除匹配的选项。受“Make”变量替换的约束。 此属性的值会被解释为正则表达式。 为了编译此规则，所有已经存在的 COPTS（包括规则的 copts 属性中明确指定的值）都将从 COPTS 中移除。此属性应很少需要用到，
stamp	Integer; optional; default is -1 是否将 build 信息编码到二进制文件中。可能的值包括： stamp = 1：始终将 build 信息压印到二进制文件中，即使在 --nostamp build 中也是如此。应避免此设置，因为它可能会终止对该二进制文件的远程缓存以及依赖于该二进制文件的任何下游操作。 stamp = 0：始终用常量值替换 build 信息。这样可以提供良好的构建结果缓存。 stamp = -1：build 信息的嵌入由 --[no]stamp 标志控制。 带时间戳的二进制文件不会重新构建，除非其依赖项发生更改。
win_def_file	Label; optional 要传递给链接器的 Windows DEF 文件。 仅当 Windows 是目标平台时，才应使用此属性。 它可用于在关联共享库期间 导出符号。

cc_import

cc_import(name, 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 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",
)

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

参数

属性
name	Name; required 此目标的唯一名称。
hdrs	List of labels; optional 由此预编译库发布的、由源代码直接包含在相关规则中的头文件列表。
alwayslink	Boolean; optional; default is False 如果为 1，则（直接或间接）依赖于此 C++ 预编译库的任何二进制文件都将链接到在静态库归档的所有对象文件中，即使某些目标文件中不包含该二进制文件引用的符号也是如此。 如果二进制文件中的代码未明确调用您的代码（例如，您的代码注册以接收某个服务提供的某个回调），那么这会非常有用。 由于已知问题，如果始终链接在 Windows 上对 VS 2017 不起作用，请将 VS 2017 升级到最新版本。
interface_library	Label; optional 用于关联共享库的单个接口库。 允许的文件类型：.ifso、.tbd、.lib、.so 或 .dylib
shared_library	Label; optional 单个预编译共享库。Bazel 可确保它可供在运行时依赖它的二进制文件使用。 允许的文件类型：.so、.dll 或 .dylib
static_library	Label; optional 单个预编译的静态库。 允许的文件类型：.a、.pic.a 或 .lib
system_provided	Boolean; optional; default is False 如果为 1，则表示运行时所需的共享库由系统提供。在这种情况下，应指定 interface_library 且 shared_library 应为空。

cc_library

cc_library(name, deps, srcs, data, hdrs, 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 内的文件，以及从库其 deps 中列出库的 cc_* 规则的 hdrs 和 srcs 内的文件中添加。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 目前无法区分直接包含项和传递包含项，因此它无法检测到文件非法直接包含仅允许以传递方式包含的标头的错误情况。例如，在上面的示例中，如果 foo.cc 直接包含 baz.h，则 Bazel 不会发出错误消息。这样做是非法的，因为 foo 不直接依赖于 baz。目前，在这种情况下不会产生错误，但未来可能会添加此类错误检查。

参数

属性
name	Name; required 此目标的唯一名称。
deps	List of labels; optional 要链接到二进制目标的其他库的列表。 这些可以是 cc_library 或 objc_library 目标。
srcs	List of labels; optional 为创建目标而处理的 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	List of labels; optional 此库发布的、由来源直接包含在相关规则中的头文件的列表。 这是声明描述库接口的头文件的首选位置。这些标头将可供来源添加到此规则或相关规则中。不应由此库的客户端包含的标头应改为列在 srcs 属性中，即使它们包含在已发布的标头中也是如此。如需查看更详细的说明，请参阅“标头包含项检查”。
alwayslink	Boolean; optional; default is False 如果为 1，则（直接或间接）依赖于此 C++ 库的任何二进制文件都将链接到 srcs 中列出的文件的所有对象文件，即使某些文件不包含任何二进制文件引用的符号也是如此。 如果二进制文件中的代码未明确调用您的代码（例如，您的代码注册以接收某个服务提供的某个回调），那么这会非常有用。 由于已知问题，如果始终链接在 Windows 上对 VS 2017 不起作用，请将 VS 2017 升级到最新版本。
copts	List of strings; optional 将这些选项添加到 C++ 编译命令。可以使用“Make 变量”替换和 Bourne shell 令牌化。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅在编译此目标时生效，而不会对其依赖项生效，因此要注意别处包含的头文件。所有路径都应该相对于工作区（而不是当前软件包）。 如果软件包声明功能 no_copts_tokenization，则 Bourne shell 令牌化仅适用于包含单个“Make”变量的字符串。
defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D，并添加到此目标以及依赖于它的每条规则的编译命令行中。请务必小心，因为这可能会造成深远的影响。如有疑问，请改为将定义值添加到 local_defines。
implementation_deps	List of labels; optional 库目标所依赖的其他库的列表。与 deps 不同，这些库（及其所有传递依赖项）的头文件和 include 路径仅用于编译此库，而不用于编译依赖于此库的库。使用 implementation_deps 指定的库仍链接到依赖于此库的二进制目标中。 目前，只能在 cc_ libraries 中使用，并受 --experimental_cc_implementation_deps 标志保护。
include_prefix	String; optional 要添加到此规则的标头路径中的前缀。 设置后，此规则的 hdrs 属性中的标头可供访问，这是该属性的值，前置于其代码库相对路径。 在添加此前缀之前，系统会移除 strip_include_prefix 属性中的前缀。
includes	List of strings; optional 要添加到编译行的 include dir 列表。 可使用“生成变量”替换值。 每个字符串都会以 -isystem 为前缀，并添加到 COPTS 中。与 COPTS 不同，这些标志是为此规则以及依赖于它的所有规则添加的。（注意：并非它所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如果您有疑问，请改为向 COPTS 添加“-I”标志。 必须将头文件添加到 src 或 hdrs，否则当编译被沙盒化（默认设置）时，这些头文件将不适用于相关规则。
linkopts	List of strings; optional 将这些标志添加到 C++ 链接器命令。 受限于“Make”变量替换、 Bourne shell 令牌化和标签扩展。 在链接二进制目标之前，此属性中的每个字符串都会添加到 LINKOPTS。 此列表中不以 $ 或 - 开头的每个元素都被假定为 deps 中目标的标签。该目标生成的文件列表会附加到链接器选项。如果标签无效，或未在 deps 中声明，则会报告错误。
linkstamp	Label; optional 同时编译指定的 C++ 源文件并将其链接到最终二进制文件。需要这种技巧才能将时间戳信息引入二进制文件；如果我们按常规方式将源文件编译为对象文件，则时间戳就会不正确。Linkstamp 编译不得包含任何特定的编译器标记，因此不应依赖于任何特定头文件、编译器选项或其他构建变量。 只有 base 软件包中才需要此选项。
linkstatic	Boolean; optional; default is False 对于 cc_binary 和 cc_test：在静态模式下链接二进制文件。对于 cc_library.linkstatic：请参阅下文。 默认情况下，系统会针对 cc_binary 启用此选项，针对其余各项停用此选项。 启用后，如果这是一个二进制文件或测试，此选项会指示构建工具尽可能关联 .a 的（而不是 .so 的）以进行用户库。 某些系统库可能仍然会动态关联，正如没有静态库的库一样。因此，生成的可执行文件仍将动态链接，因此基本上只有静态。 链接可执行文件的方法实际上有三种： 具有 full_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 可启用此模式。 在 cc_library() 规则中使用 linkstatic 属性时，其含义会有所不同。对于 C++ 库，linkstatic=True 表示仅允许静态链接，因此不会生成 .so。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。 如果为 linkstatic=False，构建工具将在 *.runfiles 区域创建指向依赖共享库的符号链接。
local_defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D 并添加到此目标的编译命令行中，但不会添加到其依赖性。
nocopts	String; optional 从 C++ 编译命令中移除匹配的选项。受“Make”变量替换的约束。 此属性的值会被解释为正则表达式。 为了编译此规则，所有已经存在的 COPTS（包括规则的 copts 属性中明确指定的值）都将从 COPTS 中移除。此属性应很少需要用到，
strip_include_prefix	String; optional 要从此规则的标头路径中移除的前缀。 设置后，此规则的 hdrs 属性中的标头可通过其路径访问，且此前缀会被截断。 如果它是相对路径，则视为相对于软件包的路径。如果为绝对路径，则将其视为代码库相对路径。 include_prefix 属性中的前缀是在去除此前缀之后添加的。
textual_hdrs	List of labels; optional 此库发布的、由来源在相关规则中以文本形式包含的头文件的列表。 此位置用于声明无法自行编译的头文件；也就是说，要编译有效代码，其他源文件始终需要以文本形式包含这些文件。
win_def_file	Label; optional 要传递给链接器的 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	Name; required 此目标的唯一名称。
deps	List of labels; optional 要为其生成 C++ 代码的 proto_library 规则列表。

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	Name; required 此目标的唯一名称。
profile	Label; optional 提示配置文件的标签。提示文件的扩展名为 .afdo。该标签还可以指向 fdo_absolute_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	Name; required 此目标的唯一名称。
absolute_path_profile	String; optional FDO 配置文件的绝对路径。FDO 文件只能采用 .afdo 扩展名。
profile	Label; optional FDO 配置文件的标签或生成该配置文件的规则。FDO 文件可以具有以下扩展名之一：.profraw（用于未编入索引的 LLVM 配置文件）、.profdata（用于已编入索引的 LLVM 配置文件）、.zip（包含 LLVM Profraw 配置文件）、.afdo（用于 AutoFDO 配置文件）、.xfdo（用于 XBinary 配置文件）。该标签还可以指向 fdo_absolute_path_profile 规则。
proto_profile	Label; optional protobuf 配置文件的标签。

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	Name; required 此目标的唯一名称。
ld_profile	Label; optional 传递到关联操作的配置文件的标签。此文件的扩展名为 .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, 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	Name; required 此目标的唯一名称。
deps	List of labels; optional 要链接到二进制目标的其他库的列表。 这些可以是 cc_library 或 objc_library 目标。
srcs	List of labels; optional 为创建目标而处理的 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 惯例，不同的扩展名表示不同的编程语言。
additional_linker_inputs	List of labels; optional 将这些文件传递给 C++ 链接器命令。 例如，可在此处提供已编译的 Windows .res 文件，以将其嵌入二进制目标中。
copts	List of strings; optional 将这些选项添加到 C++ 编译命令。可以使用“Make 变量”替换和 Bourne shell 令牌化。 在编译二进制目标之前，此属性中的每个字符串都会按给定顺序添加到 COPTS。这些标志仅在编译此目标时生效，而不会对其依赖项生效，因此要注意别处包含的头文件。所有路径都应该相对于工作区（而不是当前软件包）。 如果软件包声明功能 no_copts_tokenization，则 Bourne shell 令牌化仅适用于包含单个“Make”变量的字符串。
defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D，并添加到此目标以及依赖于它的每条规则的编译命令行中。请务必小心，因为这可能会造成深远的影响。如有疑问，请改为将定义值添加到 local_defines。
includes	List of strings; optional 要添加到编译行的 include dir 列表。 可使用“生成变量”替换值。 每个字符串都会以 -isystem 为前缀，并添加到 COPTS 中。与 COPTS 不同，这些标志是为此规则以及依赖于它的所有规则添加的。（注意：并非它所依赖的规则！）请务必小心，因为这可能会造成深远的影响。如果您有疑问，请改为向 COPTS 添加“-I”标志。 必须将头文件添加到 src 或 hdrs，否则当编译被沙盒化（默认设置）时，这些头文件将不适用于相关规则。
linkopts	List of strings; optional 将这些标志添加到 C++ 链接器命令。 受限于“Make”变量替换、 Bourne shell 令牌化和标签扩展。 在链接二进制目标之前，此属性中的每个字符串都会添加到 LINKOPTS。 此列表中不以 $ 或 - 开头的每个元素都被假定为 deps 中目标的标签。该目标生成的文件列表会附加到链接器选项。如果标签无效，或未在 deps 中声明，则会报告错误。
linkstatic	Boolean; optional; default is False 对于 cc_binary 和 cc_test：在静态模式下链接二进制文件。对于 cc_library.linkstatic：请参阅下文。 默认情况下，系统会针对 cc_binary 启用此选项，针对其余各项停用此选项。 启用后，如果这是一个二进制文件或测试，此选项会指示构建工具尽可能关联 .a 的（而不是 .so 的）以进行用户库。 某些系统库可能仍然会动态关联，正如没有静态库的库一样。因此，生成的可执行文件仍将动态链接，因此基本上只有静态。 链接可执行文件的方法实际上有三种： 具有 full_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 可启用此模式。 在 cc_library() 规则中使用 linkstatic 属性时，其含义会有所不同。对于 C++ 库，linkstatic=True 表示仅允许静态链接，因此不会生成 .so。linkstatic=False 不会阻止创建静态库。该属性用于控制动态库的创建。 如果为 linkstatic=False，构建工具将在 *.runfiles 区域创建指向依赖共享库的符号链接。
local_defines	List of strings; optional 要添加到编译行的定义的列表。 受“Make”变量替换和 Bourne shell 令牌化的约束。 每个字符串（必须由单个 Bourne shell 令牌组成）都会添加前缀 -D 并添加到此目标的编译命令行中，但不会添加到其依赖性。
malloc	Label; optional; default is @bazel_tools//tools/cpp:malloc 替换 malloc 的默认依赖项。 默认情况下，C++ 二进制文件链接到 //tools/cpp:malloc，后者是一个空库，因此二进制文件最终会使用 libc malloc。 此标签必须引用 cc_library。如果编译是针对非 C++ 规则，则此选项无效。如果指定了 linkshared=True，系统将忽略此属性的值。
nocopts	String; optional 从 C++ 编译命令中移除匹配的选项。受“Make”变量替换的约束。 此属性的值会被解释为正则表达式。 为了编译此规则，所有已经存在的 COPTS（包括规则的 copts 属性中明确指定的值）都将从 COPTS 中移除。此属性应很少需要用到，
stamp	Integer; optional; default is 0 是否将 build 信息编码到二进制文件中。可能的值包括： stamp = 1：始终将 build 信息压印到二进制文件中，即使在 --nostamp build 中也是如此。应避免此设置，因为它可能会终止对该二进制文件的远程缓存以及依赖于该二进制文件的任何下游操作。 stamp = 0：始终用常量值替换 build 信息。这样可以提供良好的构建结果缓存。 stamp = -1：build 信息的嵌入由 --[no]stamp 标志控制。 带时间戳的二进制文件不会重新构建，除非其依赖项发生更改。
win_def_file	Label; optional 要传递给链接器的 Windows DEF 文件。 仅当 Windows 是目标平台时，才应使用此属性。 它可用于在关联共享库期间 导出符号。

cc_toolchain

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, 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	Name; required 此目标的唯一名称。
all_files	Label; required 所有 cc_toolchain 工件的集合。这些工件将作为输入添加到所有与 rules_cc 相关的操作（使用下面属性中的更精确工件集的操作除外）。Bazel 假定 all_files 是所有其他提供工件的属性的超集（例如，linkstamp 编译同时需要编译和链接文件，因此它采用 all_files）。 这是 cc_toolchain.files 包含的内容，供所有使用 C++ 工具链的 Starlark 规则使用。
ar_files	Label; optional 归档操作所需的所有 cc_toolchain 工件的集合。
as_files	Label; optional 汇编操作所需的所有 cc_toolchain 工件的集合。
compiler	String; optional; nonconfigurable 已弃用。请改用 toolchain_identifier 属性。在 从 CROSSTOOL 迁移到 Starlark 后，它将成为空操作，并将于 #7075 之前移除。 设置后，它将用于执行 crosstool_config.toolchain 选择。此选项的优先级高于 --cpu Bazel 选项。
compiler_files	Label; required 编译操作所需的所有 cc_toolchain 工件的集合。
compiler_files_without_includes	Label; optional 在支持输入发现的情况下（目前仅适用于 Google）编译操作所需的所有 cc_toolchain 工件的集合。
coverage_files	Label; optional 覆盖率操作所需的所有 cc_toolchain 工件的集合。如果未指定，则系统会使用 all_files。
cpu	String; optional; nonconfigurable 已弃用。请改用 toolchain_identifier 属性。在 CROSSTOOL 迁移到 Starlark 后，它将成为空操作，并将于 #7075 之前移除。 设置后，它将用于执行 crosstool_config.toolchain 选择。此选项的优先级高于 --cpu Bazel 选项。
dwp_files	Label; required dwp 操作所需的所有 cc_toolchain 工件的集合。
dynamic_runtime_lib	Label; optional C++ 运行时库的动态库工件（例如 libstdc++.so）。 启用“static_link_cpp_runtimes”功能时将使用此变量，并且我们会动态关联依赖项。
exec_transition_for_inputs	Boolean; optional; default is True 设置为 True 可针对 exec 平台将所有文件输入编译到 cc_toolchain，而不是进行过渡（即默认为目标平台）。
libc_top	Label; optional 作为输入传递给编译/链接操作的 libc 的工件集合。
linker_files	Label; required 关联操作所需的所有 cc_toolchain 工件的集合。
module_map	Label; optional 要用于模块化 build 的模块映射工件。
objcopy_files	Label; required objcopy 操作所需的所有 cc_toolchain 工件的集合。
static_runtime_lib	Label; optional C++ 运行时库的静态库工件（例如 libstdc++.a）。 如果启用了“static_link_cpp_runtimes”功能，并且我们将静态链接依赖项，则会用到此变量。
strip_files	Label; required 剥离操作所需的所有 cc_toolchain 工件的集合。
supports_header_parsing	Boolean; optional; default is False 如果 cc_toolchain 支持标头解析操作，应将其设置为 True。
supports_param_files	Boolean; optional; default is True 如果 cc_toolchain 支持使用参数文件链接操作，应将其设置为 True。
toolchain_config	Label; required 提供 cc_toolchain_config_info 的规则的标签。
toolchain_identifier	String; optional; nonconfigurable 用于将此 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	Name; required 此目标的唯一名称。
toolchains	Dictionary mapping strings to labels; required; nonconfigurable 从“<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", }, )