BazelCon 2024 註冊現已開放！

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

設定

7.3 · 7.2 · 7.1 · 7.0 · 6.5

本頁面將介紹 Starlark 設定的優點和基本用法，以及 Bazel 的 API，可用於自訂專案的建構方式。其中包含如何定義建構設定，並提供範例。

這麼做可讓您：

為專案定義自訂標記，不再需要使用 --define
撰寫轉場效果，以不同於父項的設定依附元件設定依附元件 (例如 --compilation_mode=opt 或 --cpu=arm)
將更好的預設值烘焙為規則 (例如使用指定 SDK 自動建構 //my:android_app)

等等，完全由 .bzl 檔案提供 (不需要 Bazel 版本)。請前往 bazelbuild/examples 存放區查看範例。

使用者定義的建構設定

建構設定是單一設定資訊。您可以將設定視為鍵/值對應。設定 --cpu=ppc 和 --copt="-DFoo" 會產生類似 {cpu: ppc, copt: "-DFoo"} 的設定。每個項目都是建構設定。

cpu 和 copt 等傳統旗標是原生設定，其鍵已定義，且值已在原生 Bazel Java 程式碼中設定。Bazel 使用者只能透過指令列和其他原生維護的 API 讀取及寫入這些檔案。如要變更原生旗標和公開這些旗標的 API，您必須使用 bazel 版本。使用者定義的建構設定會在 .bzl 檔案中定義 (因此不需要 Bazel 版本來註冊變更)。此外，您也可以透過指令列設定這些項目 (若已指定為 flags，詳情請見下文)，但也可以透過使用者定義的轉場效果進行設定。

定義建構設定

端對端範例

`build_setting` `rule()` 參數

建構設定是規則，與其他規則相同，可透過 Starlark rule() 函式的 build_setting 屬性進行區分。

# example/buildsettings/build_settings.bzl
string_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

build_setting 屬性會採用指定建構設定類型的函式。類型僅限於一組基本的 Starlark 類型，例如 bool 和 string。詳情請參閱 config 模組說明文件。而在規則的實作函式中，可以完成更複雜的輸入。詳情請見下文。

config 模組的函式採用選用的布林參數 flag (預設為 false)。如果 flag 設為 true，使用者也可以在指令列透過預設值和轉換，在指令列上設定建構設定。使用者不一定能調整所有設定。舉例來說，如果您是規則編寫者，並想在測試規則中啟用某些偵錯模式，那麼您不希望使用者在其他非測試規則中隨意啟用該功能。

使用 ctx.build_setting_value

和所有規則一樣，建構設定規則也有實作函式。您可以透過 ctx.build_setting_value 方法存取建構設定的基本 Starlark 類型值。這個方法僅適用於建構設定規則的 ctx 物件。這些實作方法可以直接轉送建構設定值，或對其執行其他工作，例如型別檢查或更複雜的結構體建立作業。以下說明如何實作 enum 型別的建構設定：

# example/buildsettings/build_settings.bzl
TemperatureProvider = provider(fields = ['type'])

temperatures = ["HOT", "LUKEWARM", "ICED"]

def _impl(ctx):
    raw_temperature = ctx.build_setting_value
    if raw_temperature not in temperatures:
        fail(str(ctx.label) + " build setting allowed to take values {"
             + ", ".join(temperatures) + "} but was set to unallowed value "
             + raw_temperature)
    return TemperatureProvider(type = raw_temperature)

temperature = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

定義多重字串標記

字串設定有額外的 allow_multiple 參數，可在指令列或 bazelrc 中設定多次標記。其預設值仍會使用字串型屬性設定：

# example/buildsettings/build_settings.bzl
allow_multiple_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True, allow_multiple = True)
)

# example/BUILD
load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
allow_multiple_flag(
    name = "roasts",
    build_setting_default = "medium"
)

系統會將標記的各項設定視為單一值：

$ bazel build //my/target --//example:roasts=blonde \
    --//example:roasts=medium,dark

上述內容剖析為 {"//example:roasts": ["blonde", "medium,dark"]}，ctx.build_setting_value 則會傳回 ["blonde", "medium,dark"] 清單。

建構設定的例項化

