C / C++ 规则

报告问题 查看源代码 敬上 每晚 · 7.3。 · 7.2。 · 7.1。 · 7.0。 · 6.5

规则

cc_binary

查看规则来源
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

它会生成一个可执行的二进制文件。


目标的 name 应与 作为应用主要入口点的源文件(去掉扩展名)。 例如,如果您的入口点是 main.cc,则您的姓名应 为 main

隐式输出目标

  • name.stripped(仅在明确请求时构建):剥离 二进制文件版本。对二进制文件运行 strip -g 以移除调试 符号。您可以使用以下命令在命令行中提供其他剥离选项: --stripopt=-foo
  • name.dwp(仅在明确请求时构建):如果 已启用 Fission:调试 信息包文件。否则: 空白文件。

参数

属性
name

姓名;必需

此目标的唯一名称。

deps

标签列表;默认值为 []

要链接到二进制文件目标的其他库的列表。

这些值可以是 cc_libraryobjc_library 目标。

还可以 将链接器脚本 (.lds) 放入依赖项,并在 linkopts
srcs

标签列表;默认值为 []

为创建库目标而处理的 C 和 C++ 文件的列表。 这些是非生成的 C/C++ 源文件和头文件, 代码)。

所有 .cc.c.cpp 文件都会 进行编译。这些文件可能是生成的文件:如果 一些其他规则的 outs,即此cc_library 都将自动依赖于那条规则

纯汇编程序文件(.s、.asm)不会进行预处理,并且通常使用 汇编程序预处理的汇编文件 (.S) 会经过预处理,并且通常是 使用 C/C++ 编译器编写代码。

.h 文件不会进行编译,但可用于 按来源纳入此规则。.cc.h 文件可以直接包含 这些srcs、此规则的hdrs或任何 deps 参数中列出的规则。

所有 #included 个文件都必须在 此或引用的 cc_libraryhdrs 属性 或者如果为私有规则,则应将其列在 srcs 中 添加到此库中。如需了解更多详情,请参阅“标头包含项检查”。 更加详细的说明

.so.lo.a 文件 预编译文件您的媒体库可能包含以下内容: 如果它使用我们不使用的第三方代码,则为 srcs 都没有源代码

如果 srcs 属性包含另一条规则的标签, cc_library 会将该规则的输出文件作为源文件,执行以下操作: 编译。这对于一次性生成源代码非常有用( 最好实现 Starlark 规则类并使用 cc_common API)

允许的 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

...以及生成这些文件的任何规则(例如 cc_embed_data)。 不同的扩展表示 。

data

标签列表;默认值为 []

此库在运行时所需的文件列表。 查看关于 data 的一般评论 大多数构建规则

如果 data 是生成文件的名称,则以下代码 cc_library规则会自动依赖于 规则。

如果 data 是规则名称,则 cc_library规则自动依赖于该规则 并且该规则的outs会自动添加到 此cc_library的数据文件。

您的 C++ 代码可以像这样访问这些数据文件:


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

标签列表;默认值为 []

将这些文件传递给 C++ 链接器命令。

例如,您可以在此处提供经过编译的 Windows .res 文件, 二进制目标。

copts

字符串列表;默认值为 []

将这些选项添加到 C++ 编译命令中。 需遵循 "Make variable" 替换和 Bourne shell 令牌化

此属性中的每个字符串都会按照指定顺序添加到 COPTS 中, 编译二进制目标的过程这些标志仅在编译此目标时有效,而不会在编译此目标时生效 因此请注意别处包含的头文件。 所有路径都应相对于工作区,而不是当前软件包。 third_party 之外不需要此属性。

如果该软件包声明了 featureno_copts_tokenization,Bourne shell 标记化仅适用于字符串 其中包含一个“品牌”变量。

defines

字符串列表;默认值为 []

要添加到编译行的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成, 前缀为 -D,并添加到编译命令行中, 以及依赖于该规则的每条规则请务必小心, 产生深远的影响。如有疑问,请将定义值添加到 local_defines
dynamic_deps

标签列表;默认值为 []

这些是当前目标所依赖的其他 cc_shared_library 依赖项。

cc_shared_library 实现将使用 dynamic_deps(传递性,即dynamic_deps 当前目标的dynamic_deps),以决定在哪个cc_libraries 不应链接传递 deps,因为已提供 由另一位cc_shared_library提供。

hdrs_check

String;默认值为 ""

已弃用,无运维。
includes

字符串列表;默认值为 []

要添加到编译行的 include 目录列表。 需遵循替换 "Make variable" 的规定。 每个字符串都以软件包路径为前缀,并传递到 C++ 工具链, 通过“include_paths”CROSSTOOL 功能。在 POSIX 系统上运行的工具链 将生成 -isystem path_to_package/include_entry。 它只能用于 不符合 Google 的 #include 语句写作风格。 与 COPTS 不同,系统会为此规则添加这些标记 以及依赖于它的所有规则(注意:并非其所依赖的规则!)是 必须格外小心,因为这可能会造成深远的影响。如有疑问,请添加 “-I”标志更改为 COPTS

