規則
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_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 |
此目標的專屬名稱。 |
deps
|
可以是 |
srcs
|
所有 系統不會編譯 所有 如果規則的名稱位於
允許的
...以及產生這些檔案的任何規則。 不同的擴充功能會根據 gcc 慣例,表示不同的程式設計語言。 |
additional_linker_inputs
|
舉例來說,您可以在這裡提供編譯的 Windows .res 檔案並嵌入二進位目標中。 |
copts
|
此屬性中的每個字串都會以特定順序新增至
如果套件宣告功能
|
defines
|
-D ,並新增至該目標的編譯指令列及所有規則。請注意,這樣做可能會帶來極大的影響。如有疑慮,請改為將定義值新增至 local_defines 。 |
includes
|
取決於 「Make variable」替代變數。每個字串前面都會加上 標頭必須新增至 src 或 hd,否則在編譯沙箱時,這些規則將無法供獨立規則使用 (預設)。 |
linkopts
|
LINKOPTS 。
這份清單中每個開頭不是 |
linkshared
|
linkshared=True 。這個選項預設為關閉。
如果有這個標記,表示在
如果同時指定 |
linkstatic
|
cc_binary 和 cc_test :在靜態模式中連結二進位檔。針對 cc_library.linkstatic :請參閱以下說明。
根據預設,
如果啟用這個選項,且這是二進位檔或測試,這個選項會盡可能讓建構工具在 連結執行檔的方法有三種:
在
如果設為 |
local_defines
|
-D ,並新增至這個目標的編譯指令列,但不適用於其依附元件。 |
malloc
|
根據預設,C++ 二進位檔會與 |
nocopts
|
COPTS (包括規則 copts 屬性中指定的值) 都會從 COPTS 中移除。這個屬性不應很少使用。 |
stamp
|
除非其依附元件已變更,否則重新建構的二進位檔不會重新建構。 |
win_def_file
|
只有在 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
|
如果一律連結功能不適用於 Windows 2017 版本 (因為已知問題),請將 Sv2017 升級至最新版本。 |
interface_library
|
允許的檔案類型: |
shared_library
|
允許的檔案類型: |
static_library
|
允許的檔案類型: |
system_provided
|
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)
標頭收錄檢查
用於建構作業的所有標頭檔案,都必須在 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 | 列.h |
foo.cc | foo.h 長條.h |
列.h | Bar-impl.h baz.h |
Bar-impl.h | Bar.h baz.h |
列.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
檔案的編譯作業可能會遞移至 hdrs
或 srcs
中的任何標頭檔案,用於在轉換轉換的 deps
關閉中。cc_library
在這個範例中,編譯器在編譯 foo.cc
時可能會讀取 baz.h
和 baz-impl.h
,但 foo.cc
不得包含 #include "baz.h"
。因此,baz
必須新增至 foo
的 deps
。
Bazel 必須依賴工具鍊支援,以強制執行納入檢查規則。layering_check
功能必須由工具鍊支援,並明確要求,例如透過 --features=layering_check
指令列旗標或 package
函式的 features
參數。Bazel 提供的工具鍊僅支援 Unix 和 macOS 的 clang 這項功能。
引數
屬性 | |
---|---|
name |
此目標的專屬名稱。 |
deps
|
可以是 |
srcs
|
所有 系統不會編譯 所有 如果規則的名稱位於
允許的
...以及產生這些檔案的任何規則。 不同的擴充功能會根據 gcc 慣例,表示不同的程式設計語言。 |
hdrs
|
這通常是宣告宣告檔案,用於說明程式庫介面的標頭檔案。這些標頭將依據此規則的來源或獨立規則進行納入。不應納入這個程式庫用戶端的標頭應改為 |
alwayslink
|
srcs 中列出檔案的所有物件檔案連結,即使其中不含二進位檔參照的符號。如果二進位檔並未由二進位檔中的程式碼明確呼叫 (例如,程式碼會在註冊時接收某些服務提供的回呼),這項功能就非常實用。如果一律連結功能不適用於 Windows 2017 版本 (因為已知問題),請將 Sv2017 升級至最新版本。 |
copts
|
此屬性中的每個字串都會以特定順序新增至
如果套件宣告功能
|
defines
|
-D ,並新增至該目標的編譯指令列及所有規則。請注意,這樣做可能會帶來極大的影響。如有疑慮,請改為將定義值新增至 local_defines 。 |
implementation_deps
|
deps 不同,這些標頭的標頭和包含這些程式庫的路徑 (及其所有遞移依附元件) 只會用於這個程式庫的編譯作業,且不會依賴依附此程式庫的程式庫。使用 implementation_deps 指定的程式庫仍會與依附此程式庫的二進位目標連結。目前用量僅限於 cc_library,並受到旗標 |
include_prefix
|
設定之後,這個規則 這個前置字串新增前,系統會移除 |
includes
|
取決於 「Make variable」替代變數。每個字串前面都會加上 標頭必須新增至 src 或 hd,否則在編譯沙箱時,這些規則將無法供獨立規則使用 (預設)。 |
linkopts
|
LINKOPTS 。
這份清單中每個開頭不是 |
linkstamp
|
base 套件。
|
linkstatic
|
cc_binary 和 cc_test :在靜態模式中連結二進位檔。針對 cc_library.linkstatic :請參閱以下說明。
根據預設,
如果啟用這個選項,且這是二進位檔或測試,這個選項會盡可能讓建構工具在 連結執行檔的方法有三種:
在
如果設為 |
local_defines
|
-D ,並新增至這個目標的編譯指令列,但不適用於其依附元件。 |
nocopts
|
COPTS (包括規則 copts 屬性中指定的值) 都會從 COPTS 中移除。這個屬性不應很少使用。 |
strip_include_prefix
|
設定之後,這個規則的 如果是相對路徑,系統會將其視為套件相關路徑。如果是絕對路徑,就代表這是存放區相對路徑。 移除這個前置字元後,系統會新增 |
textual_hdrs
|
這個位置是用於宣告無法自行編譯的標頭檔案,也就是說,這些檔案必須一律包含其他文字檔案,才能建構有效的程式碼。 |
win_def_file
|
只有在 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 規則清單。
|
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
。foo_shared
不會假設要匯出 baz
。系統也會假設符合 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
標記 cul 狀況 cc_library
,但這項修正應該很少見,而且您絕對應該確保 cc_library
確實會多次連結。
'//foo:foo' is already linked statically in '//bar:bar' but not exported`
也就是說,在不透過其中一個 cc_shared_library
依附元件存取 deps
過渡式封閉程式庫的情況下,該程式庫已連結到 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 依附元件。
|
exports_filter
|
任何目標
請注意,此屬性實際上不會新增依附元件邊緣至這些目標,而是會透過 我們允許使用以下語法:
|
shared_lib_name
|
|
user_link_flags
|
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
|
只有在 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
|
|
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
|
|
profile
|
|
proto_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
|
|
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 |
此目標的專屬名稱。 |
deps
|
可以是 |
srcs
|
所有 系統不會編譯 所有 如果規則的名稱位於
允許的
...以及產生這些檔案的任何規則。 不同的擴充功能會根據 gcc 慣例,表示不同的程式設計語言。 |
additional_linker_inputs
|
舉例來說,您可以在這裡提供編譯的 Windows .res 檔案並嵌入二進位目標中。 |
copts
|
此屬性中的每個字串都會以特定順序新增至
如果套件宣告功能
|
defines
|
-D ,並新增至該目標的編譯指令列及所有規則。請注意,這樣做可能會帶來極大的影響。如有疑慮,請改為將定義值新增至 local_defines 。 |
includes
|
取決於 「Make variable」替代變數。每個字串前面都會加上 標頭必須新增至 src 或 hd,否則在編譯沙箱時,這些規則將無法供獨立規則使用 (預設)。 |
linkopts
|
LINKOPTS 。
這份清單中每個開頭不是 |
linkstatic
|
cc_binary 和 cc_test :在靜態模式中連結二進位檔。針對 cc_library.linkstatic :請參閱以下說明。
根據預設,
如果啟用這個選項,且這是二進位檔或測試,這個選項會盡可能讓建構工具在 連結執行檔的方法有三種:
在
如果設為 |
local_defines
|
-D ,並新增至這個目標的編譯指令列,但不適用於其依附元件。 |
malloc
|
根據預設,C++ 二進位檔會與 |
nocopts
|
COPTS (包括規則 copts 屬性中指定的值) 都會從 COPTS 中移除。這個屬性不應很少使用。 |
stamp
|
除非其依附元件已變更,否則重新建構的二進位檔不會重新建構。 |
win_def_file
|
只有在 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 |
此目標的專屬名稱。 |
all_files
|
all_files 是所有其他成果提供屬性的超集 (例如:linktamp 編譯需要編譯和連結檔案,因此需要 all_files )。
這是 |
ar_files
|
封存動作所需的所有 cc_toolchain 構件集合。 |
as_files
|
組合動作所需的所有 cc_toolchain 構件集合。 |
compiler
|
toolchain_identifier 屬性。在
CROSSTOOL 遷移至 Starlark
之後,這個數量固定不變,並將於 #7075 中移除。設定完成後,系統就會使用這個值執行 crosstool_config.toolchain。系統會優先採用 --cpu Bazel 選項。 |
compiler_files
|
|
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
設定完成後,系統就會使用這個值執行 crosstool_config.toolchain。系統會優先採用 --cpu Bazel 選項。 |
dwp_files
|
|
dynamic_runtime_lib
|
當您啟用「static_link_cpp_runtimes」功能時,我們將動態連結依附元件。 |
exec_transition_for_inputs
|
|
libc_top
|
|
linker_files
|
|
module_map
|
|
objcopy_files
|
|
static_runtime_lib
|
當您啟用「static_link_cpp_runtimes」功能,且靜態連結依附元件時,將會使用此功能。 |
strip_files
|
|
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)
代表 C++ 工具鍊的集合。
這項規則的責任如下:
- 收集所有相關的 C++ 工具鍊。
-
根據傳遞至 Bazel 的
--cpu
和--compiler
選項選取工具鍊。
另請參閱這個 頁面 ,取得精緻的 C++ 工具鍊設定和工具鍊選取說明文件。
引數
屬性 | |
---|---|
name |
此目標的專屬名稱。 |
toolchains
|
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", }, ) |