可設定屬性 (通常稱為 select()
) 是 Bazel 功能,可讓使用者切換值
建構規則屬性
舉例來說,如果多平台程式庫會自動 為架構選擇適當的實作項目,或為 功能可設定的二進位檔,可在建構期間自訂。
範例
# myapp/BUILD
cc_binary(
name = "mybinary",
srcs = ["main.cc"],
deps = select({
":arm_build": [":arm_lib"],
":x86_debug_build": [":x86_dev_lib"],
"//conditions:default": [":generic_lib"],
}),
)
config_setting(
name = "arm_build",
values = {"cpu": "arm"},
)
config_setting(
name = "x86_debug_build",
values = {
"cpu": "x86",
"compilation_mode": "dbg",
},
)
這麼做會宣告「選擇」的 cc_binary
追蹤 Deployment
指令列具體來說,deps
會變為:
指令 | deps = |
bazel build //myapp:mybinary --cpu=arm |
[":arm_lib"] |
bazel build //myapp:mybinary -c dbg --cpu=x86 |
[":x86_dev_lib"] |
bazel build //myapp:mybinary --cpu=ppc |
[":generic_lib"] |
bazel build //myapp:mybinary -c dbg --cpu=ppc |
[":generic_lib"] |
select()
做為值的預留位置,系統會根據其做選擇
設定條件,也就是參照 config_setting
的標籤
目標。在可設定的屬性中使用 select()
,代表這個屬性
在不同條件設有時,有效地採用不同的價值。
相符項目必須不明確:如果同時符合多個條件,
* 這些函式都會解析成相同的值。例如,在 Linux x86 上執行時,這顯然很模糊
{"@platforms//os:linux": "Hello", "@platforms//cpu:x86_64": "Hello"}
,因為這兩個分支版本都會解析為「hello」。
* 其中一個的 values
是所有其他欄位的嚴格超集合'。例如:values = {"cpu": "x86", "compilation_mode": "dbg"}
是 values = {"cpu": "x86"}
的明確專業化。
系統會在下列情況自動比對內建條件 //conditions:default
不會產生其他影響
雖然本例使用 deps
,但 select()
也適用於 srcs
,
resources
、cmd
和大多數其他屬性。只有少量屬性
「無法設定」,而且會清楚顯示這類註解。例如:
「config_setting
」已具備
無法設定 values
屬性。
select()
和依附元件
某些屬性會變更所有遞移依附元件的建構參數
而非目標的支出舉例來說,genrule
的 tools
會將 --cpu
變更為
執行 Bazel 的機器 (由於跨平台程式碼編譯)
而非該目標所需的 CPU)。也就是
設定轉換。
有
#myapp/BUILD
config_setting(
name = "arm_cpu",
values = {"cpu": "arm"},
)
config_setting(
name = "x86_cpu",
values = {"cpu": "x86"},
)
genrule(
name = "my_genrule",
srcs = select({
":arm_cpu": ["g_arm.src"],
":x86_cpu": ["g_x86.src"],
}),
tools = select({
":arm_cpu": [":tool1"],
":x86_cpu": [":tool2"],
}),
)
cc_binary(
name = "tool1",
srcs = select({
":arm_cpu": ["armtool.cc"],
":x86_cpu": ["x86tool.cc"],
}),
)
執行中
$ bazel build //myapp:my_genrule --cpu=arm
x86
開發人員機器上的版本會將建構繫結至 g_arm.src
、tool1
和
x86tool.cc
。連接至 my_genrule
的 select
都使用 my_genrule
的
建構參數,包含 --cpu=arm
。tools
屬性有所變更
tool1
及其遞移依附元件的 --cpu
變更為 x86
。select
tool1
會使用 tool1
的建構參數,包括 --cpu=x86
。
設定條件
可設定屬性中的每個鍵都是對
config_setting
或
constraint_value
。
config_setting
只是一系列的
預期的指令列旗標設定。只要將這些內容封裝到目標中
如何維持「標準」可從多個位置參照的條件
constraint_value
支援多平台行為。
內建旗標
像 --cpu
這樣的標記會內建在 Bazel 中:建構工具原生理解
適用於所有專案中的所有版本指定為
config_setting
的
values
屬性:
config_setting(
name = "meaningful_condition_name",
values = {
"flag1": "value1",
"flag2": "value2",
...
},
)
flagN
是標記名稱 (不含 --
,因此 "cpu"
而不是 "--cpu"
)。valueN
就是該標記的預期值:meaningful_condition_name
符合以下條件:
values
中的每一個項目都相符。順序無關。
剖析 valueN
時,會當做在指令列中設定。因此:
values = { "compilation_mode": "opt" }
與bazel build -c opt
相符values = { "force_pic": "true" }
與bazel build --force_pic=1
相符values = { "force_pic": "0" }
與bazel build --noforce_pic
相符
config_setting
僅支援會影響目標行為的標記。例如:
--show_progress
禁止,原因如下:
這只會影響 Bazel 將進度回報給使用者的方式。目標無法使用
旗標,建構結果。確切的受支援標記組合
。實務上,大多數「合理」的標記這些研究有助於我們找出
能引導後續作業的標準
自訂旗標
可以使用以下項目,建立自己的專案專屬標記模型: Starlark 版本設定。有別於內建旗標 定義為建構目標,因此 Bazel 會將這些目標與目標標籤進行參照。
查詢是透過 config_setting
的
flag_values
。
屬性:
config_setting(
name = "meaningful_condition_name",
flag_values = {
"//myflags:flag1": "value1",
"//myflags:flag2": "value2",
...
},
)
--define
敬上
是自訂旗標的替代舊版語法 (例如
--define foo=bar
)。這可以用
values 屬性
(values = {"define": "foo=bar"}
) 或
define_values 屬性
(define_values = {"foo": "bar"}
)。--define
僅支援回溯值
相容性。盡可能優先使用 Starlark 版本設定。
values
、flag_values
和 define_values
會獨立評估。
如果所有值都相符,config_setting
就會達成比對。
預設條件
沒有其他條件時符合內建條件「//conditions:default
」
比對。
因為「完全符合」規則, 可設定屬性沒有相符結果
且沒有預設條件發出 "no matching conditions"
錯誤。這可以
避免意外的設定發生
# myapp/BUILD
config_setting(
name = "x86_cpu",
values = {"cpu": "x86"},
)
cc_library(
name = "x86_only_lib",
srcs = select({
":x86_cpu": ["lib.cc"],
}),
)
$ bazel build //myapp:x86_only_lib --cpu=arm
ERROR: Configurable attribute "srcs" doesn't match this configuration (would
a default condition help?).
Conditions checked:
//myapp:x86_cpu
如要進一步消除錯誤,您可以使用 select()
的
no_match_error
屬性。
平台
雖然可以透過指令列指定多個標記,但也可以 所以每次要個別設定 即可建立目標 平台 可讓您將這些元素整合為簡單的套裝組合
# myapp/BUILD
sh_binary(
name = "my_rocks",
srcs = select({
":basalt": ["pyroxene.sh"],
":marble": ["calcite.sh"],
"//conditions:default": ["feldspar.sh"],
}),
)
config_setting(
name = "basalt",
constraint_values = [
":black",
":igneous",
],
)
config_setting(
name = "marble",
constraint_values = [
":white",
":metamorphic",
],
)
# constraint_setting acts as an enum type, and constraint_value as an enum value.
constraint_setting(name = "color")
constraint_value(name = "black", constraint_setting = "color")
constraint_value(name = "white", constraint_setting = "color")
constraint_setting(name = "texture")
constraint_value(name = "smooth", constraint_setting = "texture")
constraint_setting(name = "type")
constraint_value(name = "igneous", constraint_setting = "type")
constraint_value(name = "metamorphic", constraint_setting = "type")
platform(
name = "basalt_platform",
constraint_values = [
":black",
":igneous",
],
)
platform(
name = "marble_platform",
constraint_values = [
":white",
":smooth",
":metamorphic",
],
)
您可以透過指令列指定平台。它會啟動
config_setting
,其中包含平台的 constraint_values
、
讓這些 config_setting
在 select()
運算式中進行比對。
舉例來說,如要將 my_rocks
的 srcs
屬性設為 calcite.sh
,
您可以直接執行
bazel build //my_app:my_rocks --platforms=//myapp:marble_platform
如果沒有平台,這看起來會像這樣
bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
select()
也可以直接讀取 constraint_value
:
constraint_setting(name = "type")
constraint_value(name = "igneous", constraint_setting = "type")
constraint_value(name = "metamorphic", constraint_setting = "type")
sh_binary(
name = "my_rocks",
srcs = select({
":igneous": ["igneous.sh"],
":metamorphic" ["metamorphic.sh"],
}),
)
如果只需要config_setting
檢查單一值
平台仍處於開發階段。詳情請參閱 說明文件。
合併 select()
秒
select
可以在同一個屬性中多次顯示:
sh_binary(
name = "my_target",
srcs = ["always_include.sh"] +
select({
":armeabi_mode": ["armeabi_src.sh"],
":x86_mode": ["x86_src.sh"],
}) +
select({
":opt_mode": ["opt_extras.sh"],
":dbg_mode": ["dbg_extras.sh"],
}),
)
select
無法顯示在另一個 select
中。如需將 selects
建立巢狀結構
屬性則接受其他目標值,請使用中階目標:
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":armeabi_mode": [":armeabi_lib"],
...
}),
)
sh_library(
name = "armeabi_lib",
srcs = select({
":opt_mode": ["armeabi_with_opt.sh"],
...
}),
)
如需在符合多個條件時比對 select
,請考慮使用 AND
鏈結。
OR 鏈結
請把握以下幾項重點:
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1": [":standard_lib"],
":config2": [":standard_lib"],
":config3": [":standard_lib"],
":config4": [":special_lib"],
}),
)
多數條件都會得出相同的 依附元件。這個語法不易讀取
維護。最好不用重複 [":standard_lib"]
次
次。
您可以選擇將值預先定義為 BUILD 變數:
STANDARD_DEP = [":standard_lib"]
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1": STANDARD_DEP,
":config2": STANDARD_DEP,
":config3": STANDARD_DEP,
":config4": [":special_lib"],
}),
)
這樣就能更輕鬆地管理依附元件。但這仍會造成不必要的 重複內容
如需更直接的支援服務,請使用下列其中一項:
selects.with_or
with_or
巨集位於 Skylib 的
selects
模組支援直接在 select
內使用 OR
條件:
load("@bazel_skylib//lib:selects.bzl", "selects")
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = selects.with_or({
(":config1", ":config2", ":config3"): [":standard_lib"],
":config4": [":special_lib"],
}),
)
selects.config_setting_group
config_setting_group
巨集位於 Skylib 的
selects
模組支援 OR
多個 config_setting
:
load("@bazel_skylib//lib:selects.bzl", "selects")
config_setting(
name = "config1",
values = {"cpu": "arm"},
)
config_setting(
name = "config2",
values = {"compilation_mode": "dbg"},
)
selects.config_setting_group(
name = "config1_or_2",
match_any = [":config1", ":config2"],
)
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1_or_2": [":standard_lib"],
"//conditions:default": [":other_lib"],
}),
)
有別於 selects.with_or
,不同目標可在不同目標之間共用 :config1_or_2
不同的屬性
除非其中一個條件不夠明確,否則將視為無法比對多個條件 「專業認證」這些值就會解析為相同的值詳情請參閱這篇文章。
AND 鏈結
如需在符合多個條件時比對 select
分支,請使用
Skylib 巨集
config_setting_group:
config_setting(
name = "config1",
values = {"cpu": "arm"},
)
config_setting(
name = "config2",
values = {"compilation_mode": "dbg"},
)
selects.config_setting_group(
name = "config1_and_2",
match_all = [":config1", ":config2"],
)
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1_and_2": [":standard_lib"],
"//conditions:default": [":other_lib"],
}),
)
與「或」鏈結不同,現有config_setting
無法直接AND
將
在 select
內。您必須明確將其納入 config_setting_group
中。
自訂錯誤訊息
根據預設,如果沒有相符條件,系統會將 select()
附加至目標
失敗,錯誤訊息:
ERROR: Configurable attribute "deps" doesn't match this configuration (would
a default condition help?).
Conditions checked:
//tools/cc_target_os:darwin
//tools/cc_target_os:android
請使用 no_match_error
自訂這項設定
屬性:
cc_library(
name = "my_lib",
deps = select(
{
"//tools/cc_target_os:android": [":android_deps"],
"//tools/cc_target_os:windows": [":windows_deps"],
},
no_match_error = "Please build with an Android or Windows toolchain",
),
)
$ bazel build //myapp:my_lib
ERROR: Configurable attribute "deps" doesn't match this configuration: Please
build with an Android or Windows toolchain
規則相容性
規則實作會接收可設定的解析值 屬性。舉例來說:
# myapp/BUILD
some_rule(
name = "my_target",
some_attr = select({
":foo_mode": [":foo"],
":bar_mode": [":bar"],
}),
)
$ bazel build //myapp/my_target --define mode=foo
規則導入程式碼將 ctx.attr.some_attr
視為 [":foo"]
。
巨集可接受 select()
子句並傳遞至原生程式碼
不過,編寫這類演算法並不容易
因為我們無法寫出所有可能的規則但無法直接操縱這些事件。舉例來說
以便轉換巨集
select({"foo": "val"}, ...)
到
select({"foo": "val_with_suffix"}, ...)
這麼做有兩個原因。
首先,需知道 select
選擇哪個路徑的巨集「無法運作」
因為系統會在 Bazel 載入階段評估巨集。
發生在標記值之前。
這只是核心 Bazel 設計限制,不太可能隨時變更。
第二,只需要疊代處理所有 select
路徑的巨集,
技術上可行
缺少一致性的 UI必須進一步設計才能變更
而負責任的 AI 技術做法
有助於達成這項目標
Bazel 查詢和 cquery
Bazel query
是透過 Bazel 的
載入階段。
這表示,服務並不知道目標使用的指令列,因為那些指令列會標記
系統在建構作業的後續版本 (在
分析階段)。
因此,系統無法決定要選擇哪些 select()
分支版本。
Bazel cquery
會在 Bazel 的分析階段後運作,因此
以上資訊,也能夠準確解析 select()
。
請考慮採用以下建議:
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
# myapp/BUILD
string_flag(
name = "dog_type",
build_setting_default = "cat"
)
cc_library(
name = "my_lib",
deps = select({
":long": [":foo_dep"],
":short": [":bar_dep"],
}),
)
config_setting(
name = "long",
flag_values = {":dog_type": "dachshund"},
)
config_setting(
name = "short",
flag_values = {":dog_type": "pug"},
)
query
高估 :my_lib
的依附元件:
$ bazel query 'deps(//myapp:my_lib)'
//myapp:my_lib
//myapp:foo_dep
//myapp:bar_dep
cquery
則顯示其確切依附元件:
$ bazel cquery 'deps(//myapp:my_lib)' --//myapp:dog_type=pug
//myapp:my_lib
//myapp:bar_dep
常見問題
為什麼 select() 無法在巨集中運作?
select()「可」在規則中使用!請參閱「規則相容性」一文,瞭解 詳細資料。
這個問題的主要問題通常是因為 select() 不適用於 巨集。這些與規則不同。詳情請參閱 規則和巨集的說明文件 以便瞭解其中差異 以下是端對端範例:
定義規則和巨集:
# myapp/defs.bzl
# Rule implementation: when an attribute is read, all select()s have already
# been resolved. So it looks like a plain old attribute just like any other.
def _impl(ctx):
name = ctx.attr.name
allcaps = ctx.attr.my_config_string.upper() # This works fine on all values.
print("My name is " + name + " with custom message: " + allcaps)
# Rule declaration:
my_custom_bazel_rule = rule(
implementation = _impl,
attrs = {"my_config_string": attr.string()},
)
# Macro declaration:
def my_custom_bazel_macro(name, my_config_string):
allcaps = my_config_string.upper() # This line won't work with select(s).
print("My name is " + name + " with custom message: " + allcaps)
將規則和巨集例項化:
# myapp/BUILD
load("//myapp:defs.bzl", "my_custom_bazel_rule")
load("//myapp:defs.bzl", "my_custom_bazel_macro")
my_custom_bazel_rule(
name = "happy_rule",
my_config_string = select({
"//third_party/bazel_platforms/cpu:x86_32": "first string",
"//third_party/bazel_platforms/cpu:ppc": "second string",
}),
)
my_custom_bazel_macro(
name = "happy_macro",
my_config_string = "fixed string",
)
my_custom_bazel_macro(
name = "sad_macro",
my_config_string = select({
"//third_party/bazel_platforms/cpu:x86_32": "first string",
"//third_party/bazel_platforms/cpu:ppc": "other string",
}),
)
建構失敗,因為 sad_macro
無法處理 select()
:
$ bazel build //myapp:all
ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
(most recent call last):
File "/myworkspace/myapp/BUILD", line 17
my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
File "/myworkspace/myapp/defs.bzl", line 4, in
my_custom_bazel_macro
my_config_string.upper()
type 'select' has no method upper().
ERROR: error loading package 'myapp': Package 'myapp' contains errors.
對 sad_macro
加註時,建構作業成功:
# Comment out sad_macro so it doesn't mess up the build.
$ bazel build //myapp:all
DEBUG: /myworkspace/myapp/defs.bzl:5:3: My name is happy_macro with custom message: FIXED STRING.
DEBUG: /myworkspace/myapp/hi.bzl:15:3: My name is happy_rule with custom message: FIRST STRING.
這項變更無法改變,因為系統會先評估定義巨集, Bazel 會讀取建構作業的指令列標記。這意味著 用於評估 select()s 的資料。
不過,巨集可以將 select()
當做不透明 blob 傳遞至規則:
# myapp/defs.bzl
def my_custom_bazel_macro(name, my_config_string):
print("Invoking macro " + name)
my_custom_bazel_rule(
name = name + "_as_target",
my_config_string = my_config_string,
)
$ bazel build //myapp:sad_macro_less_sad
DEBUG: /myworkspace/myapp/defs.bzl:23:3: Invoking macro sad_macro_less_sad.
DEBUG: /myworkspace/myapp/defs.bzl:15:3: My name is sad_macro_less_sad with custom message: FIRST STRING.
為什麼 select() 一律傳回 true?
因為巨集 (而非規則) 就定義了
「無法評估 select()
」,但嘗試這麼做
通常會產生錯誤:
ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
(most recent call last):
File "/myworkspace/myapp/BUILD", line 17
my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
File "/myworkspace/myapp/defs.bzl", line 4, in
my_custom_bazel_macro
my_config_string.upper()
type 'select' has no method upper().
布林值是一種特殊情況,會在訊息中自動失敗,因此請特別留意 務必善待他人:
$ cat myapp/defs.bzl
def my_boolean_macro(boolval):
print("TRUE" if boolval else "FALSE")
$ cat myapp/BUILD
load("//myapp:defs.bzl", "my_boolean_macro")
my_boolean_macro(
boolval = select({
"//third_party/bazel_platforms/cpu:x86_32": True,
"//third_party/bazel_platforms/cpu:ppc": False,
}),
)
$ bazel build //myapp:all --cpu=x86
DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
$ bazel build //mypro:all --cpu=ppc
DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
這是因為巨集無法辨識 select()
的內容。
所以實際上評估的是 select()
物件本身。根據
Python 設計
除了極少數例外狀況之外的所有物件
會自動傳回 true。
我可以像字典一樣讀取 select() 嗎?
巨集「無法」評估選取項目,因為巨集會先評估
Bazel 知道建構的指令列參數為何。至少能夠閱讀
舉例來說,select()
的字典要為每個值加上後置字串嗎?
概念上是可行的,但這並非 Bazel 功能。
您目前可以做什麼,先準備一份簡單的字典,再提供給
select()
:
$ cat myapp/defs.bzl
def selecty_genrule(name, select_cmd):
for key in select_cmd.keys():
select_cmd[key] += " WITH SUFFIX"
native.genrule(
name = name,
outs = [name + ".out"],
srcs = [],
cmd = "echo " + select(select_cmd + {"//conditions:default": "default"})
+ " > $@"
)
$ cat myapp/BUILD
selecty_genrule(
name = "selecty",
select_cmd = {
"//third_party/bazel_platforms/cpu:x86_32": "x86 mode",
},
)
$ bazel build //testapp:selecty --cpu=x86 && cat bazel-genfiles/testapp/selecty.out
x86 mode WITH SUFFIX
如果想同時支援 select()
和原生類型,可以執行以下操作:
$ cat myapp/defs.bzl
def selecty_genrule(name, select_cmd):
cmd_suffix = ""
if type(select_cmd) == "string":
cmd_suffix = select_cmd + " WITH SUFFIX"
elif type(select_cmd) == "dict":
for key in select_cmd.keys():
select_cmd[key] += " WITH SUFFIX"
cmd_suffix = select(select_cmd + {"//conditions:default": "default"})
native.genrule(
name = name,
outs = [name + ".out"],
srcs = [],
cmd = "echo " + cmd_suffix + "> $@",
)
為什麼 select() 無法與 bind() 搭配使用?
首先,不要使用 bind()
,已淘汰,並改用 alias()
。
技術面來說,bind()
是存放區
而不是 BUILD 規則
存放區規則沒有特定設定,因此不會評估
與 BUILD 規則相同因此,bind()
中的 select()
無法
實際評估任何特定分支版本
請改用 alias()
,而在select()
actual
屬性,以便執行這種類型的執行階段判斷作業。這個
可以正常運作,因為 alias()
是 BUILD 規則,而會以
特定設定
$ cat WORKSPACE
workspace(name = "myapp")
bind(name = "openssl", actual = "//:ssl")
http_archive(name = "alternative", ...)
http_archive(name = "boringssl", ...)
$ cat BUILD
config_setting(
name = "alt_ssl",
define_values = {
"ssl_library": "alternative",
},
)
alias(
name = "ssl",
actual = select({
"//:alt_ssl": "@alternative//:ssl",
"//conditions:default": "@boringssl//:ssl",
}),
)
透過這項設定,您可以傳遞 --define ssl_library=alternative
和任何目標
依附於 //:ssl
或 //external:ssl
的項目,就會看到替代
位於 @alternative//:ssl
。
不過,請停止使用 bind()
。
為什麼我的 select() 沒有選擇預期的內容?
如果 //myapp:foo
的 select()
未選擇您預期的條件,
使用 cquery 和 bazel config
進行偵錯:
如果 //myapp:foo
是您要建構的頂層目標,請執行:
$ bazel cquery //myapp:foo <desired build flags>
//myapp:foo (12e23b9a2b534a)
如果您要建立其他目標 //bar
,
//myapp:foo 在子圖表的某處,執行:
$ bazel cquery 'somepath(//bar, //myapp:foo)' <desired build flags>
//bar:bar (3ag3193fee94a2)
//bar:intermediate_dep (12e23b9a2b534a)
//myapp:foo (12e23b9a2b534a)
(12e23b9a2b534a)
旁邊的 //myapp:foo
是雜湊
設定該設定會解析 //myapp:foo
的 select()
您可以檢查
包含 bazel config
的值:
$ bazel config 12e23b9a2b534a
BuildConfigurationValue 12e23b9a2b534a
Fragment com.google.devtools.build.lib.analysis.config.CoreOptions {
cpu: darwin
compilation_mode: fastbuild
...
}
Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
linkopt: [-Dfoo=bar]
...
}
...
接著,將這個輸出內容與每個 config_setting
預期的設定進行比較。
//myapp:foo
可能會在同一個建構作業中處於不同設定。詳情請參閱
cquery 說明文件,瞭解如何使用 somepath
取得正確結果
第一。
為什麼 select()
不支援平台?
Bazel 不支援可設定屬性來檢查特定平台 是目標平台,因為語意不明確
例如:
platform(
name = "x86_linux_platform",
constraint_values = [
"@platforms//cpu:x86",
"@platforms//os:linux",
],
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":x86_linux_platform": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
在這個 BUILD
檔案中,如果目標平台同時擁有select()
@platforms//cpu:x86
和 @platforms//os:linux
限制條件,但「不是」
這裡已定義 :x86_linux_platform
?BUILD
檔案的作者和使用者
每個平台定義了獨立平台
可能會有不同的想法
我該怎麼做?
請改為定義 config_setting
,以符合任何平台,
這些限制:
config_setting(
name = "is_x86_linux",
constraint_values = [
"@platforms//cpu:x86",
"@platforms//os:linux",
],
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":is_x86_linux": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
這個程序定義了特定語意,讓使用者更清楚瞭解 滿足所需條件
如果我真的想要在平台上select
,該怎麼辦?
如果您的建構需求需要檢查平台,
可以翻轉 config_setting
中的 --platforms
旗標值:
config_setting(
name = "is_specific_x86_linux_platform",
values = {
"platforms": ["//package:x86_linux_platform"],
},
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":is_specific_x86_linux_platform": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
Bazel 團隊不會為此背書。會對建構造成太大影響 使用者會因預期狀況不符,而感到混淆。