添加的 include 路径将包含生成的文件以及 都在源代码树中

标签;默认值为 "@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++ 链接器命令中。 受“品牌”的约束变量替换, <ph type="x-smartling-placeholder"></ph> 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=Truelinkshared=True,您会得到一个,主要是 一个独立的单元

linkstatic

布尔值;默认值为 True

对于cc_binarycc_test:以静态方式关联二进制文件 模式。对于 cc_library.link_static:请参阅下文。

默认情况下,系统会为 cc_binary 启用此选项,为其余设备关闭此选项。

如果已启用,并且是二进制文件或测试文件,此选项将指示构建工具加入 尽可能为用户库使用 .a(而非 .so)。 系统库,如 libc(但不是 C/C++ 运行时库、 (如下所示)仍是动态链接的, 因为没有静态库因此生成的可执行文件仍会 处于关联状态,因此大部分都是静态的。

关联可执行文件其实有三种不同的方法:

  • 使用完全静态链接功能的 STATIC,在该功能中,所有内容均以静态方式链接; 例如“gcc -static foo.o libbar.a libbaz.a -lm”。
    您可以通过在fully_static_link features 属性。
  • STATIC,其中所有用户库均以静态方式链接(如果 版本可用),但系统库(不包括 C/C++ 运行时库) 动态关联,例如“gcc foo.o libfoo.a libbaz.a -lm”。
    通过指定 linkstatic=True 即可启用此模式。
  • 动态 - 所有库都动态关联(如果动态版本 可用),例如“gcc foo.o libfoo.so libbaz.so -lm”。
    通过指定 linkstatic=False 即可启用此模式。

如果 linkstatic 属性或 fully_static_link//third_party 之外使用了features 请在规则旁边添加注释以说明原因。

linkstatic 属性在用于 cc_library() 规则。 对于 C++ 库,linkstatic=True 表示 允许使用静态链接,因此系统不会生成任何 .so。linkstatic=False 可以 不会阻止创建静态库。该属性旨在控制 创建动态库

在生产环境中使用 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

module_interfaces

标签列表;默认值为 []

这些文件列表被视为 C++20 模块接口。

C++ Standard 对模块接口文件扩展名没有限制

  • Clang 使用 cppm
  • GCC 可以使用任何源文件扩展名
  • MSVC 使用 ixx

使用由标志保护 --experimental_cpp_modules

nocopts

String;默认值为 ""

从 C++ 编译命令中移除匹配选项。 受“品牌”的约束变量替换。 此属性的值会被解释为正则表达式。 与此正则表达式匹配的任何现有 COPTS (包括规则的 copts 属性中明确指定的值) 将从 COPTS 中移除,以便编译此规则。 不需要或使用此属性 third_party 之外。这些值未经过预处理 除“品牌”变量替换。
reexport_deps

标签列表;默认值为 []

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, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, toolchains, 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.将共享库与接口库相关联

在 Unix 上:


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # libmylib.ifso is an interface library for libmylib.so which will be passed to linker
  interface_library = "libmylib.ifso",
  # libmylib.so will be available for runtime
  shared_library = "libmylib.so",
)

在 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 关联

在 Unix 上:


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  system_provided = 1,
)

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

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

其余命令在 Unix 和 Windows 上是相同的:


