规则
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_library
- cc_test
- cc_toolchain
- cc_toolchain_suite
- fdo_prefetch_hints
- fdo_profile
- memprof_profile
- propeller_optimize
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
|
标签列表;默认值为 这些目标可以是 |
srcs
|
标签列表;默认值为 系统会编译所有 系统不会对纯汇编程序文件(.s、.asm)进行预处理,并且通常使用汇编程序构建此类文件。预处理的汇编文件 (.S) 会进行预处理,并且通常使用 C/C++ 编译器进行构建。
所有
如果
允许的
...以及生成这些文件的任何规则(例如 |
data
|
标签列表;默认值为 data 的一般注释。如果 如果 您的 C++ 代码可以像这样访问这些数据文件:
|
additional_linker_inputs
|
标签列表;默认值为 例如,您可以在此处提供已编译的 Windows .res 文件,以将其嵌入到二进制目标中。 |
copts
|
字符串列表;默认值为
在编译二进制目标之前,此属性中的每个字符串都会按给定顺序添加到
如果软件包声明 feature
|
defines
|
字符串列表;默认值为 -D 前缀,并添加到编译命令行中,并添加到此目标中,以及依赖于它的每条规则。请务必小心,因为这可能会造成深远的影响。如果有疑问,请改为向 local_defines 添加定义值。 |
dynamic_deps
|
标签列表;默认值为 cc_shared_library 依赖项。
|
hdrs_check
|
字符串;默认值为 |
includes
|
字符串列表;默认值为 -isystem path_to_package/include_entry 。这只能用于不符合 Google 的 #include 语句编写样式的第三方库。
与 COPTS 不同,系统会为此规则以及依赖于它的每条规则添加这些标记。(注意:并非其所依赖的规则!)请务必小心,因为这可能会造成深远的影响。如有疑问,请将“-I”标志添加到 COPTS。
添加的 |
link_extra_lib
|
标签;默认值为
默认情况下,C++ 二进制文件链接到 |
linkopts
|
字符串列表;默认值为 LINKOPTS 中,然后再关联二进制目标。
此列表假定列表中每个不以 |
linkshared
|
布尔值;默认值为 linkshared=True 。默认情况下,此选项处于关闭状态。
如果存在此标志,则表示使用
如果您同时指定 |
linkstatic
|
布尔值;默认值为 cc_binary 和 cc_test :在静态模式下关联二进制文件。对于 cc_library.link_static :请参阅下文。
默认情况下,系统会为
如果启用,并且这是二进制文件或测试文件,则此选项会告知构建工具尽可能链接 关联可执行文件其实有三种不同的方法:
如果
如果用于
在生产环境中使用 |
local_defines
|
字符串列表;默认值为 -D 作为前缀,并添加到此目标的编译命令行中,但不会添加到其依赖项中。 |
malloc
|
标签;默认值为
默认情况下,C++ 二进制文件链接到 |
module_interfaces
|
标签列表;默认值为 C++ 标准对模块接口文件扩展名没有限制
该使用由 |
nocopts
|
字符串;默认值为 COPTS 中移除与此正则表达式匹配的所有先前存在的 COPTS (包括规则的 copts 属性中明确指定的值)。不应在 third_party 之外需要使用此属性,也不应使用此属性。除了“Make”变量替换之外,不会以任何其他方式对这些值进行预处理。 |
reexport_deps
|
标签列表;默认值为 |
stamp
|
整数;默认值为
除非其依赖项发生变化,否则带时间戳的二进制文件不会被重新构建。 |
win_def_file
|
标签;默认值为 仅当 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
|
标签列表;默认值为 |
alwayslink
|
布尔值;默认值为 如果由于已知问题而导致始终链接无法用于 Windows 上的 VS 2017,请将 VS 2017 升级到最新版本。 |
includes
|
字符串列表;默认值为 -isystem path_to_package/include_entry 。这只能用于不符合 Google 的 #include 语句编写样式的第三方库。
与 COPTS 不同,系统会为此规则以及依赖于它的每条规则添加这些标记。(注意:并非其所依赖的规则!)请务必小心,因为这可能会造成深远的影响。如有疑问,请将“-I”标志添加到 COPTS。
默认 |
interface_library
|
标签;默认值为 允许的文件类型: |
linkopts
|
字符串列表;默认值为 LINKOPTS 中,然后再关联二进制目标。
此列表假定列表中每个不以 |
objects
|
标签列表;默认值为 |
pic_objects
|
标签列表;默认值为 |
pic_static_library
|
标签;默认值为 |
shared_library
|
标签;默认值为 允许的文件类型: |
static_library
|
标签;默认值为 允许的文件类型: |
system_provided
|
布尔值;默认值为 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 是规则的名称。foo其他类型的库分别以 .lo
和 .a
结尾。如果您需要特定的共享库名称(例如要定义 Python 模块),请使用 genrule 将库复制到所需的名称。
标头包含性检查
build 中使用的所有头文件必须在 cc_*
规则的 hdrs
或 srcs
中声明。系统会强制执行此要求。
对于 cc_library
规则,hdrs
中的头文件包含库的公共接口,可以直接从库本身的 hdrs
和 srcs
中的文件,以及 cc_*
规则的 hdrs
和 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 使用此功能。
示例
我们使用 alwayslink
标记强制链接器链接此代码,不过主二进制代码不会引用它。
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
库(用于加载另一个动态库),因此此规则指定了用于关联 dl
库的 -ldl
链接选项。
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
。第三方代码通常需要一些 defines
和 linkopts
。
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
|
标签列表;默认值为 这些目标可以是 请参阅大多数构建规则定义的典型属性中有关 这些应该是 C++ 库规则的名称。当您构建关联此规则的库的二进制文件时,您还需要关联 尽管名称是“deps”,但并非此库的所有客户端都属于这里。运行时数据依赖项属于 如需关联预编译的第三方库,请改为将其名称添加到 如需在未将其关联到此库的情况下依赖于某些内容,请将其名称添加到 |
srcs
|
标签列表;默认值为 系统会编译所有 系统不会对纯汇编程序文件(.s、.asm)进行预处理,并且通常使用汇编程序构建此类文件。预处理的汇编文件 (.S) 会进行预处理,并且通常使用 C/C++ 编译器进行构建。
所有
如果
允许的
...以及生成这些文件的任何规则(例如 |
data
|
标签列表;默认值为 data 的一般注释。如果 如果 您的 C++ 代码可以像这样访问这些数据文件:
|
hdrs
|
标签列表;默认值为 此位置是声明用于描述库接口的头文件的位置。这些标头将可供此规则或依赖规则中的来源包含。
不应纳入此库的客户端的标头应改为列在 允许的 |
additional_compiler_inputs
|
标签列表;默认值为 |
additional_linker_inputs
|
标签列表;默认值为 例如,您可以在此处提供已编译的 Windows .res 文件,以将其嵌入到二进制目标中。 |
alwayslink
|
布尔值;默认值为 srcs 中列出的文件的所有对象文件中,即使其中某些文件不包含二进制文件引用的符号也是如此。如果您的代码没有被二进制文件中的代码明确调用(例如,您的代码注册以接收某项服务提供的某种回调),那么该方法会非常有用。
如果由于已知问题而导致始终链接无法用于 Windows 上的 VS 2017,请将 VS 2017 升级到最新版本。 |
copts
|
字符串列表;默认值为
在编译二进制目标之前,此属性中的每个字符串都会按给定顺序添加到
如果软件包声明 feature
|
defines
|
字符串列表;默认值为 -D 前缀,并添加到编译命令行中,并添加到此目标中,以及依赖于它的每条规则。请务必小心,因为这可能会造成深远的影响。如果有疑问,请改为向 local_defines 添加定义值。 |
hdrs_check
|
字符串;默认值为 |
implementation_deps
|
标签列表;默认值为 deps 不同,这些库(及其所有传递依赖项)的头文件和 include 路径仅用于此库的编译,而不会用于依赖于此库的库。使用 implementation_deps 指定的库仍会链接到依赖于此库的二进制文件目标。目前,此用法仅限于 cc_library,并由 |
include_prefix
|
字符串;默认值为 设置后,此规则的 在添加此前缀之前,系统会先移除 此属性仅在 |
includes
|
字符串列表;默认值为 -isystem path_to_package/include_entry 。这只能用于不符合 Google 的 #include 语句编写样式的第三方库。
与 COPTS 不同,系统会为此规则以及依赖于它的每条规则添加这些标记。(注意:并非其所依赖的规则!)请务必小心,因为这可能会造成深远的影响。如有疑问,请将“-I”标志添加到 COPTS。
添加的 |
linkopts
|
字符串列表;默认值为 cc_binary.linkopts 。
linkopts 属性还会应用于通过 deps 属性(或通过被视为类似处理的其他属性:cc_binary 的 malloc 属性)直接或间接依赖于此库的任何目标。依赖项 linkopt 优先于从属 linkopt(即依赖项 linkopt 稍后显示在命令行中)。--linkopt 中指定的 linkopt 优先于规则 linkopt。
请注意, 此外,请务必注意,“-Wl,-soname”或“-Xlinker -soname”选项不受支持,且绝不应在此属性中指定。 由 |
linkstamp
|
标签;默认值为 base 软件包中才需要此选项。
|
linkstatic
|
布尔值;默认值为 cc_binary 和 cc_test :在静态模式下关联二进制文件。对于 cc_library.link_static :请参阅下文。
默认情况下,系统会为
如果启用,并且这是二进制文件或测试文件,则此选项会告知构建工具尽可能链接 关联可执行文件其实有三种不同的方法:
如果
如果用于
在生产环境中使用 |
local_defines
|
字符串列表;默认值为 -D 作为前缀,并添加到此目标的编译命令行中,但不会添加到其依赖项中。 |
module_interfaces
|
标签列表;默认值为 C++ 标准对模块接口文件扩展名没有限制
该使用由 |
strip_include_prefix
|
字符串;默认值为 设置后,此规则的 如果是相对路径,则会被当作软件包相对路径。如果它是绝对路径,则会被理解为代码库相对路径。
此属性仅在 |
textual_hdrs
|
标签列表;默认值为 这是用于声明无法自行编译的头文件的位置;也就是说,它们始终需要由其他源文件以文本形式包含才能构建有效代码。 |
win_def_file
|
标签;默认值为 仅当 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 规则列表。 |
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
静态链接 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
|
标签列表;默认值为
这些直接依赖项的任何传递库依赖项都将关联到此共享库,前提是它们尚未被
在分析期间,规则实现会将
每当同一库以静态方式链接到多个 |
additional_linker_inputs
|
标签列表;默认值为 user_link_flags 属性执行此操作。 |
dynamic_deps
|
标签列表;默认值为 cc_shared_library 依赖项。
|
experimental_disable_topo_sort_do_not_use_remove_before_7_0
|
布尔值;默认值为 |
exports_filter
|
字符串列表;默认值为
任何目标
请注意,此属性实际上并没有向这些目标添加依赖边缘,依赖边缘应由 允许使用以下语法:
|
roots
|
标签列表;默认值为 |
shared_lib_name
|
字符串;默认值为 |
static_deps
|
字符串列表;默认值为 |
user_link_flags
|
字符串列表;默认值为
|
win_def_file
|
标签;默认值为 仅当 Windows 是目标平台时,才应使用此属性。 它可用于在关联共享库期间 导出符号。 |
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
|
标签列表;默认值为 这些目标可以是 |
srcs
|
标签列表;默认值为 系统会编译所有 系统不会对纯汇编程序文件(.s、.asm)进行预处理,并且通常使用汇编程序构建此类文件。预处理的汇编文件 (.S) 会进行预处理,并且通常使用 C/C++ 编译器进行构建。
所有
如果
允许的
...以及生成这些文件的任何规则(例如 |
data
|
标签列表;默认值为 data 的一般注释。如果 如果 您的 C++ 代码可以像这样访问这些数据文件:
|
additional_linker_inputs
|
标签列表;默认值为 例如,您可以在此处提供已编译的 Windows .res 文件,以将其嵌入到二进制目标中。 |
copts
|
字符串列表;默认值为
在编译二进制目标之前,此属性中的每个字符串都会按给定顺序添加到
如果软件包声明 feature
|
defines
|
字符串列表;默认值为 -D 前缀,并添加到编译命令行中,并添加到此目标中,以及依赖于它的每条规则。请务必小心,因为这可能会造成深远的影响。如果有疑问,请改为向 local_defines 添加定义值。 |
dynamic_deps
|
标签列表;默认值为 cc_shared_library 依赖项。
|
hdrs_check
|
字符串;默认值为 |
includes
|
字符串列表;默认值为 -isystem path_to_package/include_entry 。这只能用于不符合 Google 的 #include 语句编写样式的第三方库。
与 COPTS 不同,系统会为此规则以及依赖于它的每条规则添加这些标记。(注意:并非其所依赖的规则!)请务必小心,因为这可能会造成深远的影响。如有疑问,请将“-I”标志添加到 COPTS。
添加的 |
link_extra_lib
|
标签;默认值为
默认情况下,C++ 二进制文件链接到 |
linkopts
|
字符串列表;默认值为 LINKOPTS 中,然后再关联二进制目标。
此列表假定列表中每个不以 |
linkshared
|
布尔值;默认值为 linkshared=True 。默认情况下,此选项处于关闭状态。
如果存在此标志,则表示使用
如果您同时指定 |
linkstatic
|
布尔值;默认值为 cc_binary 和 cc_test :在静态模式下关联二进制文件。对于 cc_library.link_static :请参阅下文。
默认情况下,系统会为
如果启用,并且这是二进制文件或测试文件,则此选项会告知构建工具尽可能链接 关联可执行文件其实有三种不同的方法:
如果
如果用于
在生产环境中使用 |
local_defines
|
字符串列表;默认值为 -D 作为前缀,并添加到此目标的编译命令行中,但不会添加到其依赖项中。 |
malloc
|
标签;默认值为
默认情况下,C++ 二进制文件链接到 |
module_interfaces
|
标签列表;默认值为 C++ 标准对模块接口文件扩展名没有限制
该使用由 |
nocopts
|
字符串;默认值为 COPTS 中移除与此正则表达式匹配的所有先前存在的 COPTS (包括规则的 copts 属性中明确指定的值)。不应在 third_party 之外需要使用此属性,也不应使用此属性。除了“Make”变量替换之外,不会以任何其他方式对这些值进行预处理。 |
reexport_deps
|
标签列表;默认值为 |
stamp
|
整数;默认值为
除非其依赖项发生变化,否则带时间戳的二进制文件不会被重新构建。 |
win_def_file
|
标签;默认值为 仅当 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_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 )。
这是 |
ar_files
|
标签;默认值为 |
as_files
|
标签;默认值为 |
compiler_files
|
标签(必需) 编译操作所需的所有 cc_toolchain 工件的集合。 |
compiler_files_without_includes
|
标签;默认值为 |
coverage_files
|
标签;默认值为 |
dwp_files
|
标签(必需) dwp 操作所需的所有 cc_toolchain 工件的集合。 |
dynamic_runtime_lib
|
标签;默认值为 此属性将在启用“static_link_cpp_runtimes”功能时用到,并且我们会动态关联依赖项。 |
exec_transition_for_inputs
|
布尔值;默认值为 |
libc_top
|
标签;默认值为 |
linker_files
|
标签(必需) 关联操作所需的所有 cc_toolchain 工件的集合。 |
module_map
|
标签;默认值为 |
objcopy_files
|
标签(必需) objcopy 操作所需的所有 cc_toolchain 工件的集合。 |
output_licenses
|
字符串列表;默认值为 |
static_runtime_lib
|
标签;默认值为 当“static_link_cpp_runtimes”功能处于启用状态,并且我们以静态方式关联依赖项时,将使用此属性。 |
strip_files
|
标签(必需) 剥离操作所需的所有 cc_toolchain 工件的集合。 |
supports_header_parsing
|
布尔值;默认值为 |
supports_param_files
|
布尔值;默认值为 |
toolchain_config
|
标签(必需) 提供cc_toolchain_config_info 的规则的标签。
|
toolchain_identifier
|
字符串;默认值为
在问题 #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_绝对路径_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
|
标签;默认值为 |
profile
|
标签(必需) FDO 配置文件的标签或生成该配置文件的规则。FDO 文件可以使用以下扩展名之一:.profraw(用于未编入索引的 LLVM 配置文件)、.profdata(用于已编入索引的 LLVM 配置文件)、.zip(用于保存 LLVM Profraw 配置文件)、.afdo(用于 AutoFDO 配置文件)、.xfdo(用于 XBinary 配置文件)。该标签还可以指向 fdo_absolute_path_profile 规则。 |
proto_profile
|
标签;默认值为 |
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 配置文件),或 .zip 扩展名(对于包含 memprof.profdata 文件的 zip 文件)。该标签还可以指向 fdo_absolute_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。 |