可設定的建構屬性

回報問題open_in_new 查看原始碼open_in_new 。 。 。 。 夜間 。 。 。 。 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({
        "//tools/target_cpu:x86": "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({
        "//tools/target_cpu:x86": "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({
        "//tools/target_cpu:x86": 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 = {
        "//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 規則。

Workspace 規則沒有特定設定，因此不會評估 與 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。

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