使用 build_setting 參數定義的規則具有隱含的必要 build_setting_default 屬性。這個屬性會採用 build_setting 參數所宣告的類型。

# example/buildsettings/build_settings.bzl
FlavorProvider = provider(fields = ['type'])

def _impl(ctx):
    return FlavorProvider(type = ctx.build_setting_value)

flavor = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

# example/BUILD
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
    name = "favorite_flavor",
    build_setting_default = "APPLE"
)

預先定義的設定

端對端範例

Skylib 程式庫包含一組預先定義的設定，您可以例項化，不必寫入自訂 Starlark。

舉例來說，如要定義可接受有限字串值集合的設定，請按照下列步驟操作：

# example/BUILD
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
string_flag(
    name = "myflag",
    values = ["a", "b", "c"],
    build_setting_default = "a",
)

如需完整清單，請參閱「常見建構設定規則」。

使用建構設定

視建構設定而定

如果目標想讀取設定資訊，可以透過一般屬性依附元件直接依附建構設定。

# example/rules.bzl
load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
def _rule_impl(ctx):
    if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
        ...

drink_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "flavor": attr.label()
    }
)

# example/BUILD
load("//example:rules.bzl", "drink_rule")
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
    name = "favorite_flavor",
    build_setting_default = "APPLE"
)
drink_rule(
    name = "my_drink",
    flavor = ":favorite_flavor",
)

語言可能會想要建立一組標準的建構設定，所有該語言的規則都會依賴這些設定。雖然 fragments 的原生概念不再以硬式編碼物件的形式存在於 Starlark 設定世界中，但要轉譯這個概念的方法之一是使用一組常見的隱含屬性。例如：

# kotlin/rules.bzl
_KOTLIN_CONFIG = {
    "_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
    "_mode": attr.label(default = "//kotlin/config:mode-flag"),
    ...
}

...

kotlin_library = rule(
    implementation = _rule_impl,
    attrs = dicts.add({
        "library-attr": attr.string()
    }, _KOTLIN_CONFIG)
)

