กฎ
ชื่อแทน
ดูแหล่งที่มาของกฎalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
กฎ alias
จะสร้างชื่ออื่นที่อาจเรียกว่ากฎได้
การใช้ชื่อแทนใช้ได้กับเป้าหมาย "ปกติ" เท่านั้น โดยเฉพาะอย่างยิ่ง package_group
และ test_suite
จะใช้เป็นชื่อแทนไม่ได้
การใช้อีเมลแทนอาจมีประโยชน์ในรีโพซิทอรีขนาดใหญ่ที่การเปลี่ยนชื่อเป้าหมายจะต้องทำการเปลี่ยนแปลงไฟล์จำนวนมาก คุณยังใช้กฎชื่อแทนเพื่อจัดเก็บการเรียกใช้ฟังก์ชัน select ได้หากต้องการนำตรรกะนั้นมาใช้ซ้ำกับหลายเป้าหมาย
กฎแทนที่จะมีการประกาศการแสดงผลของตนเอง ส่วนในด้านอื่นๆ ทั้งหมด กฎนี้จะทํางานเหมือนกับกฎที่อ้างอิง (เช่น ระบบจะไม่สนใจ testonly ในชื่อแทน แต่จะนํา 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)
จับคู่สถานะการกำหนดค่าที่คาดไว้ (แสดงเป็นแฟล็กบิลด์หรือข้อจำกัดของแพลตฟอร์ม) เพื่อจุดประสงค์ในการทริกเกอร์แอตทริบิวต์ที่กำหนดค่าได้ ดูselect เพื่อดูวิธีใช้กฎนี้และ แอตทริบิวต์ที่กำหนดค่าได้เพื่อดูภาพรวมของฟีเจอร์ทั่วไป
ตัวอย่าง
รายการต่อไปนี้จะจับคู่กับบิลด์ที่ตั้งค่า --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" } )
รายการต่อไปนี้จะจับคู่กับบิลด์ที่ตั้งFlag ที่ผู้ใช้กำหนด
--//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
หลายรายการตรงกับสถานะการกําหนดค่าปัจจุบันได้ที่เลือก - สำหรับคำที่รองรับรูปแบบตัวย่อ (เช่น
--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
ความหมายที่แน่นอนจะแตกต่างกันไปในแต่ละ Flag เช่น--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 และทดสอบเงื่อนไขอย่างละเอียดเพื่อยืนยันสิ่งที่คาดหวัง - หากต้องการกำหนดเงื่อนไขที่ไม่ได้อิงตาม Flag การสร้างในตัว ให้ใช้Flag ที่ Starlark กำหนด คุณใช้
--define
ได้ด้วย แต่วิธีนี้ให้การสนับสนุนที่ต่ำกว่าและไม่แนะนำ ดูการพูดคุยเพิ่มเติมได้ที่นี่ - หลีกเลี่ยงการใช้คำจำกัดความ
config_setting
ที่เหมือนกันในแพ็กเกจอื่นซ้ำ แต่ให้อ้างอิงconfig_setting
ทั่วไปที่กําหนดไว้ในแพ็กเกจแคนนอนิกแทน values
,define_values
และconstraint_values
ใช้ร่วมกันในconfig_setting
เดียวกันได้ แต่ต้องตั้งค่าอย่างน้อย 1 รายการสำหรับconfig_setting
หนึ่งๆ
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสําหรับเป้าหมายนี้ |
constraint_values
|
รายการป้ายกำกับ nonconfigurable ค่าเริ่มต้นคือ constraint_values ที่แพลตฟอร์มเป้าหมายต้องระบุเพื่อให้ตรงกับ config_setting นี้ (ไม่พิจารณาแพลตฟอร์มการดำเนินการที่นี่) ระบบจะไม่สนใจค่าข้อจำกัดเพิ่มเติมที่แพลตฟอร์มมี ดูรายละเอียดได้ที่หัวข้อ
แอตทริบิวต์การสร้างที่กำหนดค่าได้
ในกรณีที่ |
define_values
|
พจนานุกรม: สตริง -> สตริง nonconfigurable ค่าเริ่มต้นคือ values แต่ใช้สำหรับ Flag --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
|
พจนานุกรม: label -> String; nonconfigurable; ค่าเริ่มต้นคือ values แต่ใช้สำหรับ
Flag การสร้างที่ผู้ใช้กำหนด
แอตทริบิวต์นี้เป็นแอตทริบิวต์ที่แยกต่างหากเนื่องจากระบบจะอ้างอิง Flag ที่กําหนดโดยผู้ใช้เป็นป้ายกํากับ ขณะที่อ้างอิง Flag ในตัวเป็นสตริงที่กำหนดเอง |
values
|
พจนานุกรม: สตริง -> สตริง nonconfigurable ค่าเริ่มต้นคือ กฎนี้รับการกำหนดค่าของเป้าหมายที่กำหนดค่าไว้ซึ่งอ้างอิงถึงเป้าหมายในคำสั่ง เพื่อความสะดวก ค่าการกําหนดค่าจะระบุเป็น Flag การสร้าง (โดยไม่มี หากไม่ได้ตั้งค่า Flag อย่างชัดเจนที่บรรทัดคำสั่ง ระบบจะใช้ค่าเริ่มต้น
หากคีย์ปรากฏหลายครั้งในพจนานุกรม ระบบจะใช้เฉพาะอินสแตนซ์ล่าสุด
หากคีย์อ้างอิงถึง 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, compressed_output, 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
เป็น "จริง" (หาก strict
เป็น "เท็จ" ระบบจะข้ามเป้าหมายที่อยู่นอกขอบเขตพร้อมแสดงคำเตือน) วิธีที่ง่ายที่สุดในการป้องกันไม่ให้เหตุการณ์เช่นนี้เกิดขึ้นคือการพูดถึงป้ายกำกับเดียวกันในขอบเขตเช่นเดียวกับในนิพจน์การค้นหา
ความแตกต่างเพียงอย่างเดียวระหว่างข้อความค้นหาที่อนุญาตที่นี่และในบรรทัดคำสั่งคือระบบไม่อนุญาตให้ใช้ข้อความค้นหาที่มีข้อกำหนดเป้าหมายแบบไวลด์การ์ด (เช่น //pkg:*
หรือ //pkg:all
) ที่นี่
สาเหตุมี 2 ประการ ประการแรก เนื่องจาก genquery
ต้องระบุขอบเขตเพื่อป้องกันไม่ให้เป้าหมายที่อยู่นอกการปิดเชิงสื่อกลางของการค้นหาส่งผลต่อเอาต์พุต และประการที่ 2 เนื่องจากไฟล์ BUILD
ไม่รองรับการอ้างอิงไวลด์การ์ด (เช่น ไม่อนุญาตให้ใช้ deps=["//a/..."]
)
ระบบจะจัดเรียงเอาต์พุตของ genquery ตามลําดับตัวอักษรเพื่อบังคับใช้เอาต์พุตแบบกำหนดได้ ยกเว้น --output=graph|minrank|maxrank
หรือเมื่อใช้ somepath
เป็นฟังก์ชันระดับบนสุด
ชื่อไฟล์เอาต์พุตคือชื่อของกฎ
ตัวอย่าง
ตัวอย่างนี้จะเขียนรายการป้ายกำกับใน Closure แบบทรานซิทีฟของเป้าหมายที่ระบุลงในไฟล์
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสำหรับเป้าหมายนี้ |
compressed_output
|
บูลีน ค่าเริ่มต้นคือ True เอาต์พุตคำค้นหาจะเขียนในรูปแบบไฟล์ GZIP คุณสามารถใช้การตั้งค่านี้เพื่อหลีกเลี่ยงการใช้หน่วยความจำของ Bazel ที่เพิ่มขึ้นอย่างรวดเร็วเมื่อคาดว่าเอาต์พุตการค้นหาจะมีขนาดใหญ่ Bazel จะบีบอัดเอาต์พุตการค้นหาที่มีขนาดใหญ่กว่า 220 ไบต์อยู่แล้วภายในโดยไม่คำนึงถึงค่าของการตั้งค่านี้ ดังนั้นการตั้งค่านี้เป็น True อาจไม่ลดกองข้อมูลที่เก็บไว้ แต่จะช่วยให้ Bazel ข้ามการคลายการบีบอัดเมื่อเขียนไฟล์เอาต์พุตได้ ซึ่งอาจทำให้ใช้หน่วยความจำมาก
|
expression
|
สตริง ต้องระบุ คําค้นหาที่จะดําเนินการ ซึ่งแตกต่างจากบรรทัดคำสั่งและตำแหน่งอื่นๆ ในไฟล์ BUILD เนื่องจากระบบจะแก้ไขป้ายกำกับที่นี่โดยสัมพันธ์กับไดเรกทอรีรูทของพื้นที่ทำงาน เช่น ป้ายกำกับ: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, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
จะสร้างไฟล์อย่างน้อย 1 ไฟล์โดยใช้คำสั่ง Bash ที่ผู้ใช้กำหนด
Genrules คือกฎการสร้างทั่วไปที่คุณใช้ได้หากไม่มีกฎเฉพาะสำหรับงาน
เช่น คุณอาจเรียกใช้ Bash แบบบรรทัดเดียว อย่างไรก็ตาม หากจำเป็นต้องคอมไพล์ไฟล์ C++ ให้ใช้กฎ cc_*
ที่มีอยู่ เนื่องจากระบบได้ดำเนินการยกน้ำหนักทั้งหมดให้คุณแล้ว
โปรดทราบว่า genrule ต้องใช้เชลล์เพื่อตีความอาร์กิวเมนต์คำสั่ง นอกจากนี้ คุณยังอ้างอิงโปรแกรมใดก็ได้ที่มีอยู่ใน PATH ได้โดยง่าย แต่วิธีนี้จะทำให้คำสั่งไม่สมบูรณ์และอาจทำซ้ำไม่ได้ หากต้องการเรียกใช้เครื่องมือเพียงรายการเดียว ให้ลองใช้ run_binary แทน
อย่าใช้ genrule เพื่อเรียกใช้การทดสอบ มีการผ่อนปรนพิเศษสำหรับการทดสอบและผลการทดสอบ รวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปแล้ว การทดสอบต้องทำงานหลังจากการบิลด์เสร็จสมบูรณ์และบนสถาปัตยกรรมเป้าหมาย ส่วน genrules จะทำงานในระหว่างการบิลด์และบนสถาปัตยกรรม exec (ทั้ง 2 อย่างอาจแตกต่างกัน) หากต้องการกฎการทดสอบสำหรับวัตถุประสงค์ทั่วไป ให้ใช้ sh_test
ข้อควรพิจารณาเกี่ยวกับการรวบรวมคลิป
ดูข้อมูลเพิ่มเติมเกี่ยวกับการคอมไพล์ข้ามภาษาได้จากคู่มือผู้ใช้
ขณะที่ genrules ทำงานระหว่างการบิลด์ ผลลัพธ์มักจะใช้หลังจากการบิลด์เพื่อนำไปใช้งานหรือทดสอบ พิจารณาตัวอย่างการคอมไพล์โค้ด C สําหรับไมโครคอนโทรลเลอร์: คอมไพเลอร์จะยอมรับไฟล์ซอร์ส C และสร้างโค้ดที่ทํางานบนไมโครคอนโทรลเลอร์ โค้ดที่สร้างขึ้นจะไม่สามารถทำงานบน CPU ที่ใช้สร้างได้ แต่คอมไพเลอร์ C (หากคอมไพล์จากซอร์สโค้ด) จะต้องทำงานได้
ระบบบิลด์ใช้การกําหนดค่า exec เพื่ออธิบายเครื่องที่บิลด์ทํางานอยู่ และการกําหนดค่าเป้าหมายเพื่ออธิบายเครื่องที่เอาต์พุตของบิลด์ควรทํางาน โดยจะมีตัวเลือกในการกําหนดค่าแต่ละรายการและแยกไฟล์ที่เกี่ยวข้องออกเป็นไดเรกทอรีแยกต่างหากเพื่อหลีกเลี่ยงข้อขัดแย้ง
สำหรับ genrules ระบบการบิลด์จะตรวจสอบว่ามีการคอมไพล์ทรัพยากร Dependency อย่างเหมาะสม โดยระบบจะคอมไพล์ srcs
(หากจำเป็น) สำหรับการกำหนดค่า target, คอมไพล์ tools
สำหรับการกำหนดค่า exec และถือว่าเอาต์พุตมีไว้สำหรับการกำหนดค่า target นอกจากนี้ยังมี
ตัวแปร "Make" ที่คำสั่ง genrule สามารถส่งไปยังเครื่องมือที่เกี่ยวข้องได้
เราไม่ต้องการให้ genrule กำหนดแอตทริบิวต์ deps
เนื่องจากกฎอื่นๆ ในตัวใช้ข้อมูลเมตาที่ขึ้นอยู่กับภาษาซึ่งส่งผ่านระหว่างกฎต่างๆ เพื่อกำหนดวิธีจัดการกฎแบบใช้ร่วมกันโดยอัตโนมัติ แต่ genrule ไม่สามารถทำงานอัตโนมัติในระดับนี้ได้ Genrules จะทํางานในระดับไฟล์และ runfiles เท่านั้น
กรณีพิเศษ
การคอมไพล์ Exec-exec: ในบางกรณี ระบบบิลด์จำเป็นต้องเรียกใช้ Genrule เพื่อให้ดำเนินการเอาต์พุตได้ในระหว่างบิลด์ด้วย ตัวอย่างเช่น หาก Genrule สร้างคอมไพเลอร์ที่กำหนดเองบางส่วนซึ่งต่อมามีการใช้งานโดย Genrule อื่น กฎแรกต้องสร้างเอาต์พุตสำหรับการกำหนดค่าการดำเนินการ เพราะเป็นที่ที่คอมไพเลอร์จะทำงานใน Genrule อื่น ในกรณีนี้ ระบบบิลด์จะทําในสิ่งที่ถูกต้องโดยอัตโนมัติ โดยจะสร้าง srcs
และ outs
ของ genrule แรกสําหรับการกําหนดค่า exec แทนการกําหนดค่าเป้าหมาย ดูข้อมูลเพิ่มเติมได้ที่คู่มือผู้ใช้
เครื่องมือ JDK และ C++: หากต้องการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์จะมีชุดตัวแปรให้ใช้งาน ดูรายละเอียดได้ที่ตัวแปร"Make"
สภาพแวดล้อม Genrule
คำสั่ง 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)
กับเอาต์พุต เครื่องมือ และแหล่งที่มาอย่างแพร่หลาย เนื่องจากมีการแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าต่างๆ Genrules จึงใช้เส้นทางแบบฮาร์ดโค้ดและ/หรือเส้นทางแบบสัมบูรณ์ไม่ได้ - เขียนมาโคร Starlark ทั่วไปเผื่อในกรณีที่มีการใช้กฎเกณฑ์เดียวกันหรือคล้ายกันมากใน หลายที่ หาก Genrule ซับซ้อน ให้พิจารณาใช้งานในสคริปต์หรือกฎ Starlark ซึ่งจะช่วยปรับปรุงความสามารถในการอ่านและความสามารถในการทดสอบ
- ตรวจสอบว่ารหัสออกแสดงสถานะความสําเร็จหรือความล้มเหลวของ genrule อย่างถูกต้อง
- อย่าเขียนข้อความที่ให้ข้อมูลไปยัง stdout หรือ stderr แม้ว่าจะมีประโยชน์สำหรับการแก้ไขข้อบกพร่อง แต่การดำเนินการนี้อาจกลายเป็นการรบกวนได้ง่ายๆ การดำเนินการ genrule ที่ประสบความสำเร็จควรจะไม่มีเสียง ในทางกลับกัน genrule ที่ทำงานไม่สำเร็จควรแสดงข้อความแสดงข้อผิดพลาดที่ชัดเจน
$$
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 ในกฎอื่นๆ คุณจะใช้ป้ายกํากับของ 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
|
รายการชื่อไฟล์ กำหนดค่าไม่ได้ ต้องระบุ รายการไฟล์ที่กฎนี้สร้างไฟล์เอาต์พุตต้องไม่ข้ามขอบเขตของแพ็กเกจ ระบบจะตีความชื่อไฟล์เอาต์พุตโดยสัมพันธ์กับแพ็กเกจ
หากตั้งค่า Flag
ระบบคาดว่าคําสั่ง genrule จะสร้างไฟล์เอาต์พุตแต่ละไฟล์ในตำแหน่งที่กำหนดไว้ล่วงหน้า
ตำแหน่งพร้อมใช้งานใน |
cmd
|
สตริง ค่าเริ่มต้นคือ $(location)
และตัวแปร "Make"
cmd_bash , cmd_ps และ cmd_bat
หากไม่มีรายการที่เกี่ยวข้อง
หากความยาวบรรทัดคำสั่งเกินขีดจำกัดของแพลตฟอร์ม (64K ใน Linux/macOS, 8K ใน Windows) genrule จะเขียนคำสั่งลงในสคริปต์และเรียกใช้สคริปต์นั้นเพื่อแก้ปัญหา ซึ่งมีผลกับแอตทริบิวต์ cmd ทั้งหมด ( |
cmd_bash
|
สตริง ค่าเริ่มต้นคือ แอตทริบิวต์นี้มีความสำคัญสูงกว่า |
cmd_bat
|
สตริง ค่าเริ่มต้นคือ แอตทริบิวต์นี้มีลำดับความสำคัญสูงกว่า
|
cmd_ps
|
สตริง ค่าเริ่มต้นคือ แอตทริบิวต์นี้มีลําดับความสําคัญสูงกว่า
เราเรียกใช้คำสั่งต่อไปนี้เพื่อตั้งค่าสภาพแวดล้อมก่อนที่จะเรียกใช้คำสั่ง PowerShell ใน genrule เพื่อให้ Powershell ใช้งานได้ง่ายขึ้นและเกิดข้อผิดพลาดน้อยลง
|
executable
|
บูลีน ไม่สามารถกําหนดค่าได้ ค่าเริ่มต้นคือ
การตั้งค่าแฟล็กนี้เป็น "จริง" หมายความว่าเอาต์พุตเป็นไฟล์ปฏิบัติการและเรียกใช้ได้โดยใช้คำสั่ง ระบบไม่รองรับการประกาศข้อมูลที่ต้องพึ่งพาสําหรับไฟล์ปฏิบัติการที่สร้างขึ้น |
local
|
บูลีน ค่าเริ่มต้นคือ
หากตั้งค่าเป็น "จริง" ตัวเลือกนี้จะบังคับให้
ซึ่งเทียบเท่ากับการให้แท็ก "local" ( |
message
|
สตริง ค่าเริ่มต้นคือ
ข้อความความคืบหน้าที่จะพิมพ์เมื่อดำเนินการขั้นตอนการสร้างนี้ โดยค่าเริ่มต้น ข้อความจะเป็น "กำลังสร้าง output" (หรืออะไรสักอย่างเท่าๆ กัน) แต่คุณระบุข้อความที่เจาะจงมากกว่านี้ก็ได้ ใช้แอตทริบิวต์นี้แทน |
output_licenses
|
ประเภทใบอนุญาต ค่าเริ่มต้นคือ common attributes
|
output_to_bindir
|
บูลีน ไม่สามารถกําหนดค่าได้ ค่าเริ่มต้นคือ
หากตั้งค่าเป็น "จริง" ตัวเลือกนี้จะทําให้ระบบเขียนไฟล์เอาต์พุตลงในไดเรกทอรี |
tools
|
รายการป้ายกำกับ ค่าเริ่มต้นคือ
ระบบบิลด์จะสร้างข้อกําหนดเบื้องต้นเหล่านี้ก่อนเรียกใช้คําสั่ง genrule โดยสร้างโดยใช้การกําหนดค่า exec เนื่องจากเครื่องมือเหล่านี้จะทํางานเป็นส่วนหนึ่งของบิลด์ คุณดูเส้นทางของ
|
starlark_doc_extract
ดูแหล่งที่มาของกฎstarlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)
starlark_doc_extract()
จะดึงข้อมูลเอกสารประกอบสำหรับกฎ ฟังก์ชัน (รวมถึงมาโคร) แง่มุม และผู้ให้บริการที่กําหนดหรือส่งออกอีกครั้งในไฟล์ .bzl
หรือ .scl
ที่ระบุ เอาต์พุตของกฎนี้คือ ModuleInfo
โปรโตคอลไบนารีตามที่ระบุไว้
ใน
stardoc_output.proto
ในซอร์สทรี Bazel
เป้าหมายเอาต์พุตโดยนัย
name.binaryproto
(เอาต์พุตเริ่มต้น):ModuleInfo
โปรโตคอลไบนารีname.textproto
(จะสร้างขึ้นก็ต่อเมื่อมีการขออย่างชัดเจนเท่านั้น):name.binaryproto
เวอร์ชันข้อความ proto
คำเตือน: เราไม่รับประกันว่ารูปแบบเอาต์พุตของกฎนี้จะเสถียร โดยมีไว้สำหรับใช้ภายในโดย Stardoc เป็นหลัก
อาร์กิวเมนต์
Attributes | |
---|---|
name |
ชื่อ ต้องระบุ ชื่อที่ไม่ซ้ำกันสําหรับเป้าหมายนี้ |
deps
|
รายการป้ายกํากับ ค่าเริ่มต้นคือ load() โดย
src เป้าหมายเหล่านี้ควรเป็นเป้าหมาย bzl_library ภายใต้การใช้งานปกติ แต่กฎ starlark_doc_extract ไม่ได้บังคับใช้เช่นนั้น และยอมรับเป้าหมายใดก็ตามที่ให้ไฟล์ Starlark ใน DefaultInfo
โปรดทราบว่าไฟล์ Starlark ที่รวมไว้ต้องอยู่ในต้นไม้ซอร์สโค้ด Bazel ไม่สามารถ |
src
|
ป้ายกำกับ (ต้องระบุ) ไฟล์ Starlark ที่จะใช้ดึงข้อมูลเอกสารโปรดทราบว่าไฟล์นี้ต้องเป็นไฟล์ในซอร์สทรี เนื่องจาก Bazel ไม่สามารถ |
render_main_repo_name
|
บูลีน ค่าเริ่มต้นคือ //foo:bar.bzl จะแสดงผลเป็น @main_repo_name//foo:bar.bzl )
ชื่อที่ใช้สำหรับที่เก็บหลักมาจาก คุณควรตั้งค่าแอตทริบิวต์นี้เป็น |
symbol_names
|
รายการสตริง ค่าเริ่มต้นคือ
|
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
|
รายการสตริง nonconfigurable ค่าเริ่มต้นคือ แท็กที่ขึ้นต้นด้วยอักขระ "-" จะถือว่าเป็นแท็กเชิงลบ อักขระ "-" ที่อยู่ก่อนหน้าไม่ถือว่าเป็นส่วนหนึ่งของแท็ก ดังนั้นแท็กชุด "-ขนาดเล็ก" จะตรงกับขนาด "เล็ก" ของการทดสอบ แท็กอื่นๆ ทั้งหมดจะถือว่าเป็นแท็กเชิงบวก หากต้องการทำให้แท็กเชิงบวกชัดเจนยิ่งขึ้น คุณอาจทำให้แท็กขึ้นต้นด้วยอักขระ "+" ได้ด้วย ซึ่งระบบจะไม่ประเมินอักขระนี้เป็นส่วนหนึ่งของข้อความในแท็ก เพียงแต่ทำให้อ่านความแตกต่างระหว่างเชิงบวกและเชิงลบได้ง่ายขึ้น เฉพาะกฎการทดสอบที่ตรงกับแท็กเชิงบวกทั้งหมดและแท็กเชิงลบไม่มีเท่านั้นที่จะรวมอยู่ในชุดทดสอบ โปรดทราบว่านี่ไม่ได้หมายความว่าระบบจะข้ามข้อผิดพลาดในการตรวจสอบทรัพยากร Dependency ในการทดสอบที่ถูกกรองออก แต่ทรัพยากร Dependency ในการทดสอบที่ถูกข้ามยังคงต้องเป็นข้อมูลทางกฎหมาย (เช่น ไม่ได้ถูกบล็อกโดยข้อจํากัดระดับการมองเห็น)
คีย์เวิร์ดแท็ก
โปรดทราบว่า
หากต้องการ |
tests
|
รายการป้ายกำกับ nonconfigurable ค่าเริ่มต้นคือ
โดยยอมรับ
หากไม่ได้ระบุแอตทริบิวต์ |