กฎ
ชื่อแทน
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
กฎ alias
จะสร้างชื่ออื่นที่อาจเรียกว่ากฎ
ส่วนชื่อแทนจะใช้ได้กับเป้าหมาย "ปกติ" เท่านั้น โดยเฉพาะอย่างยิ่ง ชื่อแทน package_group
และ test_suite
ไม่ได้
กฎของชื่อแทนมีการประกาศระดับการเข้าถึงของตัวเอง ในด้านอื่นๆ ทั้งหมด กฎจะทำงานเหมือนกับกฎที่อ้างอิง (เช่น ระบบจะไม่สนใจ testonly ในชื่อแทน และจะใช้เพียงการทดสอบเท่านั้นของกฎที่อ้างอิงแทน) โดยมีข้อยกเว้นเล็กน้อยดังต่อไปนี้
-
การทดสอบจะไม่ทำงานหากมีการพูดถึงชื่อแทนในบรรทัดคำสั่ง หากต้องการกำหนดชื่อแทนที่เรียกใช้การทดสอบที่อ้างอิง ให้ใช้กฎ
test_suite
ที่มีเป้าหมายเดียวในแอตทริบิวต์tests
-
เมื่อกำหนดกลุ่มสภาพแวดล้อม ระบบจะไม่รองรับชื่อแทนของกฎ
environment
ซึ่งใช้ไม่ได้กับตัวเลือกบรรทัดคำสั่ง--target_environment
เช่นกัน
ตัวอย่าง
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
actual
|
|
config_setting
config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
จับคู่สถานะการกำหนดค่าที่คาดหวัง (แสดงเป็นแฟล็กบิลด์หรือข้อจำกัดแพลตฟอร์ม) เพื่อ ทริกเกอร์แอตทริบิวต์ที่กำหนดค่าได้ ดูวิธีใช้กฎนี้และ แอตทริบิวต์ที่กำหนดค่าได้ในส่วนเลือกเพื่อดูภาพรวมของฟีเจอร์ทั่วไป
ตัวอย่าง
รายการต่อไปนี้ตรงกับบิลด์ทั้งหมดที่ตั้งค่า --compilation_mode=opt
หรือ -c opt
(โดยชัดแจ้งที่บรรทัดคำสั่งหรือโดยปริยายจากไฟล์ .bazelrc)
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
รายการต่อไปนี้ตรงกับบิลด์ใดก็ตามที่กำหนดเป้าหมายเป็น ARM และใช้ FOO=bar
คำจำกัดความที่กำหนดเอง (เช่น bazel build --cpu=arm --define FOO=bar ...
)
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
รายการต่อไปนี้ตรงกับบิลด์ใดๆ ที่ตั้งค่าแฟล็กที่ผู้ใช้กำหนด
--//custom_flags:foo=1
(โดยชัดแจ้งที่บรรทัดคำสั่งหรือโดยนัยจากไฟล์ .bazelrc)
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
รายการต่อไปนี้ตรงกับบิลด์ทั้งหมดที่กำหนดเป้าหมายแพลตฟอร์มด้วยสถาปัตยกรรม x86_64 และ glibc เวอร์ชัน 2.25 โดยสมมติว่ามี constraint_value
ที่มีป้ายกำกับ //example:glibc_2_25
อยู่ โปรดทราบว่าแพลตฟอร์มจะยังคงตรงกันหากกำหนดค่าข้อจำกัดเพิ่มเติมที่นอกเหนือจาก 2 ค่านี้
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )ในทุกกรณีเหล่านี้ การกำหนดค่าจะเปลี่ยนแปลงภายในบิลด์ได้ เช่น ในกรณีที่ต้องสร้างเป้าหมายสำหรับแพลตฟอร์มอื่นที่ไม่ตรงกับระดับของแพลตฟอร์ม ซึ่งหมายความว่าแม้ว่า
config_setting
จะไม่ตรงกับแฟล็กบรรทัดคำสั่งระดับบนสุด แต่ก็อาจยังคงตรงกับเป้าหมายบิลด์บางรายการ
Notes
- ดู select สำหรับสิ่งที่จะเกิดขึ้นเมื่อ
config_setting
หลายรายการตรงกับสถานะการกำหนดค่าปัจจุบัน - สำหรับแฟล็กที่รองรับรูปแบบชวเลข (เช่น
--compilation_mode
กับ-c
) คำจำกัดความของvalues
ต้องใช้แบบฟอร์มแบบเต็ม ซึ่งจะจับคู่คำขอโดยอัตโนมัติโดยใช้แบบฟอร์มใดรูปแบบหนึ่ง -
หากแฟล็กมีค่าหลายค่า (เช่น
--copt=-Da --copt=-Db
หรือ แฟล็ก Starlark ที่เป็นประเภทรายการ)values = { "flag": "a" }
จะจับคู่หาก"a"
ปรากฏที่ใดก็ตามในรายการจริงvalues = { "myflag": "a,b" }
ทำงานในลักษณะเดียวกัน: จะจับคู่กับ--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
และ--myflag=c,b,a
ความหมายที่แน่นอนจะแตกต่างกันไปในแต่ละแฟล็ก เช่น--copt
ไม่รองรับหลายค่าในอินสแตนซ์เดียวกัน นั่นคือ--copt=a,b
จะสร้าง["a,b"]
ในขณะที่--copt=a --copt=b
จะสร้าง["a", "b"]
(เพื่อให้values = { "copt": "a,b" }
จับคู่กับค่าแรกแต่ไม่จับคู่กับค่าหลัง) แต่--ios_multi_cpus
(สำหรับกฎของ Apple) จะ:-ios_multi_cpus=a,b
และios_multi_cpus=a --ios_multi_cpus=b
ทั้ง 2 อย่างจะให้ผลลัพธ์["a", "b"]
ตรวจสอบคำจำกัดความของแฟล็กและทดสอบเงื่อนไขอย่างรอบคอบเพื่อยืนยันความคาดหวังที่แน่นอน - หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างโมเดลโดยแฟล็กบิลด์ในตัว ให้ใช้
แฟล็กที่ Starlark กำหนด นอกจากนี้คุณยังใช้
--define
ได้ด้วย แต่วิธีนี้ทำให้การสนับสนุนไม่ดีนักและไม่แนะนำให้ใช้ ดูการสนทนาเพิ่มเติมที่นี่ - หลีกเลี่ยงการใช้คำจำกัดความ
config_setting
ที่ซ้ำกันในแพ็กเกจที่ต่างกัน แต่ให้อ้างอิงconfig_setting
ทั่วไปที่กำหนดไว้ในแพ็กเกจ Canonical แทน - คุณใช้
values
,define_values
และconstraint_values
ร่วมกับชุดค่าผสมใดก็ได้ในconfig_setting
เดียวกัน แต่ต้องมีการตั้งค่าอย่างน้อย 1 รายการสำหรับconfig_setting
ใดๆ ที่กำหนด
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
constraint_values
|
constraint_values ขั้นต่ำที่แพลตฟอร์มเป้าหมายต้องระบุเพื่อให้ตรงกับ config_setting นี้ (แพลตฟอร์มการดำเนินการจะไม่พิจารณาที่นี่) และจะไม่สนใจค่าข้อจำกัดเพิ่มเติมใดๆ ที่แพลตฟอร์มไม่สนใจ ดูรายละเอียดได้ที่
แอตทริบิวต์บิลด์ที่กำหนดค่าได้
ในกรณีที่ 2 |
define_values
|
values แต่สำหรับแฟล็ก --define โดยเฉพาะ
ซึ่งหมายความว่า config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) ไม่ทำงานเนื่องจากคีย์เดียวกัน ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) ตรงกับ
|
flag_values
|
values แต่ใช้กับ
แฟล็กบิลด์ที่กำหนดโดยผู้ใช้
นี่คือแอตทริบิวต์ที่แตกต่างกัน เนื่องจากมีการอ้างอิงแฟล็กที่ผู้ใช้กำหนดเป็นป้ายกำกับ ขณะที่การแฟล็กในตัวจะอ้างอิงเป็นสตริงที่กำหนดเอง |
values
|
กฎนี้รับค่าจากเป้าหมายที่กำหนดค่าซึ่งอ้างอิงเป้าหมายในคำสั่ง เพื่อความสะดวก ค่าของการกำหนดค่าจะระบุเป็นแฟล็กบิลด์ (โดยไม่มี หากไม่ได้กำหนดแฟล็กอย่างชัดแจ้งในบรรทัดคำสั่ง ระบบจะใช้ค่าเริ่มต้น
หากคีย์ปรากฏขึ้นหลายครั้งในพจนานุกรม ระบบจะใช้เฉพาะอินสแตนซ์สุดท้ายเท่านั้น
หากคีย์อ้างอิงแฟล็กที่ตั้งค่าได้หลายครั้งในบรรทัดคำสั่ง (เช่น
|
กลุ่มไฟล์
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
ใช้ filegroup
เพื่อตั้งชื่อที่สะดวกสำหรับชุดเป้าหมาย
จากนั้นจะอ้างอิงจากกฎอื่นๆ ได้
เราขอแนะนำให้ใช้ filegroup
แทนการอ้างอิงไดเรกทอรีโดยตรง
เวอร์ชันหลังไม่มีเสียงเนื่องจากระบบบิลด์ไม่มีความรู้ที่สมบูรณ์เกี่ยวกับไฟล์ทั้งหมดที่อยู่ใต้ไดเรกทอรี ระบบจึงสร้างใหม่ไม่ได้เมื่อไฟล์เหล่านี้มีการเปลี่ยนแปลง เมื่อใช้ร่วมกับ glob filegroup
จะทำให้ระบบของบิลด์รู้จักไฟล์ทั้งหมดได้อย่างชัดเจน
ตัวอย่าง
หากต้องการสร้าง filegroup
ที่ประกอบด้วยไฟล์ต้นฉบับ 2 ไฟล์ ให้ทำ
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
หรือใช้ glob
เพื่อค้นหาไดเรกทอรี testdata:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
หากต้องการใช้คําจํากัดความเหล่านี้ ให้อ้างอิง filegroup
ที่มีป้ายกํากับจากกฎใดๆ ต่อไปนี้
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
srcs
|
เป็นเรื่องปกติที่จะใช้ผลลัพธ์ของนิพจน์ glob สำหรับค่าของแอตทริบิวต์ |
data
|
ระบบจะเพิ่มเป้าหมายที่มีชื่อในแอตทริบิวต์ |
output_group
|
"กลุ่มเอาต์พุต" คือหมวดหมู่อาร์ติแฟกต์เอาต์พุตของเป้าหมายที่ระบุไว้ในการใช้งานกฎดังกล่าว |
Genquery
genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
genquery()
เรียกใช้การค้นหาที่ระบุในภาษาของการค้นหา Blaze และดัมพ์ผลลัพธ์ลงในไฟล์
ระบบจะอนุญาตให้การค้นหาเข้าชมการปิดเป้าหมายที่ระบุในแอตทริบิวต์ scope
เท่านั้นเพื่อให้บิลด์สอดคล้องกัน การค้นหาที่ละเมิดกฎนี้จะดำเนินการไม่สำเร็จหากไม่ได้ระบุ strict
หรือเป็นจริง (หาก strict
เป็นเท็จ ระบบจะข้ามเป้าหมายที่อยู่นอกขอบเขตพร้อมแสดงคำเตือน) วิธีที่ง่ายที่สุดที่จะป้องกันปัญหานี้คือการพูดถึงป้ายกำกับเดียวกันในขอบเขตในนิพจน์การค้นหา
ความแตกต่างเพียงอย่างเดียวระหว่างการค้นหาที่อนุญาตที่นี่และในบรรทัดคำสั่งคือคำค้นหาที่มีข้อกำหนดเฉพาะเป้าหมายไวลด์การ์ด (เช่น //pkg:*
หรือ //pkg:all
) ไม่ได้รับอนุญาตที่นี่
เหตุผลของการค้นหานี้มี 2 แบบ ดังนี้ เนื่องจาก genquery
ต้องระบุขอบเขตเพื่อป้องกันไม่ให้เป้าหมายที่อยู่นอกการปิดแบบทรานซิทีฟของการค้นหามีผลต่อผลลัพธ์ และข้อที่ 2 คือเนื่องจากไฟล์ BUILD
ไม่รองรับการอ้างอิงไวลด์การ์ด (เช่น ไม่อนุญาต deps=["//a/..."]
)
เอาต์พุตของ genquery จะเรียงลำดับโดยใช้ --order_output=full
เพื่อบังคับใช้เอาต์พุตเชิงกำหนด
ชื่อของไฟล์เอาต์พุตคือชื่อของกฎ
ตัวอย่าง
ตัวอย่างนี้เขียนรายการป้ายกำกับในการปิดทางอ้อมของเป้าหมายที่ระบุไปยังไฟล์
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
expression
|
:b ในแอตทริบิวต์นี้ในไฟล์ a/BUILD จะอ้างถึง //:b เป้าหมาย
|
opts
|
bazel query ได้ ไม่อนุญาตให้ใช้ตัวเลือกการค้นหาบางอย่างที่นี่: --keep_going , --query_file , --universe_scope , --order_results และ --order_output ตัวเลือกที่ไม่ได้ระบุไว้ที่นี่จะมีค่าเริ่มต้นเหมือนกับบรรทัดคำสั่งของ bazel query
|
scope
|
|
strict
|
|
Genrule
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
จะสร้างไฟล์อย่างน้อย 1 ไฟล์โดยใช้คำสั่ง Bash ที่ผู้ใช้กำหนด
กฎเกณฑ์เป็นกฎการสร้างโดยทั่วไปที่คุณสามารถใช้ได้หากไม่มีกฎเฉพาะสำหรับงาน
ตัวอย่างเช่น คุณเรียกใช้ Bash 1 บรรทัด อย่างไรก็ตาม หากจำเป็นต้องคอมไพล์ไฟล์ C++ ให้ยึดตามกฎ cc_*
ที่มีอยู่ เพราะการดำเนินการที่ยุ่งยากทั้งหมดได้ดำเนินไปให้คุณแล้ว
อย่าใช้ Genrule เพื่อทำการทดสอบ จะมีการชดเชยพิเศษสำหรับการทดสอบและผลการทดสอบ รวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปคุณจะต้องดำเนินการทดสอบหลังจากที่บิลด์เสร็จสมบูรณ์และในสถาปัตยกรรมเป้าหมาย ในขณะที่ Genrules จะทำงานระหว่างบิลด์และสถาปัตยกรรมโฮสต์ (ทั้ง 2 แบบอาจแตกต่างกัน) หากต้องการกฎการทดสอบวัตถุประสงค์ทั่วไป ให้ใช้ sh_test
ข้อควรพิจารณาเกี่ยวกับการคอมไพล์ข้าม
ดูข้อมูลเพิ่มเติมเกี่ยวกับการคอมไพล์ข้ามได้ในคู่มือผู้ใช้
ขณะที่ Genrules ทำงานระหว่างบิลด์ เอาต์พุตของมักจะใช้หลังจากบิลด์ สำหรับการทำให้ใช้งานได้หรือการทดสอบ ลองดูตัวอย่างการคอมไพล์โค้ด C สำหรับไมโครคอนโทรลเลอร์ คอมไพเลอร์จะยอมรับไฟล์ต้นฉบับ C และสร้างโค้ดที่ทำงานบนไมโครคอนโทรลเลอร์ แน่นอนว่าโค้ดที่สร้างขึ้นไม่สามารถทำงานบน CPU ที่ใช้ในการสร้างโค้ดได้ แต่ตัวคอมไพเลอร์ C (หากคอมไพล์จากแหล่งที่มา) เองจำเป็นต้องใช้
ระบบบิลด์ใช้การกำหนดค่าโฮสต์เพื่ออธิบายเครื่องที่บิลด์ทำงานและการกำหนดค่าเป้าหมายเพื่ออธิบายเครื่องที่ควรเรียกใช้เอาต์พุตของบิลด์ โดยมีตัวเลือกในการกำหนดค่ารายการเหล่านี้และแยกไฟล์ที่เกี่ยวข้องออกเป็นไดเรกทอรีแยกต่างหากเพื่อหลีกเลี่ยงข้อขัดแย้ง
สำหรับ Genrules ระบบบิลด์จะดูแลให้มีการสร้างทรัพยากร Dependency อย่างเหมาะสมด้วย srcs
จะสร้างขึ้น (หากจำเป็น) สำหรับการกำหนดค่าเป้าหมาย, tools
สร้างขึ้นสำหรับการกำหนดค่าโฮสต์ และจะถือว่าเอาต์พุตเป็นของการกำหนดค่าเป้าหมาย และยังมี
ตัวแปร "สร้าง" ที่คำสั่ง Genrule สามารถส่งผ่านไปยังเครื่องมือที่เกี่ยวข้องได้
โปรดทราบว่า Genrule ไม่ได้ระบุแอตทริบิวต์ deps
โดยกฎอื่นๆ ที่มีไว้ให้อยู่แล้วจะใช้ข้อมูลเมตาที่ขึ้นอยู่กับภาษาที่ส่งผ่านระหว่างกฎเพื่อกำหนดวิธีจัดการกฎที่ไม่เชื่อมโยงโดยอัตโนมัติ แต่ระบบอัตโนมัติระดับนี้ไม่สามารถทำได้สำหรับ Genrules การสร้างกฎจะทำงานที่ระดับไฟล์และ Runfiles เท่านั้น
กรณีพิเศษ
การคอมไพล์โฮสต์และโฮสต์: ในบางกรณี ระบบบิลด์จะต้องเรียกใช้ Genrules เพื่อให้สามารถดำเนินการเอาต์พุตระหว่างบิลด์ได้ด้วย เช่น หาก Genrule สร้างคอมไพเลอร์ที่กำหนดเองบางรูปแบบซึ่งหลังจากนั้นมีการใช้โดยเจนอื่น กฎแรกจะต้องสร้างเอาต์พุตสำหรับการกำหนดค่าโฮสต์ เพราะเป็นที่ที่คอมไพเลอร์จะทำงานในอีกรุ่นหนึ่ง ในกรณีนี้ ระบบบิลด์จะทำสิ่งที่ถูกต้องโดยอัตโนมัติ โดยจะสร้าง srcs
และ outs
ของรุ่นแรกสำหรับการกำหนดค่าโฮสต์แทนการกำหนดค่าเป้าหมาย ดูข้อมูลเพิ่มเติมได้ที่คู่มือผู้ใช้
เครื่องมือ JDK และ C++: หากต้องการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์จะมีชุดตัวแปรที่จะใช้ ดูรายละเอียดได้ที่ตัวแปร"ผู้ผลิต"
สภาพแวดล้อมการสร้างกฎ
คำสั่ง genrule จะทำงานโดย Bash Shell ที่กำหนดค่าล้มเหลวเมื่อคำสั่งหรือไปป์ไลน์ล้มเหลวโดยใช้ set -e -o pipefail
เครื่องมือบิลด์จะเรียกใช้คำสั่ง Bash ในสภาพแวดล้อมกระบวนการที่ปลอดภัยที่กำหนดเฉพาะตัวแปรหลัก เช่น PATH
, PWD
, TMPDIR
และอื่นๆ
ระบบจะไม่ส่งตัวแปรส่วนใหญ่ที่กำหนดไว้ในสภาพแวดล้อม Shell ของผู้ใช้ไปยังคำสั่งของ genrule เพื่อให้มั่นใจว่าบิลด์จะทำซ้ำได้ แต่ Bazel (แต่ไม่ใช่ Blaze) จะส่งผ่านค่าตัวแปรสภาพแวดล้อม PATH
ของผู้ใช้
การเปลี่ยนแปลงค่าของ PATH
จะทำให้ Bazel เรียกใช้คำสั่งอีกครั้งในบิลด์ถัดไป
คำสั่ง genrule ไม่ควรเข้าถึงเครือข่าย ยกเว้นเพื่อเชื่อมต่อกระบวนการที่เป็นรายการย่อยของคำสั่งเอง แม้ว่าจะยังไม่ได้บังคับใช้ก็ตาม
ระบบบิลด์จะลบไฟล์เอาต์พุตที่มีอยู่โดยอัตโนมัติ แต่จะสร้างไดเรกทอรีระดับบนสุดที่จำเป็นก่อนที่จะเรียกใช้ Genrule และยังนำไฟล์เอาต์พุตออกในกรณีที่เกิดข้อผิดพลาดอีกด้วย
คำแนะนำทั่วไป
- โปรดตรวจสอบว่าเครื่องมือที่เรียกใช้โดยกฎเกณฑ์มีหลักการและมีความครบถ้วนสมบูรณ์ เครื่องมือดังกล่าวไม่ควรเขียนการประทับเวลาลงในเอาต์พุต และควรใช้การจัดลำดับที่เสถียรสำหรับชุดและแผนที่ รวมถึงเขียนเฉพาะเส้นทางไฟล์แบบสัมพัทธ์ไปยังเอาต์พุต ไม่ใช่เส้นทางที่แน่นอน การไม่ปฏิบัติตามกฎนี้จะทำให้เกิดลักษณะการทำงานที่ไม่คาดคิด (Bazel ไม่ได้สร้างกฎเกณฑ์ตามที่คุณคิดไว้ใหม่) และทำให้ประสิทธิภาพของแคชลดลง
- ใช้
$(location)
อย่างครอบคลุมสำหรับเอาต์พุต เครื่องมือ และแหล่งที่มา เนื่องจากการแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าที่ต่างกัน ทำให้ Genrules ไม่สามารถพึ่งพาเส้นทางแบบฮาร์ดโค้ดและ/หรือเส้นทางแบบสัมบูรณ์ - ควรเขียนมาโคร Starlark ทั่วไปในกรณีที่มีการใช้กฎ Gen เดียวกันหรือคล้ายกันมากในหลายๆ ที่ หาก Genrule มีความซับซ้อน ให้พิจารณาติดตั้งใช้งานในสคริปต์หรือใช้เป็นกฎ Starlark การทำเช่นนี้จะช่วยปรับปรุงให้อ่านง่ายและช่วยในการทดสอบ
- ตรวจสอบว่ารหัสการออกนั้นบ่งบอกถึงความสำเร็จหรือความล้มเหลวของเจนกฎ
- อย่าเขียนข้อความแจ้งข้อมูลไปยัง stdout หรือ stderr แม้ว่านี่จะเป็นประโยชน์ต่อการแก้ไขข้อบกพร่อง แต่ก็สามารถกลายเป็นสิ่งรบกวนได้โดยง่าย ส่วนการกำหนดเพศที่ประสบความสำเร็จควรปิดเสียงไว้ ในทางกลับกัน การกำหนดเงื่อนไขที่ล้มเหลวควรส่งข้อความแสดงข้อผิดพลาดที่ดี
$$
evaluates to a$
, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such asls $(dirname $x)
, one must escape it thus:ls $$(dirname $$x)
.- หลีกเลี่ยงการสร้างลิงก์สัญลักษณ์และไดเรกทอรี Bazel จะไม่คัดลอกโครงสร้างไดเรกทอรี/ลิงก์สัญลักษณ์ที่สร้างโดย genrules และการตรวจสอบการอ้างอิงของไดเรกทอรีจะไม่เกิดขึ้น
- เมื่ออ้างอิง Genrule ในกฎอื่นๆ คุณจะใช้ป้ายกำกับของกฎเกณฑ์หรือป้ายกำกับของไฟล์เอาต์พุตแต่ละไฟล์ก็ได้ ในบางครั้งวิธีหนึ่งอาจอ่านได้ง่ายกว่า แต่บางวิธี เช่น การอ้างอิงเอาต์พุตตามชื่อใน
srcs
ของกฎการใช้จะหลีกเลี่ยงการเลือกเอาต์พุตอื่นๆ ของ GenRule โดยไม่ได้ตั้งใจ แต่อาจเป็นเรื่องน่าเบื่อหาก Genrule สร้างเอาต์พุตจำนวนมาก
ตัวอย่าง
ตัวอย่างนี้สร้าง foo.h
ไม่มีแหล่งที่มา เนื่องจากคำสั่งไม่ได้ป้อนข้อมูลใดๆ "ไบนารี" ที่เรียกใช้โดยคำสั่งเป็นสคริปต์ Perl ในแพ็กเกจเดียวกับ Genrule
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
ตัวอย่างต่อไปนี้แสดงวิธีใช้ filegroup
และเอาต์พุตของ genrule
อีกรายการ โปรดทราบว่าการใช้ $(SRCS)
แทนคำสั่ง $(location)
อย่างชัดแจ้งก็จริงได้เช่นกัน ตัวอย่างนี้ใช้หลังนี้เพื่อการสาธิต
genrule( name = "concat_all_files", srcs = [ "//some:files", # a filegroup with multiple files in it ==> $(locations) "//other:gen", # a genrule with a single output ==> $(location) ], outs = ["concatenated.txt"], cmd = "cat $(locations //some:files) $(location //other:gen) > $@", )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ คุณอาจดูกฎนี้ได้ในส่วน srcs หรือ deps ของกฎ BUILD อื่นๆ หากกฎสร้างไฟล์ต้นฉบับ คุณควรใช้แอตทริบิวต์ srcs
|
srcs
|
แอตทริบิวต์นี้ไม่เหมาะกับรายชื่อเครื่องมือที่เรียกใช้โดย
ระบบบิลด์จะตรวจสอบว่าข้อกำหนดเบื้องต้นเหล่านี้สร้างขึ้นก่อนเรียกใช้คำสั่ง Genrule โดยจะมีการสร้างโดยใช้การกำหนดค่าเดียวกันกับคำขอบิลด์เดิม ชื่อไฟล์ของข้อกำหนดเบื้องต้นเหล่านี้จะพร้อมใช้งานสำหรับคำสั่งเป็นรายการที่คั่นด้วยช่องว่างใน |
outs
|
ไฟล์เอาต์พุตต้องไม่ข้ามขอบเขตของแพ็กเกจ ระบบจะตีความชื่อไฟล์เอาต์พุตว่าสัมพันธ์กับแพ็กเกจ
หากตั้งค่าแฟล็ก
คาดว่าคำสั่ง genrule จะสร้างไฟล์เอาต์พุตแต่ละไฟล์ในตำแหน่งที่กำหนดไว้ล่วงหน้า
ตำแหน่งจะพร้อมใช้งานใน |
cmd
|
$(location)
และตัวแปร"ผู้ผลิต"
cmd_bash , cmd_ps และ cmd_bat
หากไม่เกี่ยวข้อง
หากบรรทัดคำสั่งยาวเกินขีดจำกัดของแพลตฟอร์ม (64, 000 บน Linux/macOS, 8K ใน Windows) Genrule จะเขียนคำสั่งลงในสคริปต์และเรียกใช้สคริปต์นั้นเพื่อแก้ปัญหา ค่านี้มีผลกับแอตทริบิวต์ cmd ทั้งหมด ( |
cmd_bash
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า |
cmd_bat
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า
|
cmd_ps
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า
เราเรียกใช้คำสั่งต่อไปนี้เพื่อตั้งค่าสภาพแวดล้อมก่อนเรียกใช้คำสั่ง Powershell ใน Genrule เพื่อให้ใช้งาน Powershell ได้ง่ายขึ้นและเกิดข้อผิดพลาดน้อยลง
|
exec_tools
|
tools ทุกประการ เว้นแต่จะมีการกำหนดค่าทรัพยากร Dependency เหล่านี้สำหรับแพลตฟอร์มการดำเนินการของกฎแทนการกำหนดค่าโฮสต์
ซึ่งหมายความว่าทรัพยากร Dependency ใน exec_tools จะไม่อยู่ภายใต้ข้อจำกัดเดียวกันกับทรัพยากร Dependency ใน tools กล่าวอย่างเจาะจงคือ ไม่จำเป็นต้องใช้การกำหนดค่าโฮสต์สำหรับทรัพยากร Dependency ชั่วคราวของตนเอง ดูรายละเอียดเพิ่มเติมได้ที่ tools
ทีม Blaze กำลังย้ายข้อมูลการใช้งาน |
executable
|
การตั้งค่าแฟล็กนี้เป็น "จริง" หมายความว่าเอาต์พุตจะเป็นไฟล์ปฏิบัติการและเรียกใช้ได้โดยใช้คำสั่ง ไม่รองรับการประกาศทรัพยากร Dependency สำหรับไฟล์สั่งการที่สร้างขึ้น |
local
|
หากตั้งค่าเป็น "จริง" ตัวเลือกนี้จะบังคับให้
ซึ่งเทียบเท่ากับการระบุ 'local' เป็นแท็ก ( |
message
|
ข้อความความคืบหน้าที่จะพิมพ์เมื่อดำเนินการในขั้นตอนบิลด์นี้ โดยค่าเริ่มต้น ข้อความจะเป็น "กำลังสร้างเอาต์พุต" (หรืออะไรที่ก็น่าเบื่อพอๆ กัน) แต่คุณอาจระบุที่เจาะจงมากขึ้นก็ได้ ใช้แอตทริบิวต์นี้แทน |
output_licenses
|
common attributes
|
output_to_bindir
|
หากตั้งค่าเป็น "จริง" ตัวเลือกนี้จะทำให้มีการเขียนไฟล์เอาต์พุตในไดเรกทอรี |
tools
|
ระบบบิลด์จะตรวจสอบว่าข้อกำหนดเบื้องต้นเหล่านี้สร้างขึ้นก่อนที่จะเรียกใช้คำสั่ง genrule ระบบสร้างโดยใช้การกำหนดค่า host เนื่องจากมีการดำเนินการเครื่องมือเหล่านี้เป็นส่วนหนึ่งของบิลด์ เส้นทางของแต่ละเป้าหมาย
|
test_suite
test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite
กำหนดชุดการทดสอบที่ถือว่า "มีประโยชน์" ต่อมนุษย์ วิธีนี้ทำให้โปรเจ็กต์สามารถกำหนดชุดการทดสอบได้ เช่น "การทดสอบที่คุณต้องทำก่อนเช็คอิน" "การทดสอบภาวะวิกฤตของโปรเจ็กต์" หรือ "การทดสอบย่อยทั้งหมด" คำสั่ง blaze test
จะดำเนินการตามโครงสร้างแบบนี้ สำหรับการเรียกใช้อย่าง blaze test //some/test:suite
ก่อน Blaze จะแจกแจงเป้าหมายการทดสอบทั้งหมดที่รวมไว้แล้วโดยเป้าหมาย //some/test:suite
(เราเรียกว่า "การขยายtest_suite") ก่อน จากนั้น Blaze จะสร้างและทดสอบเป้าหมายเหล่านั้น
ตัวอย่าง
ชุดทดสอบสำหรับทำการทดสอบขนาดเล็กทั้งหมดในแพ็กเกจปัจจุบัน
test_suite( name = "small_tests", tags = ["small"], )
ชุดทดสอบที่เรียกใช้ชุดการทดสอบที่ระบุ
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
ชุดทดสอบที่จะทำการทดสอบทั้งหมดในแพ็กเกจปัจจุบันซึ่งทำงานไม่สม่ำเสมอ
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
tags
|
แท็กที่ขึ้นต้นด้วยอักขระ "-" จะถือว่าเป็นแท็กเชิงลบ อักขระ "-" นำหน้าไม่ถือว่าเป็นส่วนหนึ่งของแท็ก ดังนั้นแท็กชุดโปรแกรม "-small" จะตรงกับขนาด "เล็ก" ของการทดสอบ แท็กอื่นๆ ทั้งหมดจะถือว่าเป็นแท็กเชิงบวก (ไม่บังคับ) หากต้องการให้แท็กเชิงบวกมีความชัดเจนมากขึ้น แท็กอาจขึ้นต้นด้วยอักขระ "+" ซึ่งจะไม่ได้รับการประเมินในฐานะเป็นส่วนหนึ่งของข้อความของแท็ก แต่เป็นเพียงการทําให้ความแตกต่างด้านบวกและด้านลบอ่านได้ง่ายขึ้นเท่านั้น ชุดทดสอบนี้จะรวมเฉพาะกฎทดสอบที่ตรงกับแท็กเชิงบวกทั้งหมดและไม่มีแท็กเชิงลบเท่านั้นที่จะรวมอยู่ในชุดทดสอบ โปรดทราบว่าการดำเนินการนี้ไม่ได้หมายความว่าระบบจะข้ามการตรวจสอบข้อผิดพลาดสำหรับทรัพยากร Dependency ของการทดสอบที่กรองออก แต่การอ้างอิงในการทดสอบที่ข้ามจะยังคงต้องเป็นไปตามกฎหมาย (เช่น ไม่ถูกบล็อกโดยข้อจำกัดระดับการเข้าถึง)
คีย์เวิร์ดของแท็ก
โปรดทราบว่า
หากต้องการ |
tests
|
ใช้
หากไม่ระบุแอตทริบิวต์ |