การกำหนดค่า

รายงานปัญหา ดูแหล่งที่มา

หน้านี้ครอบคลุมประโยชน์และการใช้งานเบื้องต้นของการกำหนดค่า Starlark ซึ่งเป็น API ของ Bazel สำหรับการปรับแต่งวิธีการสร้างโครงการของคุณ รวมถึงวิธีกำหนดการตั้งค่าการสร้างและตัวอย่าง

วิธีนี้ช่วยให้คุณทำสิ่งต่อไปนี้ได้

  • ระบุแฟล็กที่กำหนดเองสำหรับโปรเจ็กต์ของคุณ ทำให้ไม่ต้องใช้ --define
  • เขียนการเปลี่ยนเพื่อกำหนดค่า Dep ในการกำหนดค่า ที่ต่างจากเวอร์ชันหลัก (เช่น --compilation_mode=opt หรือ --cpu=arm)
  • สร้างค่าเริ่มต้นที่ดีขึ้นลงในกฎ (เช่น สร้าง //my:android_app โดยอัตโนมัติด้วย SDK ที่ระบุ)

และอื่นๆ ทั้งหมดจากไฟล์ .bzl (ไม่จำเป็นต้องเผยแพร่ Bazel) ดูที่เก็บ bazelbuild/examples สำหรับตัวอย่าง

การตั้งค่าบิลด์ที่ผู้ใช้กำหนด

การตั้งค่าบิลด์คือข้อมูลการกำหนดค่าชิ้นเดียว ให้คิดว่าการกำหนดค่าเป็นแมปคีย์/ค่า การตั้งค่า --cpu=ppc และ --copt="-DFoo" จะสร้างการกำหนดค่าที่มีลักษณะดังนี้ {cpu: ppc, copt: "-DFoo"} โดยแต่ละรายการจะเป็นการตั้งค่าของเวอร์ชัน

แฟล็กแบบดั้งเดิม เช่น cpu และ copt เป็นการตั้งค่าแบบเนทีฟ โดยมีการกำหนดคีย์และค่าจะอยู่ในโค้ด JavaScript แบบเบเซล ผู้ใช้ Bazel จะอ่านและเขียนได้ผ่านบรรทัดคำสั่งและ API อื่นๆ ที่ดูแลรักษาในระบบเท่านั้น การเปลี่ยนแฟล็กเนทีฟและ API ที่เปิดเผยแฟล็กดังกล่าวต้องมีรุ่นเบเซล การตั้งค่าบิลด์ที่ผู้ใช้กำหนดจะกำหนดไว้ในไฟล์ .bzl (ดังนั้น จึงไม่จำเป็นต้องใช้รุ่นเบเซลเพื่อลงทะเบียนการเปลี่ยนแปลง) นอกจากนี้ยังตั้งค่าผ่านบรรทัดคำสั่งได้ (หากกำหนดไว้เป็น flags โปรดดูข้อมูลเพิ่มเติมด้านล่าง) และจะตั้งค่าผ่านการเปลี่ยนที่กำหนดโดยผู้ใช้ได้ด้วย

การกำหนดการตั้งค่าบิลด์

ตัวอย่างตั้งแต่ต้นจนจบ

พารามิเตอร์ build_setting rule()

การตั้งค่าบิลด์เป็นกฎต่างๆ เช่นเดียวกับกฎอื่นๆ และแยกความแตกต่างโดยใช้แอตทริบิวต์ build_setting ของฟังก์ชัน Starlark rule()

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

แอตทริบิวต์ build_setting ใช้ฟังก์ชันที่กำหนดประเภทของการตั้งค่าบิลด์ ประเภทนี้จำกัดเฉพาะชุดประเภท Starlark พื้นฐาน เช่น bool และ string ดูรายละเอียดในเอกสารโมดูล config คุณสามารถพิมพ์ที่ซับซ้อนขึ้น ได้ในฟังก์ชันการใช้งานของกฎ ดูข้อมูลเพิ่มเติมได้ที่ด้านล่าง

ฟังก์ชันของโมดูล config จะใช้พารามิเตอร์บูลีน (ไม่บังคับ) flag ซึ่งตั้งค่าเป็น "เท็จ" โดยค่าเริ่มต้น หากตั้งค่า flag เป็น "จริง" ผู้ใช้จะกำหนดการตั้งค่าบิลด์ในบรรทัดคำสั่งได้ รวมถึงแบบภายในโดยผู้เขียนกฎผ่านค่าเริ่มต้นและการเปลี่ยน ผู้ใช้ไม่ควรตั้งค่าบางอย่างได้ เช่น หากผู้เขียนกฎมีโหมดแก้ไขข้อบกพร่องที่ต้องการเปิดใช้กฎภายใน คุณไม่ควรให้ผู้ใช้เปิดใช้ฟีเจอร์ดังกล่าวในกฎอื่นๆ ที่ไม่ใช่การทดสอบโดยสุ่มเลือก

การใช้ ctx.build_setting_value

เช่นเดียวกับกฎทั้งหมด กฎการตั้งค่าการสร้างมีฟังก์ชันการใช้งาน ค่าประเภท Starlark พื้นฐานของการตั้งค่าบิลด์จะเข้าถึงได้ผ่านเมธอด ctx.build_setting_value วิธีนี้ใช้ได้เฉพาะกับออบเจ็กต์ 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 เพิ่มเติม ซึ่งทำให้สามารถตั้งค่าแฟล็กหลายครั้งในบรรทัดคำสั่งหรือใน bazelrcs ค่าเริ่มต้นของพวกเขาจะยังคง ถูกตั้งค่าด้วยแอตทริบิวต์ที่พิมพ์ด้วยสตริง ดังนี้

# 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",
)