# first will link to libmylib.a (or libmylib.lib)
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so (or libmylib.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

标签列表;默认值为 []

发布的 这个预编译的库,将由源代码直接包含在依赖规则中。

布尔值;默认值为 False

如果为 1,则表示(直接或间接)依赖于此 C++ 的任何二进制文件 预编译的库会链接至静态库中归档的所有对象文件, 即使其中一些不包含二进制文件引用的符号,也是如此。 如果 二进制文件。例如,如果您的代码注册以接收一些回调 提供的服务

如果 alwayslink 无法用于 Windows 上的 VS 2017,原因在于 已知问题, 请将 VS 2017 升级到最新版本。

includes

字符串列表;默认值为 []

要添加到编译行的 include 目录列表。 需遵循替换 "Make variable" 的规定。 每个字符串都以软件包路径为前缀,并传递到 C++ 工具链, 通过“include_paths”CROSSTOOL 功能。在 POSIX 系统上运行的工具链 将生成 -isystem path_to_package/include_entry。 它只能用于 不符合 Google 的 #include 语句写作风格。 与 COPTS 不同,系统会为此规则添加这些标记 以及依赖于它的所有规则(注意:并非其所依赖的规则!)是 必须格外小心,因为这可能会造成深远的影响。如有疑问,请添加 “-I”标志更改为 COPTS

默认 include 路径不包含生成的 文件。如果您需要对生成的头文件使用 #include 文件,请将其列在 srcs 中。

interface_library

标签;默认值为 None

用于关联共享库的单个接口库。

允许的文件类型: .ifso, .tbd, .lib, .so.dylib

linkopts

字符串列表;默认值为 []

将这些标志添加到 C++ 链接器命令中。 受“品牌”的约束变量替换, <ph type="x-smartling-placeholder"></ph> Bourne shell 标记化 标签扩展。 此属性中的每个字符串都会先添加到 LINKOPTS 中, 链接二进制目标。

此列表中将出现每个不以 $- 开头的元素 假定为 deps 中目标的标签。通过 该目标生成的文件的列表会附加到链接器 选项。如果标签无效,或者 未在 deps 中声明。

objects

标签列表;默认值为 []

pic_objects

标签列表;默认值为 []

pic_static_library

标签;默认值为 None

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, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

对于由 C++ 编译的库,请使用 cc_library()。 结果是 .so.lo、 或 .a,具体取决于具体需求。

如果您使用依赖于 cc_library,依赖的库规则的输出 是 .a 文件。如果您指定 alwayslink=True,您会获得 .lo 文件。

对于libfoo.so 共享库,其中 foo 是规则的名称。通过 其他类型的库以 .lo.a 结尾, 。如果您需要一个特定的共享库名称, 例如,要定义一个 Python 模块,可以使用 Genrule 来复制库 更改为所需的名称。

标头包含性检查

build 中使用的所有头文件都必须在 cc_* 规则的 hdrssrcs。 这是强制执行的。

对于 cc_library 规则,hdrs 中的标头包括 库的公共接口,并且可以直接包含 从库的 hdrssrcs 的文件中获取 以及来自 hdrssrcs 的文件中 (共 cc_* 条规则,这些规则在其 deps 中列出该库)。 srcs 中的头文件只能直接从文件中包含在内 在库本身的 hdrssrcs 中。时间 决定是将标头放入 hdrs 还是 srcs, 您应询问是否希望此库的使用方能够 直接包含它这与 publicprivate 的编程语言的可见性。

未导出 cc_binarycc_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.hbar.h,但不包含 baz.h

包括文件允许的包含项
foo.hbar.h
foo.ccfoo.h bar.h
bar.hbar-impl.h,baz.h
bar-impl.hbar.h baz.h
bar.ccbar.h bar-impl.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-impl.h

包含检查规则仅适用于直接 包含。在上面的示例中,foo.cc 可以 包括bar.h,其中可能包括baz.h, 允许 turn 包含 baz-impl.h。从技术上讲 编译 .cc 文件可能会以传递方式包含任何头文件 文件放在 hdrssrcs 传递 deps 闭包中的任何 cc_library。在 在这种情况下,编译器可能会读取 baz.hbaz-impl.h 编译 foo.cc 时,但 foo.cc 不得 包含“#include "baz.h"”。为此 允许,必须将 baz 添加到 depsfoo 个。

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

示例


cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 1,
)

以下示例来自 third_party/python2_4_3/BUILD。 部分代码使用 dl 库(从 另一个动态库),所以这个 规则指定 -ldl 链接选项,以链接 dl 库。


cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

以下示例来自 third_party/kde/BUILD。 我们将预构建的 .so 文件保存在库中。 头文件位于名为 include 的子目录中。


cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

以下示例来自 third_party/gles/BUILD。 第三方代码通常需要一些 defineslinkopts


cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

参数

属性
name

姓名;必需

此目标的唯一名称。

deps

标签列表;默认值为 []

库所依赖的其他库的列表。

这些目标可以是 cc_libraryobjc_library

查看关于 deps 的一般评论 大多数构建规则

这些应该是 C++ 库规则的名称。 当您构建关联此规则库的二进制文件时, 您还需要关联 deps 中的库。

尽管“依赖项”并非此库的所有客户端 都属于这里。运行时数据依赖项属于 data。 由其他规则生成的源文件属于 srcs

要关联预编译的第三方库,请将其名称添加到 srcs

要在不将其关联至此库的情况下依赖于某个资源,请将其 改为 data

srcs

标签列表;默认值为 []

为创建库目标而处理的 C 和 C++ 文件的列表。 这些是非生成的 C/C++ 源文件和头文件, 代码)。

所有 .cc.c.cpp 文件都会 进行编译。这些文件可能是生成的文件:如果 一些其他规则的 outs,即此cc_library 都将自动依赖于那条规则

纯汇编程序文件(.s、.asm)不会进行预处理,并且通常使用 汇编程序预处理的汇编文件 (.S) 会经过预处理,并且通常是 使用 C/C++ 编译器编写代码。

.h 文件不会进行编译,但可用于 按来源纳入此规则。.cc.h 文件可以直接包含 这些srcs、此规则的hdrs或任何 deps 参数中列出的规则。

所有 #included 个文件都必须在 此或引用的 cc_libraryhdrs 属性 或者如果为私有规则,则应将其列在 srcs 中 添加到此库中。如需了解更多详情,请参阅“标头包含项检查”。 更加详细的说明