kotlin_binary = rule(
    implementation = _binary_impl,
    attrs = dicts.add({
        "binary-attr": attr.label()
    }, _KOTLIN_CONFIG)

在指令列中使用建構設定

與大多數原生標記類似，您可以使用指令列設定標示為標記的建構設定。建構設定的名稱是使用 name=value 語法的完整目標路徑：

$ bazel build //my/target --//example:string_flag=some-value # allowed
$ bazel build //my/target --//example:string_flag some-value # not allowed

支援特殊布林語法：

$ bazel build //my/target --//example:boolean_flag
$ bazel build //my/target --no//example:boolean_flag

使用建構設定別名

您可以為建構設定目標路徑設定別名，讓指令列更容易閱讀。別名的功能與原生標記類似，也可以使用雙破折號選項語法。

透過將 --flag_alias=ALIAS_NAME=TARGET_PATH 新增至 .bazelrc 來設定別名。舉例來說，如要將別名設為 coffee，請按照下列步驟操作：

# .bazelrc
build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp

最佳做法：多次設定別名會導致最近設定的別名優先。請使用不重複的別名名稱，避免產生非預期的剖析結果。

如要使用別名，請將其輸入建構設定目標路徑的位置。在上述範例中，coffee 已在使用者的 .bazelrc 中設定：

$ bazel build //my/target --coffee=ICED

而非

$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED

最佳做法：雖然您可以在指令列上設定別名，但將別名留在 .bazelrc 中，可減少指令列的雜亂。

標籤型建構設定

端對端範例

與其他建構設定不同，標籤類型設定無法使用 build_setting 規則參數定義。相反地，bazel 有兩個內建規則：label_flag 和 label_setting。這些規則會轉送建構設定所設目標的供應器，label_flag 和 label_setting 可由轉場讀取/寫入，而 label_flag 可由使用者設定，就像其他 build_setting 規則一樣。唯一的差異在於無法自訂定義。

「標籤類型」設定最終會取代晚期預設設定的功能。延遲繫結的預設屬性為「標籤」類型的屬性，其最終值可受設定影響。在 Starlark 中，這會取代 configuration_field API。

# example/rules.bzl
MyProvider = provider(fields = ["my_field"])

def _dep_impl(ctx):
    return MyProvider(my_field = "yeehaw")

dep_rule = rule(
    implementation = _dep_impl
)

def _parent_impl(ctx):
    if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
        ...

parent_rule = rule(
    implementation = _parent_impl,
    attrs = { "my_field_provider": attr.label() }
)

# example/BUILD
load("//example:rules.bzl", "dep_rule", "parent_rule")

dep_rule(name = "dep")

parent_rule(name = "parent", my_field_provider = ":my_field_provider")

label_flag(
    name = "my_field_provider",
    build_setting_default = ":dep"
)

建構設定和 select()

端對端範例

使用者可以透過 select()，在建構設定中設定屬性。建構設定目標可傳遞至 config_setting 的 flag_values 屬性。用來比對的值會以 String 的形式傳遞，然後剖析為建構設定的類型來進行比對。

config_setting(
    name = "my_config",
    flag_values = {
        "//example:favorite_flavor": "MANGO"
    }
)

使用者定義的轉場效果

設定轉換會將從一個已設定的目標到另一個目標的轉換對應至建構圖表。

設定這些屬性的規則必須包含特殊屬性：

  "_allowlist_function_transition": attr.label(
      default = "@bazel_tools//tools/allowlists/function_transition_allowlist"
  )

只要新增轉場效果，您就能輕鬆擴大建構圖表的大小。這會針對您可以建立這項規則目標的套件設定許可清單。上方程式碼區塊中的預設值會將所有項目加入許可清單。不過，如果您想限制誰可以使用規則，可以將該屬性設為指向自訂許可清單。如果您想提供建議或協助，瞭解轉換會對建構效能造成哪些影響，請與 bazel-discuss@googlegroups.com 聯絡。

定義

轉換會定義規則之間的設定變更。舉例來說，如果要求是「為與其父項不同的 CPU 編譯我的依附元件」，則會由轉換處理。

從形式上來說，轉場是從輸入設定到一個或多個輸出設定的函式。多數轉場效果會是 1:1，例如「使用 --cpu=ppc 覆寫輸入設定」。此外，也可以有 1:2 以上的轉場效果，但會有特殊限制。

在 Starlark 中，轉換的定義方式與規則類似，其中包含定義 transition() 函式和實作函式。

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {"//example:favorite_flavor" : "MINT"}

hot_chocolate_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

transition() 函式會接收實作函式、一組要讀取的建構設定 (inputs)，以及一組要寫入的建構設定 (outputs)。實作函式有兩個參數：settings 和 attr。settings 是所有在 inputs 參數中宣告為 transition() 的字典 {String:Object}。

attr 是轉場附加的規則屬性和值的字典。當這些屬性連結為傳出邊緣轉場時，系統會在 select() 解析後設定這些屬性的值。當 attr 以傳入邊緣轉移形式附加時，不會包含任何使用選取器解析值的屬性。如果 --foo 上的傳入邊緣轉場讀取屬性 bar，然後也選取 --foo 來設定屬性 bar，那麼傳入邊緣轉場有可能會在轉場中讀取錯誤的 bar 值。

實作函式必須傳回要套用的新建構設定值的字典 (或字典清單，若有多種輸出設定則適用)。傳回的字典鍵組必須完全包含傳遞至轉換函式 outputs 參數的建構設定組合。即使在轉換過程中，實際上並未變更建構設定，也必須在傳回的字典中明確傳遞原始值。

定義 1:2 以上的轉換

端對端範例

傳出邊緣轉場可將單一輸入設定對應至兩個以上的輸出設定。如要定義組合多架構程式碼的規則，這就非常實用。

1:2+ 轉場效果的定義方式，是在轉場實作函式中傳回字典清單。

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return [
        {"//example:favorite_flavor" : "LATTE"},
        {"//example:favorite_flavor" : "MOCHA"},
    ]

coffee_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

您也可以設定自訂鍵，讓規則實作函式用來讀取個別依附元件：

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {
        "Apple deps": {"//command_line_option:cpu": "ppc"},
        "Linux deps": {"//command_line_option:cpu": "x86"},
    }

multi_arch_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]
)

附加轉場效果

端對端範例