ดูรายการทั้งหมดได้ที่กฎการตั้งค่าบิลด์ทั่วไป

การใช้การตั้งค่าบิลด์

ขึ้นอยู่กับการตั้งค่าบิลด์

หากเป้าหมายต้องการอ่านข้อมูลการกำหนดค่า เป้าหมายจะขึ้นอยู่กับการตั้งค่าบิลด์โดยตรงผ่านทรัพยากร Dependency ของแอตทริบิวต์ปกติ

# 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",
)

ภาษาอาจต้องการสร้างชุด Canonical ของการตั้งค่าบิลด์ที่กฎทั้งหมดสำหรับภาษานั้นต้องใช้ แม้ว่าแนวคิดดั้งเดิมของ 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

การใช้ชื่อแทนการตั้งค่าบิลด์

คุณจะตั้งค่าชื่อแทนสำหรับเส้นทางเป้าหมายการตั้งค่าบิลด์ได้ เพื่อให้อ่านบรรทัดคำสั่งได้ง่ายขึ้น ชื่อแทนทำงานคล้ายกับแฟล็กแบบเนทีฟและยังใช้ไวยากรณ์ตัวเลือกแบบขีด 2 ขีดด้วย

ตั้งค่าชื่อแทนโดยเพิ่ม --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 มีกฎในตัว 2 ข้อคือ 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() สามารถส่งเป้าหมายการตั้งค่าของบิลด์ไปยังแอตทริบิวต์ flag_values ของ config_setting ระบบจะส่งค่าที่จะจับคู่กับการกำหนดค่าเป็น String จากนั้นจะแยกวิเคราะห์เป็นประเภทของการตั้งค่าบิลด์สำหรับการจับคู่

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

การเปลี่ยนที่กำหนดโดยผู้ใช้

การเปลี่ยนการกำหนดค่าจะแมปการเปลี่ยนรูปแบบจากเป้าหมายหนึ่งไปยังเป้าหมายอื่นภายในกราฟบิลด์

นิยาม

การเปลี่ยนจะกำหนดการเปลี่ยนแปลงการกำหนดค่าระหว่างกฎต่างๆ เช่น การเปลี่ยนแปลงจะดำเนินการกับคำขออย่าง "คอมไพล์ทรัพยากร Dependency ของฉันสำหรับ CPU คนละตัวกับทรัพยากรระดับบนสุด"

อย่างเป็นทางการ การเปลี่ยนคือฟังก์ชันจากการกำหนดค่าอินพุตเป็นการกำหนดค่าเอาต์พุตอย่างน้อย 1 รายการ การเปลี่ยนส่วนใหญ่เป็นแบบ 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) ฟังก์ชันการใช้งานมีพารามิเตอร์ 2 ตัว ได้แก่ settings และ attr settings เป็นพจนานุกรม {String:Object} ของการตั้งค่าทั้งหมดที่ประกาศในพารามิเตอร์ inputs เป็น transition()