.so.lo.a 文件 预编译文件您的媒体库可能包含以下内容: 如果它使用我们不使用的第三方代码,则为 srcs 都没有源代码

如果 srcs 属性包含另一条规则的标签, cc_library 会将该规则的输出文件作为源文件,执行以下操作: 编译。这对于一次性生成源代码非常有用( 最好实现 Starlark 规则类并使用 cc_common API)

允许的 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

...以及生成这些文件的任何规则(例如 cc_embed_data)。 不同的扩展表示 。

data

标签列表;默认值为 []

此库在运行时所需的文件列表。 查看关于 data 的一般评论 大多数构建规则

如果 data 是生成文件的名称,则以下代码 cc_library规则会自动依赖于 规则。

如果 data 是规则名称,则 cc_library规则自动依赖于该规则 并且该规则的outs会自动添加到 此cc_library的数据文件。

您的 C++ 代码可以像这样访问这些数据文件:


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
hdrs

标签列表;默认值为 []

发布的 将此库直接包含在依赖规则中。

这是声明 描述该库的接口这些标头 以供来源添加到此规则或依赖规则中。 此库的客户端不应包含的标头应 在 srcs 属性中列出,即使它们位于 包含的公共文档资源。请参阅“标头包含” ”查看更详细的说明。

允许的 headers 文件类型: .h, .hh, .hpp, .hxx

additional_compiler_inputs

标签列表;默认值为 []

您可能想要传递给编译器命令行的任何其他文件,例如 sanitizer 忽略列表等。随后,您便可以在 copts 中使用 $(location) 函数。
additional_linker_inputs

标签列表;默认值为 []

将这些文件传递给 C++ 链接器命令。

例如,您可以在此处提供经过编译的 Windows .res 文件, 二进制目标。

布尔值;默认值为 False

如果为 1,则表示(直接或间接)依赖于此 C++ 的任何二进制文件 会链接至 srcs,即使其中一些不包含二进制文件引用的符号也是如此。 如果 二进制文件。例如,如果您的代码注册以接收一些回调 提供的服务

如果 alwayslink 无法用于 Windows 上的 VS 2017,原因在于 已知问题, 请将 VS 2017 升级到最新版本。

copts

字符串列表;默认值为 []

将这些选项添加到 C++ 编译命令中。 需遵循 "Make variable" 替换和 Bourne shell 令牌化

此属性中的每个字符串都会按照指定顺序添加到 COPTS 中, 编译二进制目标的过程这些标志仅在编译此目标时有效,而不会在编译此目标时生效 因此请注意别处包含的头文件。 所有路径都应相对于工作区,而不是当前软件包。 third_party 之外不需要此属性。

如果该软件包声明了 featureno_copts_tokenization,Bourne shell 标记化仅适用于字符串 其中包含一个“品牌”变量。

defines

字符串列表;默认值为 []

要添加到编译行的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成, 前缀为 -D,并添加到编译命令行中, 以及依赖于该规则的每条规则请务必小心, 产生深远的影响。如有疑问,请将定义值添加到 local_defines
hdrs_check

String;默认值为 ""

已弃用,无运维。
implementation_deps

标签列表;默认值为 []

库目标所依赖的其他库的列表。取消 deps,这些库(及其所有库)的头文件和 include 路径 传递依赖项)仅用于编译此库,而不会用于 一切都依赖于它使用 implementation_deps 指定的库仍然链接到 依赖于此库的二进制文件目标

目前,此用法仅限于 cc_library,并由标志保护 --experimental_cc_implementation_deps

include_prefix

String;默认值为 ""

要添加到此规则标头的路径中的前缀。

设置后,此规则的 hdrs 属性中的标头可供访问 at 是该属性的值,位于其代码库相对路径前面。

先移除 strip_include_prefix 属性中的前缀, 前缀。

此属性仅在 third_party 下有效。

includes

字符串列表;默认值为 []

要添加到编译行的 include 目录列表。 需遵循替换 "Make variable" 的规定。 每个字符串都以软件包路径为前缀,并传递到 C++ 工具链, 通过“include_paths”CROSSTOOL 功能。在 POSIX 系统上运行的工具链 将生成 -isystem path_to_package/include_entry。 它只能用于 不符合 Google 的 #include 语句写作风格。 与 COPTS 不同,系统会为此规则添加这些标记 以及依赖于它的所有规则(注意:并非其所依赖的规则!)是 必须格外小心,因为这可能会造成深远的影响。如有疑问,请添加 “-I”标志更改为 COPTS

添加的 include 路径将包含生成的文件以及 都在源代码树中

linkopts

字符串列表;默认值为 []

请参阅 cc_binary.linkoptslinkopts 属性还会应用于 通过 deps 直接或间接依赖于此库 属性(或通过其他以类似方式处理的属性): malloc cc_binary 的属性)。依赖项 linkopt 优先于从属 linkopt(即附属 linkopt) 稍后在命令行中显示)。中指定的 Linkopt --linkopt 规则链接优化