轉場效果可附加在兩個位置：進入邊和離開邊。這意味著規則可以轉換自身的設定 (傳入邊緣轉移)，以及轉換其依附元件的設定 (傳出邊緣轉移)。

注意：目前無法將 Starlark 轉換附加至原生規則。如果需要這樣做，請聯絡 bazel-discuss@googlegroups.com，以協助您找出解決方法。

傳入邊緣轉場

如要啟用傳入邊緣轉場效果，請將 transition 物件 (由 transition() 建立) 附加至 rule() 的 cfg 參數：

# example/rules.bzl
load("example/transitions:transitions.bzl", "hot_chocolate_transition")
drink_rule = rule(
    implementation = _impl,
    cfg = hot_chocolate_transition,
    ...

傳入邊緣的轉場效果必須是 1:1 轉場效果。

傳出邊緣轉場效果

如要啟用傳出邊緣轉場效果，請將 transition 物件 (由 transition() 建立) 附加至屬性的 cfg 參數：

# example/rules.bzl
load("example/transitions:transitions.bzl", "coffee_transition")
drink_rule = rule(
    implementation = _impl,
    attrs = { "dep": attr.label(cfg = coffee_transition)}
    ...

外向邊緣轉場可為 1:1 或 1:2 以上。

如要瞭解如何讀取這些鍵，請參閱「透過轉場存取屬性」一文。

原生選項轉換

端對端範例

Starlark 轉換還可透過選項名稱的特殊前置字串，宣告原生建構設定選項的讀取和寫入作業。

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {"//command_line_option:cpu": "k8"}

cpu_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]

不支援的原生選項

Bazel 不支援使用 "//command_line_option:define" 在 --define 上進行轉換。請改用自訂建構設定。一般來說，我們不建議您使用 --define 的新用途，而是建議使用建構設定。

Bazel 不支援在 --config 上轉換。這是因為 --config 是「展開」旗標，可展開至其他旗標。

重要的是，--config 可能會包含不會影響建構設定的標記，例如 --spawn_strategy。根據 Bazel 的設計，無法將這類標記繫結至個別目標。這表示在轉場中套用這些效果並無一致性。

解決方法是明確列出轉場效果中「屬於」設定的標記。這需要在兩個地方維護 --config 的展開方式，而這正是已知的 UI 瑕疵。

啟用多個建構設定的轉換

如要調整允許多個值的建構設定，則必須使用清單設定該設定的值。

# example/buildsettings/build_settings.bzl
string_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True, allow_multiple = True)
)

# example/BUILD
load("//example/buildsettings:build_settings.bzl", "string_flag")
string_flag(name = "roasts", build_setting_default = "medium")

# example/transitions/rules.bzl
def _transition_impl(settings, attr):
    # Using a value of just "dark" here will throw an error
    return {"//example:roasts" : ["dark"]},

coffee_transition = transition(
    implementation = _transition_impl,
    inputs = [],
    outputs = ["//example:roasts"]
)

無操作轉換

如果轉場傳回 {}、[] 或 None，則表示系統會將所有設定保留為原始值。這比明確將每個輸出內容設為自身更方便。

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (attr)
    if settings["//example:already_chosen"] is True:
      return {}
    return {
      "//example:favorite_flavor": "dark chocolate",
      "//example:include_marshmallows": "yes",
      "//example:desired_temperature": "38C",
    }

hot_chocolate_transition = transition(
    implementation = _impl,
    inputs = ["//example:already_chosen"],
    outputs = [
        "//example:favorite_flavor",
        "//example:include_marshmallows",
        "//example:desired_temperature",
    ]
)

透過轉換存取屬性

端對端範例

將轉場效果附加至傳出邊緣時 (無論轉場效果是 1:1 還是 1:2+ 轉場效果)，如果 ctx.attr 不是清單，系統會強制將其設為清單。系統未指定這份清單中的元素順序。

# example/transitions/rules.bzl
def _transition_impl(settings, attr):
    return {"//example:favorite_flavor" : "LATTE"},

coffee_transition = transition(
    implementation = _transition_impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

def _rule_impl(ctx):
    # Note: List access even though "dep" is not declared as list
    transitioned_dep = ctx.attr.dep[0]

    # Note: Access doesn't change, other_deps was already a list
    for other_dep in ctx.attr.other_deps:
      # ...


coffee_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "dep": attr.label(cfg = coffee_transition)
        "other_deps": attr.label_list(cfg = coffee_transition)
    })