attr เป็นพจนานุกรมของแอตทริบิวต์และค่าของกฎที่แนบมากับการเปลี่ยน เมื่อแนบเป็นการเปลี่ยน EDGE ขาออก ค่าของแอตทริบิวต์เหล่านี้จะเป็นความละเอียดหลังการเลือก() ที่กำหนดค่าไว้ทั้งหมด เมื่อแนบเป็นการเปลี่ยน EDGE ขาเข้า attr จะไม่รวมแอตทริบิวต์ที่ใช้ตัวเลือกเพื่อแก้ไขค่า หากการเปลี่ยน EDGE ขาเข้าใน --foo อ่านแอตทริบิวต์ bar จากนั้นเลือก --foo เพื่อตั้งค่าแอตทริบิวต์ bar ด้วย ก็มีโอกาสที่การเปลี่ยน EDGE ขาเข้าอ่านค่า bar ที่ไม่ถูกต้องในการเปลี่ยน

ฟังก์ชันการใช้งานต้องแสดงพจนานุกรม (หรือรายการพจนานุกรม ในกรณีที่มีการเปลี่ยนโดยมีการกำหนดค่าเอาต์พุตหลายรายการ) ของค่าการตั้งค่าบิลด์ใหม่ที่จะใช้ ชุดคีย์พจนานุกรมที่แสดงผลต้องมีชุดการตั้งค่าบิลด์ที่ส่งไปยังพารามิเตอร์ outputs ของฟังก์ชันการเปลี่ยนทุกประการ ซึ่งจะเป็นเช่นนี้แม้ในกรณีที่ไม่มีการเปลี่ยนแปลงการตั้งค่าบิวด์ในช่วงการเปลี่ยนผ่านนี้ จะต้องมีการส่งค่าดั้งเดิมอย่างชัดเจนในพจนานุกรมที่แสดงผล

การกำหนดการเปลี่ยน 1:2+

ตัวอย่างตั้งแต่ต้นจนจบ

การเปลี่ยน Edge ขาออกสามารถจับคู่การกำหนดค่าอินพุตเดียวกับการกำหนดค่าเอาต์พุตตั้งแต่ 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"]
)

และยังสามารถตั้งค่าคีย์ที่กำหนดเองซึ่งฟังก์ชันการใช้งานกฎใช้เพื่ออ่านทรัพยากร Dependency แต่ละรายการได้ด้วย

# 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"]
)

กำลังแนบทรานซิชัน

ตัวอย่างตั้งแต่ต้นจนจบ

สามารถแนบทรานซิชันได้ 2 ที่ ได้แก่ ขอบขาเข้าและขอบขาออก ซึ่งหมายความว่ากฎจะเปลี่ยนการกำหนดค่าของตัวเอง (การเปลี่ยน EDGE ขาเข้า) และเปลี่ยนการกำหนดค่าของทรัพยากร Dependency (การเปลี่ยน EDGE ขาออก) ได้อย่างมีประสิทธิภาพ

หมายเหตุ: ขณะนี้ยังไม่มีวิธีแนบการเปลี่ยน Starlark เข้ากับกฎดั้งเดิม หากคุณจำเป็นต้องทำเช่นนั้น โปรดติดต่อ bazel-discuss@googlegroups.com เพื่อขอรับความช่วยเหลือเกี่ยวกับวิธีหาวิธีแก้ปัญหาเฉพาะหน้า

การเปลี่ยนขอบขาเข้า

เปิดใช้งานการเปลี่ยนขอบขาเข้าโดยแนบออบเจ็กต์ transition (สร้างโดย transition()) กับพารามิเตอร์ cfg ของ rule() ดังนี้

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

การเปลี่ยน Edge ขาเข้าต้องเป็นการเปลี่ยนแบบ 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)}
    ...

การเปลี่ยน Edge ขาออกอาจเป็นแบบ 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 ไม่รองรับการเปลี่ยนบน --define ด้วย "//command_line_option:define" โปรดใช้การตั้งค่างานสร้างที่กำหนดเองแทน โดยทั่วไปเราไม่แนะนำให้ใช้ --define ในรูปแบบใหม่ๆ เพื่อเปลี่ยนไปใช้การตั้งค่าของบิลด์

Bazel ไม่สนับสนุนการเปลี่ยนบน --config นั่นเป็นเพราะ --config เป็น Flag "การขยาย" ที่ขยายเป็น Flag อื่นๆ

ที่สำคัญ --config อาจรวมแฟล็กที่ไม่ส่งผลต่อการกำหนดค่าบิลด์ เช่น --spawn_strategy Bazel ออกแบบมาให้เชื่อมโยง Flag ดังกล่าวกับเป้าหมายแต่ละรายการไม่ได้ ซึ่งหมายความว่าไม่มีวิธีที่จะสอดคล้องกันในการเปลี่ยนแปลงที่จะเกิดขึ้น