请注意,linkopts 属性仅适用于 创建 .so 文件或可执行文件时, (创建 .a.lo 文件时)。 因此,如果设置了 linkstatic=True 属性, linkopts 属性对 此库仅在依赖于此库的其他目标上运行。

另外,需要注意的是,“-Wl,-soname”或“-Xlinker -soname” 选项不受支持,且绝不应在此属性中指定选项。

cc_library 生成的 .so 文件 不会与其依赖的库相关联 。如果您正在尝试创建供使用的共享库 在主代码库之外运行,例如手动使用 使用dlopen()LD_PRELOAD, 最好使用cc_binary规则 与 linkshared=True 属性相关联。 请参阅 cc_binary.linkshared

linkstamp

标签;默认值为 None

同时编译指定的 C++ 源文件并将其关联到最终版本 二进制文件要引入时间戳,必须用这种伎俩 转换为二进制文件;如果我们将源文件编译为 对象文件,那么时间戳就会是错误的。 链接戳记编译不得包含任何 编译器标记,因此不应依赖于任何特定的 头文件、编译器选项或其他编译变量。 只有在 base 软件包。
linkstatic

布尔值;默认值为 False

对于cc_binarycc_test:以静态方式关联二进制文件 模式。对于 cc_library.link_static:请参阅下文。

默认情况下,系统会为 cc_binary 启用此选项,为其余设备关闭此选项。

