「可設定屬性」(通常稱為 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，根據指令列的旗標來「選擇」依附元件。具體來說，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 上執行時，由於兩個分支版本都會解析為「hello」，因此這是不明確的 {"@platforms//os:linux": "Hello", "@platforms//cpu:x86_64": "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 (由於跨編譯後，可能與要為目標建構的 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。tool1 上的 select 會使用 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 = {"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",
],
)
您可以透過指令列指定平台。它會啟用包含平台 constraint_values 子集的 config_setting，以便在 select() 運算式中比對這些 config_setting。
舉例來說，如要將 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"],
}),
)
大多數條件都會評估相同的 dep，但這個語法難以讀取及維護。您不必多次重複 [":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
Skylib 的 selects 模組中的 with_or 巨集可直接在 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
Skylib 的 selects 模組中的 config_setting_group 巨集支援 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"],
}),
)
與 OR 鏈結不同，現有 config_setting 無法在 select 中直接 AND，您必須明確將其納入 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。因此，我們必須進行更多設計才能改變這一點。
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({
"//tools/target_cpu:x86": "first string",
"//tools/target_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({
"//tools/target_cpu:x86": "first string",
"//tools/target_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({
"//tools/target_cpu:x86": True,
"//tools/target_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 = {
"//tools/target_cpu:x86": "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() 是 WORKSPACE 規則，而非 BUILD 規則。
工作區規則沒有特定設定，且評估方式與 BUILD 規則相同。因此，bind() 中的 select() 無法實際評估為任何特定分支版本。
請改用 alias()，並搭配 actual 屬性中的 select()，執行這種類型的執行階段判斷作業。由於 alias() 是 BUILD 規則，且會透過特定設定進行評估，因此有效。
如有需要，您甚至可將 bind() 目標點設為 alias()。
$ 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 看到替代連結。
為什麼我的 select() 沒有選擇預期的內容？
如果 //myapp:foo 的 select() 未選擇您預期的條件，請使用 cquery 和 bazel config 進行偵錯：
如果 //myapp:foo 是您要建構的頂層目標，請執行：
$ bazel cquery //myapp:foo <desired build flags>
//myapp:foo (12e23b9a2b534a)
如要建構其他依附於子圖表 //myapp:foo 的其他目標 //bar，請執行：
$ bazel cquery 'somepath(//bar, //myapp:foo)' <desired build flags>
//bar:bar (3ag3193fee94a2)
//bar:intermediate_dep (12e23b9a2b534a)
//myapp:foo (12e23b9a2b534a)
//myapp:foo 旁邊的 (12e23b9a2b534a) 是解析 //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 可能會在同一個建構作業中處於不同設定。如要瞭解如何使用 somepath 取得正確的結果，請參閱 Cquery 說明文件。
為什麼 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": [],
}),
)
如果目標平台同時有 @platforms//cpu:x86 和 @platforms//os:linux 限制，但「不是」在這裡定義的 :x86_linux_platform，那麼在這個 BUILD 檔案中，應使用哪一個 select()？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 團隊不會為這件事背書，而是會過度限制您的建構作業，並在預期條件不符時讓使用者感到困惑。