ในการแก้ปัญหา คุณอาจระบุรายการแฟล็กที่เป็นส่วนหนึ่งของการกำหนดค่าในการเปลี่ยนของคุณอย่างชัดเจน โดยจะต้องรักษาการขยายของ --config ไว้ใน 2 ตำแหน่ง ซึ่งเป็นข้อบกพร่องของ 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"]
)

การเปลี่ยนแบบ No-op

หากการเปลี่ยนแสดงผล {}, [] หรือ 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",
    ]
)

การเข้าถึงแอตทริบิวต์ด้วยการเปลี่ยน

ตัวอย่างตั้งแต่ต้นจนจบ

เมื่อแนบการเปลี่ยนกับ Edge ขาออก (ไม่ว่าการเปลี่ยนจะเป็นแบบ 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 เพื่ออ่านค่า Dep แต่ละรายการของแต่ละคีย์ได้ ดังนี้

# 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 เกี่ยวข้องกับความละเอียดของ Toolchain ในอนาคต การเปลี่ยนการรายงานปัญหาประเภทนี้อย่างชัดเจนมักจะแทนที่ด้วยการเปลี่ยนในแพลตฟอร์มเป้าหมาย

ข้อควรพิจารณาเกี่ยวกับหน่วยความจำและประสิทธิภาพ

การเพิ่มการเปลี่ยนและการกำหนดค่าใหม่ให้กับบิลด์ของคุณมีค่าใช้จ่าย ได้แก่ กราฟบิลด์ที่ใหญ่ขึ้น กราฟบิลด์ที่เข้าใจได้ยากน้อยลง และการสร้างที่ช้ากว่า คุณควรพิจารณาถึงค่าใช้จ่ายเหล่านี้เมื่อพิจารณาใช้การเปลี่ยนในกฎการสร้าง ด้านล่างนี้เป็นตัวอย่างว่าการเปลี่ยนอาจสร้างการเติบโตแบบทวีคูณของกราฟบิลด์ได้อย่างไร

บิลด์ที่มีพฤติกรรมไม่เหมาะสม: กรณีศึกษา

กราฟความสามารถในการปรับขนาด

รูปที่ 1 กราฟความสามารถในการปรับขนาดแสดงเป้าหมายระดับบนสุดและทรัพยากร Dependency

กราฟนี้แสดงเป้าหมายระดับบนสุด //pkg:app ซึ่งขึ้นอยู่กับเป้าหมาย 2 รายการ คือ //pkg:1_0 และ //pkg:1_1 เป้าหมายทั้งสองนี้ขึ้นอยู่กับ 2 เป้าหมาย ได้แก่ //pkg:2_0 และ //pkg:2_1 เป้าหมายทั้งสองนี้ขึ้นอยู่กับ 2 เป้าหมาย ได้แก่ //pkg:3_0 และ //pkg:3_1 เหตุการณ์นี้จะดําเนินต่อไปจนถึงวันที่ //pkg:n_0 และ //pkg:n_1 ซึ่งทั้ง 2 รายการขึ้นอยู่กับเป้าหมายเดียว //pkg:dep

การสร้าง //pkg:app จำเป็นต้องมี \(2n+2\) เป้าหมาย

  • //pkg:app
  • //pkg:dep
  • //pkg:i_0 และ //pkg:i_1 สำหรับ \(i\) ใน \([1..n]\)

ลองจินตนาการว่าคุณimplementการแจ้งว่าไม่เหมาะสม --//foo:owner=<STRING> และ //pkg:i_b นำไปใช้

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

กล่าวคือ //pkg:i_b จะเติม b ต่อท้ายค่าเดิม --owner สำหรับค่า Dep ทั้งหมด

ซึ่งจะสร้างเป้าหมายที่กําหนดค่าไว้ต่อไปนี้

//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= "\(b_0b_1...b_n\)" สําหรับ \(b_i\) ใน \(\{0,1\}\)

ซึ่งทำให้กราฟบิลด์มีขนาดใหญ่กว่ากราฟเป้าหมายแบบทวีคูณ โดยมีหน่วยความจำและประสิทธิภาพที่เกี่ยวข้อง

สิ่งที่ต้องทำ: เพิ่มกลยุทธ์สำหรับการวัดผลและบรรเทาปัญหาเหล่านี้

อ่านเพิ่มเติม

โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการแก้ไขการกําหนดค่าบิลด์ที่หัวข้อต่อไปนี้