如果已启用,并且是二进制文件或测试文件,此选项将指示构建工具加入 尽可能为用户库使用 .a(而非 .so)。 系统库,如 libc(但不是 C/C++ 运行时库、 (如下所示)仍是动态链接的, 因为没有静态库因此生成的可执行文件仍会 处于关联状态,因此大部分都是静态的。

关联可执行文件其实有三种不同的方法:

  • 使用完全静态链接功能的 STATIC,在该功能中,所有内容均以静态方式链接; 例如“gcc -static foo.o libbar.a libbaz.a -lm”。
    您可以通过在fully_static_link features 属性。
  • STATIC,其中所有用户库均以静态方式链接(如果 版本可用),但系统库(不包括 C/C++ 运行时库) 动态关联,例如“gcc foo.o libfoo.a libbaz.a -lm”。
    通过指定 linkstatic=True 即可启用此模式。
  • 动态 - 所有库都动态关联(如果动态版本 可用),例如“gcc foo.o libfoo.so libbaz.so -lm”。
    通过指定 linkstatic=False 即可启用此模式。

如果 linkstatic 属性或 fully_static_link//third_party 之外使用了features 请在规则旁边添加注释以说明原因。

linkstatic 属性在用于 cc_library() 规则。 对于 C++ 库,linkstatic=True 表示 允许使用静态链接,因此系统不会生成任何 .so。linkstatic=False 可以 不会阻止创建静态库。该属性旨在控制 创建动态库

在生产环境中使用 linkstatic=False 构建的代码应该非常少。 如果为 linkstatic=False,构建工具将创建指向 *.runfiles 区域中依赖的共享库。

local_defines

字符串列表;默认值为 []

要添加到编译行的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成, 前缀为 -D,并添加到此目标的编译命令行中, 但不向其依赖项传递。
module_interfaces

标签列表;默认值为 []

这些文件列表被视为 C++20 模块接口。

C++ Standard 对模块接口文件扩展名没有限制

  • Clang 使用 cppm
  • GCC 可以使用任何源文件扩展名
  • MSVC 使用 ixx

使用由标志保护 --experimental_cpp_modules

strip_include_prefix

String;默认值为 ""

要从此规则的标头的路径中删除的前缀。

设置后,此规则的 hdrs 属性中的标头可供访问 其路径上的任何部分被截断的前缀。

如果是相对路径,则会被当作软件包相对路径。如果它是绝对的, 系统会将它理解为代码库相对路径。

include_prefix 属性中的前缀会添加到此前缀后面 删除。

此属性仅在 third_party 下有效。

textual_hdrs

标签列表;默认值为 []

发布的 此库将由来源以文本形式包含在依赖规则中。

此位置用于声明无法自行编译的头文件; 也就是说,它们始终需要由其他源文件以文本形式包含,才能构建有效的 代码。

win_def_file

标签;默认值为 None

要传递给链接器的 Windows DEF 文件。

仅当 Windows 是目标平台时,才应使用此属性。 它可用于 导出符号

cc_proto_library

查看规则来源
cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, 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, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, 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 静态链接 foobaz,后者是传递依赖项。没有 关联 bar,因为它已由 dynamic_dep bar_shared

foo_shared 使用链接器脚本 *.lds 文件来控制 的所有文件。cc_shared_library 规则逻辑 不控制要导出哪些符号,它仅使用 以便在分析阶段出错(如果两个共享库导出 相同的目标。

假定 cc_shared_library 的每个直接依赖项如下: 已导出。因此,Bazel 在分析期间假定 foofoo_shared导出。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 依赖项。

每当您使用两个属性创建新的 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

标签列表;默认值为 []

将无条件静态关联到共享库的顶级库 归档后的新文件

这些直接依赖项的任何传递库依赖项都将链接到此共享 但前提是它们尚未被 cc_shared_library 关联 在 dynamic_deps 中。

在分析过程中,规则实施会考虑 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提供。

experimental_disable_topo_sort_do_not_use_remove_before_7_0

布尔值;默认值为 False

exports_filter

字符串列表;默认值为 []

此属性包含声称由当前 共享库。

任何目标 deps 都已理解为由共享库导出。 此属性应该用于列出共享库导出的所有目标 但属于 deps 的传递依赖项。

请注意,此属性实际上并没有为这些目标添加依赖关系, 应改为由 deps 创建。此 属性只是字符串。请注意,在此属性中放置目标时 则会被视为声明共享库将从该目标导出符号。 cc_shared_library 逻辑实际上并不会负责告知链接器 的所有文件。

允许使用以下语法:

//foo:__package__,用于解释 foo/BUILD 中的任何目标

//foo:__subpackages__,用于解释 foo/BUILD 或其他任何 低于 foo/ 的软件包,例如 foo/bar/BUILD

roots

标签列表;默认值为 []

shared_lib_name

String;默认值为 ""

默认情况下,cc_shared_library 将根据 目标的名称和平台其中包括扩展名,有时还包括前缀。 有时您可能不需要默认名称,例如在加载 C++ 共享库时 对于 Python,通常不需要默认的 lib* 前缀,在这种情况下,可以使用此 属性选择自定义名称。
static_deps

字符串列表;默认值为 []

字符串列表;默认值为 []

您可能想要传递给链接器的任何其他标志。例如,要使 链接程序知道通过 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 是目标平台时,才应使用此属性。 它可用于 导出符号

cc_static_library

查看规则来源
cc_static_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
从目标及其传递依赖项的列表生成静态库。

生成的静态库包含 deps 及其传递依赖项,优先采用 PIC 对象。

输出组

linkdeps

一个文本文件,包含 中所列目标的传递依赖项的标签。 deps:没有向静态库贡献任何对象文件,但执行了 提供至少一个静态库、动态库或接口库。生成的静态库 这些库可能需要在关联时可用。

linkopts

一个文本文件,包含用户提供的所有传递词的 linkopts deps 中列出的目标的依赖项。

符号重复

默认情况下,cc_static_library 规则会检查生成的静态变量 库不包含任何重复的符号。如果是,构建会失败并显示错误 消息,其中列出了重复符号和包含这些符号的对象文件。

可以按目标或软件包停用此检查,方法是设置 features = ["-symbol_check"]或通过 --features=-symbol_check

symbol_check 的工具链支持

Bazel 随附的自动配置的 C++ 工具链支持 所有平台上的 symbol_check 功能。自定义工具链可以添加对 通过以下两种方式之一来保存数据:

  • 实现 ACTION_NAMES.validate_static_library 操作并 则可通过 symbol_check 功能启用该功能。操作中的工具集是 使用两个参数调用的静态库,用于检查是否存在重复的符号和 路径。
  • symbol_check 功能添加归档程序标志,这些标志会导致 创建静态库的操作在出现重复符号时失败。

参数

属性
name

姓名;必需

此目标的唯一名称。

deps

标签列表;默认值为 []

要组合到静态库中的目标列表,包括其所有传递对象 依赖项

不提供任何对象文件的依赖项不会包含在静态 但其标签收集在 linkdeps 个输出组。

cc_test

查看规则来源
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

cc_test() 规则可编译测试。在这里, 是一些测试代码的二进制封装容器

默认情况下,C++ 测试是动态链接的
如需静态链接单元测试,请指定 linkstatic=True。 最好说明为什么您的测试需要 linkstatic;这一点可能并不明显

隐式输出目标

  • name.stripped(仅在明确请求时构建):剥离 二进制文件版本。对二进制文件运行 strip -g 以移除调试 符号。您可以使用以下命令在命令行中提供其他剥离选项: --stripopt=-foo
  • name.dwp(仅在明确请求时构建):如果 已启用 Fission:调试 信息包文件。否则: 空白文件。

请参阅 cc_binary() 参数,但以下情况除外: 对于测试,stamp 参数默认设置为 0,并且 cc_test 有多余的 所有测试规则通用的属性 (*_test)

参数

属性
name

姓名;必需

此目标的唯一名称。

deps

标签列表;默认值为 []

要链接到二进制文件目标的其他库的列表。

这些值可以是 cc_libraryobjc_library 目标。

还可以 将链接器脚本 (.lds) 放入依赖项,并在 linkopts
srcs

标签列表;默认值为 []

为创建库目标而处理的 C 和 C++ 文件的列表。 这些是非生成的 C/C++ 源文件和头文件, 代码)。

所有 .cc.c.cpp 文件都会 进行编译。这些文件可能是生成的文件:如果 一些其他规则的 outs,即此cc_library 都将自动依赖于那条规则

纯汇编程序文件(.s、.asm)不会进行预处理,并且通常使用 汇编程序预处理的汇编文件 (.S) 会经过预处理,并且通常是 使用 C/C++ 编译器编写代码。

.h 文件不会进行编译,但可用于 按来源纳入此规则。.cc.h 文件可以直接包含 这些srcs、此规则的hdrs或任何 deps 参数中列出的规则。

所有 #included 个文件都必须在 此或引用的 cc_libraryhdrs 属性 或者如果为私有规则,则应将其列在 srcs 中 添加到此库中。如需了解更多详情,请参阅“标头包含项检查”。 更加详细的说明

.so.lo.a 文件 预编译文件您的媒体库可能包含以下内容: 如果它使用我们不使用的第三方代码,则为 srcs 都没有源代码

如果 srcs 属性包含另一条规则的标签, cc_library 会将该规则的输出文件作为源文件,执行以下操作: 编译。这对于一次性生成源代码非常有用( 最好实现 Starlark 规则类并使用 cc_common API)

允许的 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

...以及生成这些文件的任何规则(例如 cc_embed_data)。 不同的扩展表示 。

data

标签列表;默认值为 []

此库在运行时所需的文件列表。 查看关于 data 的一般评论 大多数构建规则

如果 data 是生成文件的名称,则以下代码 cc_library规则会自动依赖于 规则。

如果 data 是规则名称,则 cc_library规则自动依赖于该规则 并且该规则的outs会自动添加到 此cc_library的数据文件。

您的 C++ 代码可以像这样访问这些数据文件:


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

标签列表;默认值为 []

将这些文件传递给 C++ 链接器命令。

例如,您可以在此处提供经过编译的 Windows .res 文件, 二进制目标。

copts

字符串列表;默认值为 []

将这些选项添加到 C++ 编译命令中。 需遵循 "Make variable" 替换和 Bourne shell 令牌化

此属性中的每个字符串都会按照指定顺序添加到 COPTS 中, 编译二进制目标的过程这些标志仅在编译此目标时有效,而不会在编译此目标时生效 因此请注意别处包含的头文件。 所有路径都应相对于工作区,而不是当前软件包。 third_party 之外不需要此属性。

如果该软件包声明了 featureno_copts_tokenization,Bourne shell 标记化仅适用于字符串 其中包含一个“品牌”变量。

defines

字符串列表;默认值为 []

要添加到编译行的定义列表。 受“品牌”的约束变量替换和 Bourne shell 令牌化。 每个字符串都必须由单个 Bourne shell 令牌组成, 前缀为 -D,并添加到编译命令行中, 以及依赖于该规则的每条规则请务必小心, 产生深远的影响。如有疑问,请将定义值添加到 local_defines
dynamic_deps

标签列表;默认值为 []

这些是当前目标所依赖的其他 cc_shared_library 依赖项。

cc_shared_library 实现将使用 dynamic_deps(传递性,即dynamic_deps 当前目标的dynamic_deps),以决定在哪个cc_libraries 不应链接传递 deps,因为已提供 由另一位cc_shared_library提供。

hdrs_check

String;默认值为 ""

已弃用,无运维。
includes

字符串列表;默认值为 []

要添加到编译行的 include 目录列表。 需遵循替换 "Make variable" 的规定。 每个字符串都以软件包路径为前缀,并传递到 C++ 工具链, 通过“include_paths”CROSSTOOL 功能。在 POSIX 系统上运行的工具链 将生成 -isystem path_to_package/include_entry。 它只能用于 不符合 Google 的 #include 语句写作风格。 与 COPTS 不同,系统会为此规则添加这些标记 以及依赖于它的所有规则(注意:并非其所依赖的规则!)是 必须格外小心,因为这可能会造成深远的影响。如有疑问,请添加 “-I”标志更改为 COPTS

添加的 include 路径将包含生成的文件以及 都在源代码树中

标签;默认值为 "@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++ 链接器命令中。 受“品牌”的约束变量替换, <ph type="x-smartling-placeholder"></ph> 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=Truelinkshared=True,您会得到一个,主要是 一个独立的单元

linkstatic

布尔值;默认值为 False

对于cc_binarycc_test:以静态方式关联二进制文件 模式。对于 cc_library.link_static:请参阅下文。

默认情况下,系统会为 cc_binary 启用此选项,为其余设备关闭此选项。

如果已启用,并且是二进制文件或测试文件,此选项将指示构建工具加入 尽可能为用户库使用 .a(而非 .so)。 系统库,如 libc(但不是 C/C++ 运行时库、 (如下所示)仍是动态链接的, 因为没有静态库因此生成的可执行文件仍会 处于关联状态,因此大部分都是静态的。

关联可执行文件其实有三种不同的方法:

  • 使用完全静态链接功能的 STATIC,在该功能中,所有内容均以静态方式链接; 例如“gcc -static foo.o libbar.a libbaz.a -lm”。
    您可以通过在fully_static_link features 属性。
  • STATIC,其中所有用户库均以静态方式链接(如果 版本可用),但系统库(不包括 C/C++ 运行时库) 动态关联,例如“gcc foo.o libfoo.a libbaz.a -lm”。
    通过指定 linkstatic=True 即可启用此模式。
  • 动态 - 所有库都动态关联(如果动态版本 可用),例如“gcc foo.o libfoo.so libbaz.so -lm”。
    通过指定 linkstatic=False 即可启用此模式。

如果 linkstatic 属性或 fully_static_link//third_party 之外使用了features 请在规则旁边添加注释以说明原因。

linkstatic 属性在用于 cc_library() 规则。 对于 C++ 库,linkstatic=True 表示 允许使用静态链接,因此系统不会生成任何 .so。linkstatic=False 可以 不会阻止创建静态库。该属性旨在控制 创建动态库

在生产环境中使用 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

module_interfaces

标签列表;默认值为 []

这些文件列表被视为 C++20 模块接口。

C++ Standard 对模块接口文件扩展名没有限制

  • Clang 使用 cppm
  • GCC 可以使用任何源文件扩展名
  • MSVC 使用 ixx

使用由标志保护 --experimental_cpp_modules

nocopts

String;默认值为 ""

从 C++ 编译命令中移除匹配选项。 受“品牌”的约束变量替换。 此属性的值会被解释为正则表达式。 与此正则表达式匹配的任何现有 COPTS (包括规则的 copts 属性中明确指定的值) 将从 COPTS 中移除,以便编译此规则。 不需要或使用此属性 third_party 之外。这些值未经过预处理 除“品牌”变量替换。
reexport_deps

标签列表;默认值为 []

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_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

表示 C++ 工具链。

此规则负责:

  • 收集运行 C++ 操作所需的所有工件。这是通过 属性,例如 all_filescompiler_fileslinker_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 包含的内容,所有 Starlark 都会使用它 使用 C++ 工具链创建规则。

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

布尔值;默认值为 False

已弃用。无运维。
libc_top

标签;默认值为 None

作为输入传递给编译/链接操作的 libc 工件集合。
linker_files

标签;必需

关联操作所需的所有 cc_toolchain 工件的集合。
module_map

标签;默认值为 None

用于模块化 build 的模块映射工件。
objcopy_files

标签;必需

objcopy 操作所需的所有 cc_toolchain 工件的集合。
output_licenses

字符串列表;默认值为 []

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

String;默认值为 ""

用于将此 cc_toolchain 与 crosstool_config.toolchain.

直到问题 #5380 得到解决 这是将 cc_toolchainCROSSTOOL.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)

已弃用:该规则为空操作,将被移除。

参数

属性
name

姓名;必需

此目标的唯一名称。

fdo_prefetch_hints

查看规则来源
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

表示工作区中的 FDO 预提取提示配置文件。 示例:


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

参数

属性
name

姓名;必需

此目标的唯一名称。

profile

标签;必需

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

fdo_profile

查看规则来源
fdo_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, memprof_profile, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

表示工作区中的 FDO 配置文件。 示例:


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

参数

属性
name

姓名;必需

此目标的唯一名称。

memprof_profile

标签;默认值为 None

MemProf 配置文件的标签。配置文件应包含 .profdata 扩展名(适用于编入索引/符号化的 memprof) 或包含 memprof .profdata 的 zip 文件的.zip 扩展名 文件。
profile

标签;必需

FDO 配置文件的标签或生成该配置文件的规则。FDO 文件可以包含 以下扩展名:.profraw 表示未编入索引的 LLVM 配置文件,.profdata 表示已编入索引的 LLVM 配置文件、包含 LLVM Profraw 配置文件的 .zip、用于 AutoFDO 配置文件的 .afdo、用于 XBinary 配置文件。该标签还可以指向 fdo_绝对_path_profile 规则。
proto_profile

标签;默认值为 None

protobuf 配置文件的标签。

memprof_profile

查看规则来源
memprof_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

表示工作区中的 MEMPROF 配置文件。 示例:


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

参数

属性
name

姓名;必需

此目标的唯一名称。

profile

标签;必需

MEMPROF 配置文件的标签。配置文件应包含 .profdata 扩展名(适用于编入索引/符号化的 memprof) 或包含 memprof .profdata 的 zip 文件的.zip 扩展名 文件。 该标签还可以指向 fdo_绝对_path_profile 规则。

propeller_optimize

查看规则来源
propeller_optimize(name, cc_profile, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, ld_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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


propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

参数

属性
name

姓名;必需

此目标的唯一名称。

cc_profile

标签;必需

传递给各种编译操作的配置文件的标签。此文件包含 .txt 扩展名。
ld_profile

标签;必需

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