如果轉場是 1:2+ 且設定自訂鍵，可以使用 ctx.split_attr 讀取每個鍵的個別依附元件：

# example/transitions/rules.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {
        "Apple deps": {"//command_line_option:cpu": "ppc"},
        "Linux deps": {"//command_line_option:cpu": "x86"},
    }

multi_arch_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]
)

def _rule_impl(ctx):
    apple_dep = ctx.split_attr.dep["Apple deps"]
    linux_dep = ctx.split_attr.dep["Linux deps"]
    # ctx.attr has a list of all deps for all keys. Order is not guaranteed.
    all_deps = ctx.attr.dep

multi_arch_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "dep": attr.label(cfg = multi_arch_transition)
    })

請參閱完整範例。

與平台和工具鍊整合

許多現今的原生旗標 (例如 --cpu 和 --crosstool_top) 都與工具鏈解析有關。日後，這些類型的旗標上明確的轉場效果，可能會由目標平台上的轉場效果取代。

記憶體和效能考量事項

在建構作業中加入轉場效果，也就是新增設定，會帶來一些成本：建構圖表會變大、不易理解，且建構速度會變慢。在建構規則中使用轉場效果時，請考量這些成本。以下是轉場效果可能導致建構圖表呈現指數型成長的例子。

不良行為版本：個案研究

可擴充性圖表

圖 1. 可擴充性圖表，顯示頂層目標及其依附元件。

此圖表顯示頂層目標 //pkg:app，該目標依賴兩個目標：//pkg:1_0 和 //pkg:1_1。這兩個目標都依賴 //pkg:2_0 和 //pkg:2_1 這兩個目標。這兩個目標都依賴 //pkg:3_0 和 //pkg:3_1 這兩個目標。這會持續進行，直到 //pkg:n_0 和 //pkg:n_1 為止，這兩者都會依賴單一目標 //pkg:dep。

建構 //pkg:app 需要 \(2n+2\) 目標：

//pkg:app
//pkg:dep
\(i\) 在 \([1..n]\)中的 //pkg:i_0 和 //pkg:i_1

假設您實作旗標 --//foo:owner=<STRING>，並套用 //pkg:i_b

depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"

換句話說，//pkg:i_b 會將 b 附加至所有依附元件的舊值 --owner。

這會產生以下已設定的目標：

//pkg:app                              //foo:owner=""
//pkg:1_0                              //foo:owner=""
//pkg:1_1                              //foo:owner=""
//pkg:2_0 (via //pkg:1_0)              //foo:owner="0"
//pkg:2_0 (via //pkg:1_1)              //foo:owner="1"
//pkg:2_1 (via //pkg:1_0)              //foo:owner="0"
//pkg:2_1 (via //pkg:1_1)              //foo:owner="1"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_0)  //foo:owner="00"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_1)  //foo:owner="01"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_0)  //foo:owner="10"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_1)  //foo:owner="11"
...

//pkg:dep 會產生已設定 \(2^n\) 的目標：config.owner= 和 \(\{0,1\}\)中所有 \(b_i\) 的「\(b_0b_1...b_n\)」。

這會使建構圖表的大小以指數級數超越目標圖表，並產生相應的記憶體和效能後果。

TODO：新增評估和緩解這些問題的策略。

延伸閱讀

如要進一步瞭解如何修改建構設定，請參閱：

設定

使用者定義的建構設定

定義建構設定

build_setting rule() 參數

使用 ctx.build_setting_value

定義多重字串標記

建構設定的例項化

預先定義的設定

使用建構設定

視建構設定而定

在指令列中使用建構設定

使用建構設定別名

標籤型建構設定

建構設定和 select()

使用者定義的轉場效果

定義

定義 1:2 以上的轉換

附加轉場效果

傳入邊緣轉場

傳出邊緣轉場效果

原生選項轉換

不支援的原生選項

啟用多個建構設定的轉換

無操作轉換

透過轉換存取屬性

與平台和工具鍊整合

記憶體和效能考量事項

不良行為版本：個案研究

延伸閱讀

`build_setting` `rule()` 參數