BazelCon 2024 註冊現已開放！

本頁面由 Cloud Translation API 翻譯而成。

可設定的建構屬性

回報問題查看來源。。。。夜間。。。。 7.3 。。 7.2 。。 7.1 。。 7.0 。。 6.5 。。

可設定屬性 (通常稱為 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 規則，而會以特定設定

如有需要，您甚至可將 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。

不過，請停止使用 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 團隊不會為此背書。會對建構造成太大影響使用者會因預期狀況不符，而感到混淆。