กฎ
ชื่อแทน
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
กฎ alias
จะสร้างชื่ออื่นที่อาจเรียกว่ากฎได้
การใช้ชื่อแทนจะใช้ได้กับ "ปกติ" เท่านั้น เป้าหมาย โดยเฉพาะอย่างยิ่ง package_group
และ test_suite
ใช้เป็นชื่อแทนไม่ได้
กฎชื่อแทนมีการประกาศระดับการเข้าถึงเป็นของตัวเอง และในอีกแง่มุมหนึ่ง เช่น กฎที่อ้างอิง (เช่น testonly ในชื่อแทนจะถูกละเว้น และ testonly-ness ของกฎที่อ้างอิงแทน) โดยมีข้อยกเว้นบางประการดังนี้
-
การทดสอบจะไม่ทำงานหากมีการระบุชื่อแทนในบรรทัดคำสั่ง วิธีกำหนดชื่อแทน
ที่เรียกใช้การทดสอบที่อ้างอิง ให้ใช้
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
ไม่ตรงกับแฟล็กบรรทัดคำสั่งระดับบนสุด แต่อาจยังตรงกันอยู่
เป้าหมายของบิลด์
หมายเหตุ
- โปรดดูการเลือกสำหรับสิ่งที่จะเกิดขึ้นเมื่อหลายรายการ
config_setting
ตรงกับสถานะการกำหนดค่าปัจจุบัน - สําหรับ Flag ที่รองรับรูปแบบชวเลข (เช่น
--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
ให้ผลลัพธ์["a", "b"]
ตรวจสอบคำจำกัดความของ Flag และทดสอบ เงื่อนไขโดยละเอียดเพื่อยืนยันความคาดหวังที่ถูกต้อง - หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างโมเดลด้วยแฟล็กบิลด์ในตัว ให้ใช้
แฟล็กที่กำหนดโดย Starlark คุณใช้
--define
ได้ด้วย แต่ตัวเลือกนี้จะรัดกุมกว่า แต่ไม่แนะนำให้ใช้ โปรดดู ที่นี่เพื่อดูการสนทนาเพิ่มเติม - หลีกเลี่ยงการใช้คำจำกัดความ
config_setting
ที่เหมือนกันในแพ็กเกจอื่นซ้ำ แต่ให้อ้างอิงconfig_setting
ทั่วไปที่กำหนดไว้ในแพ็กเกจ Canonical แทน values
define_values
และconstraint_values
สามารถใช้ชุดค่าผสมใดก็ได้ในconfig_setting
เดียวกัน แต่ต้องมีอย่างน้อย กำหนดสำหรับconfig_setting
ใดๆ ก็ได้
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
constraint_values
|
constraint_values ที่แพลตฟอร์มเป้าหมายต้องระบุ
เพื่อจับคู่config_setting นี้ (แพลตฟอร์มการดำเนินการ
ที่เกี่ยวข้องกันที่นี่) ระบบจะไม่สนใจค่าข้อจำกัดเพิ่มเติมที่แพลตฟอร์มถูกละเว้น โปรดดู
รายละเอียดแอตทริบิวต์บิลด์ที่กำหนดค่าได้
ในกรณีที่ |
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 แต่
สำหรับ
แฟล็กบิลด์ที่ผู้ใช้กำหนด
ซึ่งเป็นแอตทริบิวต์ที่เด่นชัดเนื่องจาก Flag ที่ผู้ใช้กำหนดจะอ้างอิงว่าเป็นป้ายกำกับในขณะที่ แฟล็กในตัวจะอ้างอิงเป็นสตริงที่กำหนดเอง |
values
|
กฎนี้รับการกำหนดค่าของเป้าหมายที่กำหนดค่าไว้ซึ่ง
อ้างถึงในคำสั่ง เพื่อความสะดวก ค่าของการกำหนดค่าจึงมีการระบุเป็นแฟล็กบิลด์ (ไม่มี
หากไม่ได้ตั้งค่า Flag อย่างชัดเจนที่บรรทัดคำสั่ง ระบบจะใช้ค่าเริ่มต้น
หากคีย์ปรากฏในพจนานุกรมหลายครั้ง ระบบจะใช้เฉพาะอินสแตนซ์ล่าสุดเท่านั้น
หากคีย์อ้างอิงถึงแฟล็กที่ตั้งค่าได้หลายครั้งในบรรทัดคำสั่ง (เช่น
|
กลุ่มไฟล์
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
ไม่รองรับทรัพยากร Dependency ที่เป็นไวลด์การ์ด (เช่น 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 หนึ่งบรรทัด แต่หากต้องการคอมไพล์ไฟล์ C++ ให้ใช้
ตามกฎcc_*
ที่มีอยู่ เนื่องจากได้เพิ่มภาระงานหนักๆ ทั้งหมดแล้ว
สำหรับคุณ
อย่าใช้ Genrule เพื่อทำการทดสอบ มีค่าตอบแทนพิเศษสำหรับการทดสอบ
ซึ่งรวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปแล้วจำเป็นต้องทำการทดสอบ
หลังจากบิลด์เสร็จสมบูรณ์และในสถาปัตยกรรมเป้าหมายแล้ว ขณะที่ Genrule จะดำเนินการในระหว่าง
บิลด์และสถาปัตยกรรมโฮสต์ (ทั้ง 2 แบบอาจแตกต่างกัน) หากต้องการวัตถุประสงค์ทั่วไป
กฎการทดสอบ ให้ใช้ sh_test
ข้อควรพิจารณาเกี่ยวกับการรวบรวมคลิป
โปรดดูคู่มือผู้ใช้เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับ การคอมไพล์แบบข้ามแพลตฟอร์ม
แม้ว่า Genrules จะทำงานระหว่างบิลด์ แต่เอาต์พุตมักจะใช้หลังจากบิลด์เพื่อทำให้ใช้งานได้ หรือ การทดสอบ ลองพิจารณาตัวอย่างการคอมไพล์โค้ด C สำหรับไมโครคอนโทรลเลอร์: คอมไพเลอร์ยอมรับ C ไฟล์ต้นฉบับ แล้วสร้างโค้ดที่ทำงานบนไมโครคอนโทรลเลอร์ โค้ดที่สร้างขึ้นอย่างชัดเจน ไม่สามารถเรียกใช้บน CPU ที่ใช้ในการสร้าง แต่คอมไพเลอร์ C (หากคอมไพเลอร์จากแหล่งที่มา) ได้ไปแล้ว
ระบบบิลด์ใช้การกำหนดค่าโฮสต์เพื่ออธิบายเครื่องที่บิลด์ทำงาน และการกำหนดค่าเป้าหมายเพื่ออธิบายเครื่องที่เอาต์พุตของบิลด์ ที่ควรจะทำงาน เครื่องมือนี้จะแสดงตัวเลือกในการกำหนดค่าแต่ละประเภทและแยก ไฟล์ที่ตรงกันลงในไดเรกทอรีแยกต่างหากเพื่อไม่ให้เกิดความขัดแย้ง
สำหรับ Genrule ระบบบิลด์จะตรวจสอบว่าทรัพยากร Dependency สร้างขึ้นอย่างเหมาะสม ดังนี้
srcs
ได้รับการสร้างขึ้น (หากจำเป็น) สำหรับการกำหนดค่าเป้าหมาย
tools
สร้างขึ้นสำหรับการกำหนดค่าโฮสต์ และเอาต์พุตถือว่าเป็นไปตาม
สำหรับการกำหนดค่า target และยังมี
"ทำ" ตัวแปรที่คำสั่ง genrule สามารถส่งผ่านไปยังเครื่องมือที่เกี่ยวข้องได้
เป็นโดยเจตนาที่ Genrule จะไม่กำหนดแอตทริบิวต์ deps
: แต่กฎในตัวอื่นๆ จะใช้
ข้อมูลเมตาที่ขึ้นอยู่กับภาษาที่ส่งผ่านระหว่างกฎต่างๆ เพื่อกำหนดวิธีการ
จัดการกฎที่ขึ้นต่อกัน แต่การทำงานอัตโนมัติในระดับนี้ไม่สามารถทำได้สำหรับ Genrule การทำงานของกฎ
เฉพาะที่ระดับไฟล์และการเรียกใช้ไฟล์
คดีพิเศษ
การคอมไพล์โฮสต์โฮสต์: ในบางกรณี ระบบบิลด์จำเป็นต้องเรียกใช้ Genrule ที่
ดำเนินการเอาต์พุตได้ในระหว่างบิลด์ด้วย ตัวอย่างเช่น หาก Genrule สร้างคอมไพเลอร์ที่กำหนดเอง
ซึ่งมีการใช้โดย Genrule อื่นในภายหลัง กฎแรกที่จะสร้างเอาต์พุตสำหรับ
การกำหนดค่าโฮสต์ เนื่องจากเป็นตำแหน่งที่คอมไพเลอร์จะทำงานใน Genrule อื่น ในกรณีนี้
ระบบบิลด์จะทำสิ่งที่ถูกต้องโดยอัตโนมัติ โดยการสร้าง srcs
และ
outs
ของกฎแรกสำหรับการกำหนดค่าโฮสต์แทนเป้าหมาย
การกำหนดค่า โปรดดูข้อมูลเพิ่มเติมจากคู่มือผู้ใช้
ข้อมูลเพิ่มเติม
JDK และ เครื่องมือ C++: ในการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์ ระบุชุดตัวแปรที่จะใช้ ดู "ผู้ผลิต" ตัวแปรสำหรับ รายละเอียด
สภาพแวดล้อมการสร้างกฎ
คำสั่ง genrule จะดำเนินการโดย Bash Shell ที่กำหนดค่าให้ล้มเหลวเมื่อคำสั่ง
หรือไปป์ไลน์ล้มเหลว โดยใช้ set -e -o pipefail
เครื่องมือสร้างจะเรียกใช้คำสั่ง Bash ในสภาพแวดล้อมกระบวนการที่ปลอดภัยซึ่ง
กำหนดเฉพาะตัวแปรหลัก เช่น PATH
, PWD
TMPDIR
และอีก 2-3 รายการ
ตัวแปรส่วนใหญ่ที่กำหนดไว้ใน Shell ของผู้ใช้เพื่อให้แน่ใจว่าบิลด์จะทำซ้ำได้
และจะไม่ส่งผ่านไปยังคำสั่งของ Genrule อย่างไรก็ตาม Bazel (แต่
Blaze) จะส่งค่าตัวแปรสภาพแวดล้อม PATH
ของผู้ใช้
การเปลี่ยนแปลงค่า PATH
จะทำให้ Bazel เรียกใช้คำสั่งนี้อีกครั้ง
ในบิลด์ถัดไป
คำสั่ง Genrule ไม่ควรเข้าถึงเครือข่าย ยกเว้นเพื่อเชื่อมต่อกระบวนการที่ ย่อยของคำสั่งนั้น แม้ว่าจะยังไม่มีการบังคับใช้ในขณะนี้
ระบบบิลด์จะลบไฟล์เอาต์พุตที่มีอยู่โดยอัตโนมัติ แต่จะสร้างระดับบนที่จำเป็น ไดเรกทอรีก่อนที่จะเรียกใช้ Genrule นอกจากนี้ยังนำไฟล์เอาต์พุตทั้งหมดออกในกรณีที่เกิดข้อผิดพลาด
คำแนะนำทั่วไป
- ตรวจสอบให้แน่ใจว่าเครื่องมือที่เรียกใช้โดยกฎพันธุกรรมมีความละเอียดอ่อนและมีความต่อเนื่อง ผู้ใช้ไม่ควรเขียน การประทับเวลาไปยังเอาต์พุต และควรใช้การจัดลำดับที่เสถียรสำหรับชุดและแผนที่ รวมถึง เขียนเฉพาะเส้นทางไฟล์สัมพัทธ์ไปยังเอาต์พุต ไม่ใช่เส้นทางสัมบูรณ์ การไม่ปฏิบัติตามกฎนี้จะ ทำให้เกิดลักษณะการสร้างที่ไม่คาดคิด (Bazel ไม่ได้สร้าง Genrule ใหม่อย่างที่คุณคิด) และ ทำให้ประสิทธิภาพของแคชลดลง
- ใช้
$(location)
อย่างครอบคลุมสำหรับเอาต์พุต เครื่องมือ และแหล่งที่มา เนื่องจาก การแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าที่แตกต่างกัน Genrule จะอาศัยฮาร์ดโค้ดไม่ได้ และ/หรือเส้นทางสัมบูรณ์ - เขียนมาโคร Starlark ทั่วไปเผื่อในกรณีที่มีการใช้กฎเกณฑ์เดียวกันหรือคล้ายกันมากใน หลายสถานที่ หาก 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 ไม่คัดลอกไปยังไดเรกทอรี/ลิงก์สัญลักษณ์ สร้างโดย Genrule และการตรวจสอบทรัพยากร Dependency ของไดเรกทอรีจะไม่ส่งเสียง
- เมื่ออ้างอิง Genrule ในกฎอื่นๆ คุณสามารถใช้ป้ายกำกับของ 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
|
แอตทริบิวต์นี้ไม่เหมาะสำหรับแสดงรายการเครื่องมือที่ดำเนินการโดย
ระบบบิลด์จะดูแลให้มีการสร้างข้อกำหนดเบื้องต้นเหล่านี้ก่อนเรียกใช้กฎ Gen
คำสั่ง; ที่สร้างขึ้นโดยใช้การกำหนดค่าเดียวกับคำขอบิลด์เดิม
ชื่อไฟล์ของข้อกำหนดเบื้องต้นเหล่านี้จะมีให้กับคำสั่ง
รายการที่คั่นด้วยช่องว่างใน |
outs
|
ไฟล์เอาต์พุตต้องไม่ข้ามขอบเขตของแพ็กเกจ ระบบจะแปลชื่อไฟล์เอาต์พุตว่าสัมพันธ์กับแพ็กเกจ
หากตั้งค่าแฟล็ก
คำสั่ง Genrule ต้องการสร้างไฟล์เอาต์พุตแต่ละไฟล์ในตำแหน่งที่กำหนดไว้ล่วงหน้า
ตำแหน่งแสดงใน |
cmd
|
$(location)
และ "ผู้ผลิต" ตัวแปร
cmd_bash , cmd_ps และ cmd_bat
หากไม่มีข้อใดเลย
หากบรรทัดคำสั่งยาวเกินขีดจำกัดของแพลตฟอร์ม (64K ใน Linux/macOS, 8K ใน Windows)
จากนั้น Genrule จะเขียนคำสั่งลงในสคริปต์และเรียกใช้สคริปต์นั้นเพื่อแก้ปัญหา ช่วงเวลานี้
ใช้กับแอตทริบิวต์ cmd ทั้งหมด ( |
cmd_bash
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า |
cmd_bat
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า
|
cmd_ps
|
แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า
เพื่อให้ Powershell ใช้งานง่ายและมีโอกาสเกิดข้อผิดพลาดน้อยลง เราจึงเรียกใช้สิ่งต่อไปนี้ คำสั่งเพื่อตั้งค่าสภาพแวดล้อมก่อนเรียกใช้คำสั่ง Powershell ใน genrule
|
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
ที่สร้างขึ้นโดยใช้โฮสต์
การกำหนดค่า เนื่องจากเครื่องมือเหล่านี้จะดำเนินการเป็นส่วนหนึ่งของบิลด์ เส้นทางของ
รับ
|
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" ตรงกับค่า "small" ของการทดสอบ ขนาด แท็กอื่นๆ ทั้งหมดจะได้รับการพิจารณา แท็กเชิงบวก หากต้องการให้แท็กเชิงบวกมีความชัดเจนมากขึ้น แท็กอาจขึ้นต้นด้วย "+" ซึ่งระบบจะไม่ประเมินเป็นส่วนหนึ่งของข้อความแท็ก ทั้งนี้ เพียงแต่ทำให้อ่านความแตกต่างในแง่บวกและด้านลบได้ง่ายขึ้นเท่านั้น เฉพาะกฎทดสอบที่ตรงกับแท็กบวกทั้งหมดและไม่มีแท็กเชิงลบ แท็กจะรวมอยู่ในชุดทดสอบ โปรดทราบว่าไม่ได้หมายความว่าการตรวจสอบข้อผิดพลาด สำหรับทรัพยากร Dependency ของการทดสอบที่ถูกกรองออกจะถูกข้ามไป ทรัพยากร Dependency ที่ข้ามไป การทดสอบยังคงต้องเป็นข้อมูลทางกฎหมาย (เช่น ไม่ได้ถูกบล็อกโดยข้อจํากัดระดับการมองเห็น)
ระบบจะดำเนินการกับคีย์เวิร์ดของแท็ก
โปรดทราบว่า
หากคุณต้องการ |
tests
|
โดยยอมรับ
หากไม่ได้ระบุหรือเว้นว่างแอตทริบิวต์ |