หน้านี้ครอบคลุมประโยชน์และการใช้งานเบื้องต้นของการกำหนดค่า 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/buildsettings/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/buildsettings/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"
}
)
การเปลี่ยนที่กำหนดโดยผู้ใช้
การเปลี่ยนการกำหนดค่าจะแมปการเปลี่ยนรูปแบบจากเป้าหมายหนึ่งไปยังเป้าหมายอื่นภายในกราฟบิลด์
กฎที่ตั้งค่าต้องมีแอตทริบิวต์พิเศษ ดังนี้
"_allowlist_function_transition": attr.label(
default = "@bazel_tools//tools/allowlists/function_transition_allowlist"
)
การเพิ่มทรานซิชันจะทำให้คุณสามารถทำให้กราฟบิลด์ของคุณเติบโตได้ง่าย การดำเนินการนี้จะกำหนดรายการที่อนุญาตของแพ็กเกจที่คุณสร้างเป้าหมายของกฎนี้ได้ ค่าเริ่มต้นใน Codeblock ด้านบน จะแสดงได้ทุกอย่าง แต่หากต้องการจำกัดผู้ที่ใช้กฎ คุณสามารถตั้งค่าแอตทริบิวต์นั้นให้ชี้ไปยังรายการที่อนุญาตที่กำหนดเองได้ โปรดติดต่อ bazel-discuss@googlegroups.com หากต้องการคำแนะนำหรือความช่วยเหลือ ในการทำความเข้าใจว่าการเปลี่ยนจะส่งผลต่อประสิทธิภาพของบิวด์อย่างไร
นิยาม
การเปลี่ยนจะกำหนดการเปลี่ยนแปลงการกำหนดค่าระหว่างกฎต่างๆ เช่น การเปลี่ยนแปลงจะดำเนินการกับคำขออย่าง "คอมไพล์ทรัพยากร 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 เป้าหมายทั้งสองนี้ขึ้นอยู่กับสองเป้าหมาย ได้แก่ //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
//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\}\)
ซึ่งทำให้กราฟบิลด์มีขนาดใหญ่กว่ากราฟเป้าหมายแบบทวีคูณ โดยมีหน่วยความจำและประสิทธิภาพที่เกี่ยวข้อง
สิ่งที่ต้องทำ: เพิ่มกลยุทธ์สำหรับการวัดผลและบรรเทาปัญหาเหล่านี้
อ่านเพิ่มเติม
โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการแก้ไขการกําหนดค่าบิลด์ที่หัวข้อต่อไปนี้
- การกำหนดค่าบิลด์ของ Starlark
- แผนกลยุทธ์การกำหนดค่า Bazel
- ตัวอย่างทั้งหมดชุดตั้งแต่ต้นจนจบ