เป้าหมาย A
ขึ้นอยู่กับเป้าหมาย B
หาก A
ต้องใช้ B
ในเวลาที่สร้างหรือเวลาดำเนินการ ความสัมพันธ์ขึ้นอยู่กับจะทําให้เกิด Directed Acyclic Graph (DAG) เหนือเป้าหมาย และเรียกกันว่ากราฟ Dependency
ทรัพยากร Dependency โดยตรงของเป้าหมายคือเป้าหมายอื่นๆ ที่เข้าถึงได้ด้วยเส้นทางที่มีความยาว 1 ในกราฟทรัพยากร Dependency Dependency แบบทรานซิทีฟของเป้าหมายคือเป้าหมายที่เป้าหมายนั้นต้องอาศัยผ่านเส้นทางที่มีความยาวเท่าใดก็ได้ในกราฟ
อันที่จริงแล้ว ในบริบทของบิลด์ มีกราฟ Dependency 2 แบบ ได้แก่ กราฟของทรัพยากร Dependency และกราฟของทรัพยากร Dependency ที่ประกาศ ส่วนใหญ่แล้ว กราฟ 2 รูปแบบนี้มีความคล้ายคลึงกันมากจนไม่จำเป็นต้องแยกความแตกต่าง แต่ความแตกต่างนี้มีประโยชน์สำหรับการสนทนาด้านล่าง
ทรัพยากร Dependency จริงและที่ประกาศแล้ว
เป้าหมาย X
ขึ้นอยู่กับเป้าหมาย Y
จริงๆ หาก Y
ต้องมีอยู่ สร้างขึ้น และอัปเดตแล้วเพื่อให้สร้าง X
ได้อย่างถูกต้อง ส่วนสร้างอาจหมายถึง สร้าง ประมวลผล คอมไพล์ ลิงก์ เก็บถาวร บีบอัด ดำเนินการ หรืองานประเภทอื่นๆ ที่เกิดขึ้นเป็นประจำระหว่างบิลด์
X
เป้าหมายมีทรัพยากร Dependency ที่ประกาศใน Y
เป้าหมาย หากมีขีดจำกัดทรัพยากร Dependency จาก X
ไปยัง Y
ในแพ็กเกจของ X
กราฟของ Dependency จริง A ต้องเป็นกราฟย่อยของกราฟ Dependency ที่ประกาศ D เพื่อให้บิลด์ถูกต้อง กล่าวคือ โหนด x --> y
ที่เชื่อมต่อโดยตรงทุกคู่ใน A จะต้องเชื่อมต่อโดยตรงใน D ด้วย อาจกล่าวได้ว่า D เป็นค่าประมาณที่มากเกินไปของ A
ผู้เขียนไฟล์ BUILD
ต้องประกาศการขึ้นต่อกันโดยตรงทั้งหมดอย่างชัดเจนสำหรับกฎทุกข้อกับระบบบิลด์ และจะไม่ต้องมีการประกาศอีก
การไม่ปฏิบัติตามหลักการนี้ทำให้เกิดลักษณะการทำงานที่ไม่ได้กำหนด: บิลด์อาจล้มเหลว แต่ที่แย่กว่านั้นคือ บิลด์อาจขึ้นอยู่กับการดำเนินการก่อนหน้าบางอย่าง หรือขึ้นอยู่กับทรัพยากร Dependency ที่ประกาศแบบสับเปลี่ยนซึ่งเป้าหมายเกิดขึ้น Bazel จะตรวจหาการขึ้นต่อกันที่ขาดหายไปและรายงานข้อผิดพลาด แต่การตรวจสอบนี้อาจไม่เสร็จสมบูรณ์ในทุกกรณี
คุณไม่จำเป็นต้อง (และไม่ควร) พยายามแสดงรายการทุกอย่างที่นำเข้าโดยอ้อม
แม้ว่า A
จะจำเป็นขณะดำเนินการก็ตาม
ระหว่างบิลด์ของเป้าหมาย X
เครื่องมือสร้างจะตรวจสอบการปิดแบบทรานซิชันทั้งหมดของทรัพยากร Dependency ของ X
เพื่อให้แน่ใจว่าการเปลี่ยนแปลงในเป้าหมายเหล่านั้นแสดงในผลลัพธ์สุดท้าย รวมถึงสร้างตัวกลางใหม่ตามที่จำเป็น
ลักษณะการส่งต่อของทรัพยากร Dependency จะทําให้เกิดข้อผิดพลาดที่พบบ่อย บางครั้งโค้ดในไฟล์หนึ่งอาจใช้โค้ดที่ระบุโดยทรัพยากร Dependency โดยอ้อม ซึ่งเป็นการสลายตัวแต่ไม่ใช่ขอบโดยตรงในกราฟทรัพยากร Dependency ที่ประกาศ การขึ้นต่อกันโดยอ้อมจะไม่ปรากฏในไฟล์ BUILD
เนื่องจากกฎไม่ได้ขึ้นอยู่กับผู้ให้บริการโดยตรง จึงไม่มีวิธีติดตามการเปลี่ยนแปลง ดังที่แสดงในไทม์ไลน์ตัวอย่างต่อไปนี้
1. ทรัพยากร Dependency ที่ประกาศตรงกับทรัพยากร Dependency จริง
ตอนแรกทุกอย่างทำงานได้ตามปกติ โค้ดในแพ็กเกจ a
ใช้โค้ดในแพ็กเกจ b
โค้ดในแพ็กเกจ b
ใช้โค้ดในแพ็กเกจ c
ดังนั้น a
จึงขึ้นอยู่กับ c
a/BUILD |
b/BUILD |
---|---|
rule( name = "a", srcs = "a.in", deps = "//b:b", ) |
rule( name = "b", srcs = "b.in", deps = "//c:c", ) |
a / a.in |
b / b.in |
import b; b.foo(); |
import c; function foo() { c.bar(); } |
ทรัพยากร Dependency ที่ประกาศไว้ใกล้เคียงกับทรัพยากร Dependency จริงมากเกินไป ทุกอย่างเรียบร้อยดี
2. การเพิ่มทรัพยากร Dependency ที่ไม่ได้ประกาศ
เกิดอันตรายแฝงเมื่อมีคนเพิ่มโค้ดไปยัง a
ที่สร้างทรัพยากร Dependency จริง โดยตรงใน c
แต่ลืมประกาศในไฟล์บิลด์ a/BUILD
a / a.in |
|
---|---|
import b; import c; b.foo(); c.garply(); |
|
Dependency ที่ประกาศจะไม่ประมาณค่า Dependency จริงมากเกินไปอีกต่อไป
การดำเนินการนี้อาจสร้างได้สําเร็จ เนื่องจาก Closure แบบทรานซิทีฟของกราฟ 2 รายการเท่ากัน แต่ซ่อนปัญหาไว้: a
มีการพึ่งพา c
จริงแต่ไม่ได้ประกาศ
3. ความแตกต่างระหว่างกราฟทรัพยากร Dependency ที่ประกาศกับกราฟการอ้างอิงจริง
อันตรายจะถูกเปิดเผยเมื่อมีคนเปลี่ยนโครงสร้างภายในโค้ด b
เพื่อที่จะได้ไม่ต้องพึ่งพา c
อีกต่อไป โดยทำให้ a
เสียหายโดยไม่ตั้งใจ
b/BUILD |
|
---|---|
rule( name = "b", srcs = "b.in", deps = "//d:d", ) |
|
b / b.in |
|
import d; function foo() { d.baz(); } |
|
ขณะนี้กราฟทรัพยากร Dependency ที่ประกาศแสดงค่าการขึ้นต่อกันจริงน้อยเกินไปแม้ว่าจะปิดแบบสับเปลี่ยนแล้ว บิลด์ก็มีแนวโน้มที่จะล้มเหลว
ปัญหานี้อาจหลีกเลี่ยงได้ด้วยการยืนยันว่ามีการประกาศการพึ่งพาจริงจาก a
ไปยัง c
ที่ระบุไว้ในขั้นตอนที่ 2 อย่างถูกต้องในไฟล์ BUILD
ประเภทของทรัพยากร Dependency
กฎการสร้างส่วนใหญ่มีแอตทริบิวต์ 3 รายการสําหรับระบุข้อกําหนดทั่วไปประเภทต่างๆ ได้แก่ srcs
, deps
และ data
โปรดดูคำอธิบายด้านล่าง โปรดดูรายละเอียดเพิ่มเติมที่หัวข้อแอตทริบิวต์ที่มีอยู่ในกฎทั้งหมด
กฎจำนวนมากยังมีแอตทริบิวต์เพิ่มเติมสำหรับประเภทการขึ้นต่อกันที่เจาะจงกฎ เช่น compiler
หรือ resources
ซึ่งมีรายละเอียดอยู่ใน Build Encyclopedia
srcs
Dependency
ไฟล์ที่กฎหรือกฎใช้โดยตรงซึ่งแสดงผลไฟล์ต้นฉบับ
ทรัพยากร Dependency deps
กฎที่ชี้ไปยังโมดูลที่คอมไพล์แยกกันจะมีไฟล์ส่วนหัว สัญลักษณ์ ไลบรารี ข้อมูล ฯลฯ
ทรัพยากร Dependency data
เป้าหมายการสร้างอาจต้องใช้ไฟล์ข้อมูลบางอย่างเพื่อให้ทำงานได้อย่างถูกต้อง ไฟล์ข้อมูลเหล่านี้ไม่ใช่ซอร์สโค้ด จึงไม่ส่งผลต่อวิธีสร้างเป้าหมาย เช่น การทดสอบหน่วยอาจเปรียบเทียบเอาต์พุตของฟังก์ชันกับเนื้อหาของไฟล์ เมื่อสร้างการทดสอบหน่วย คุณไม่จำเป็นต้องใช้ไฟล์ แต่ต้องใช้เมื่อเรียกใช้การทดสอบ เช่นเดียวกับเครื่องมือที่เปิดใช้งานระหว่างการดําเนินการ
ระบบบิลด์จะทำการทดสอบในไดเรกทอรีที่แยกต่างหากซึ่งมีเฉพาะไฟล์ที่ระบุว่าเป็น data
เท่านั้น ดังนั้น หากไบนารี/ไลบรารี/การทดสอบต้องใช้ไฟล์บางไฟล์เพื่อทำงาน ให้ระบุไฟล์เหล่านั้น (หรือกฎการสร้างที่มีไฟล์เหล่านั้น) ใน data
เช่น
# I need a config file from a directory named env:
java_binary(
name = "setenv",
...
data = [":env/default_env.txt"],
)
# I need test data from another directory
sh_test(
name = "regtest",
srcs = ["regtest.sh"],
data = [
"//data:file1.txt",
"//data:file2.txt",
...
],
)
ไฟล์เหล่านี้จะพร้อมใช้งานโดยใช้เส้นทางแบบสัมพัทธ์ path/to/data/file
ในการทดสอบ คุณสามารถอ้างอิงไฟล์เหล่านี้ได้โดยรวมเส้นทางของไดเรกทอรีต้นทางของการทดสอบเข้ากับเส้นทางแบบสัมพัทธ์กับ Workspace เช่น ${TEST_SRCDIR}/workspace/path/to/data/file
การใช้ป้ายกำกับเพื่ออ้างอิงไดเรกทอรี
เมื่อดูไฟล์ BUILD
คุณอาจสังเกตเห็นว่าป้ายกำกับ data
บางรายการอ้างอิงถึงไดเรกทอรี ป้ายกำกับเหล่านี้ลงท้ายด้วย /.
หรือ /
ดังตัวอย่างต่อไปนี้
ซึ่งคุณไม่ควรใช้
ไม่แนะนำ —
data = ["//data/regression:unittest/."]
ไม่แนะนำ —
data = ["testdata/."]
ไม่แนะนำ —
data = ["testdata/"]
วิธีนี้ดูจะสะดวกดี โดยเฉพาะสำหรับการทดสอบ เนื่องจากช่วยให้การทดสอบใช้ไฟล์ข้อมูลทั้งหมดในไดเรกทอรีได้
แต่อย่าพยายามทำเช่นนั้น ระบบบิลด์ต้องทราบชุดไฟล์ทั้งหมดที่เป็นอินพุตของบิลด์ (หรือการทดสอบ) เพื่อให้แน่ใจว่าการสร้างใหม่แบบเพิ่มทีละน้อย (และการดำเนินการทดสอบอีกครั้ง) หลังจากการเปลี่ยนแปลงนั้นถูกต้อง เมื่อคุณระบุไดเรกทอรี ระบบบิลด์จะสร้างใหม่เฉพาะในกรณีที่ไดเรกทอรีนั้นๆ เปลี่ยนแปลง (เนื่องจากการเพิ่มหรือลบไฟล์) แต่จะตรวจไม่พบการแก้ไขไฟล์แต่ละไฟล์ เนื่องจากการเปลี่ยนแปลงเหล่านั้นไม่ส่งผลต่อไดเรกทอรีที่รวมอยู่
แทนที่จะระบุไดเรกทอรีเป็นอินพุตไปยังระบบบิลด์ คุณควรแจกแจงชุดของไฟล์ที่อยู่ในไดเรกทอรีเหล่านั้นให้ชัดเจนหรือใช้ฟังก์ชัน glob()
ก็ได้ (ใช้ **
เพื่อบังคับให้ glob()
เป็นแบบซ้ำซ้อน)
แนะนำ —
data = glob(["testdata/**"])
แต่น่าเสียดายที่บางสถานการณ์จำเป็นต้องใช้ป้ายกำกับไดเรกทอรี
เช่น หากไดเรกทอรี testdata
มีไฟล์ที่มีชื่อไม่เป็นไปตามไวยากรณ์ของป้ายกำกับ การแจกแจงไฟล์อย่างชัดแจ้งหรือการใช้ฟังก์ชัน glob()
จะทำให้เกิดข้อผิดพลาดป้ายกำกับไม่ถูกต้อง ในกรณีนี้ คุณต้องใช้ป้ายกำกับไดเรกทอรี แต่โปรดระวังความเสี่ยงที่อาจเกิดขึ้นจากการสร้างขึ้นใหม่ที่ไม่ถูกต้องตามที่อธิบายไว้ข้างต้น
หากต้องใช้ป้ายกำกับไดเรกทอรี โปรดทราบว่าคุณจะอ้างอิงแพ็กเกจหลักด้วยเส้นทางสัมพัทธ์ ../
ไม่ได้ โปรดใช้เส้นทางสัมบูรณ์ เช่น //data/regression:unittest/.
แทน
กฎภายนอก เช่น การทดสอบ ที่ต้องใช้สําเนาไฟล์หลายรายการต้องประกาศอย่างชัดแจ้งว่าต้องอาศัยไฟล์ทั้งหมด คุณใช้ filegroup()
เพื่อจัดกลุ่มไฟล์เข้าด้วยกันในไฟล์ BUILD
ได้ ดังนี้
filegroup(
name = 'my_data',
srcs = glob(['my_unittest_data/*'])
)
จากนั้นคุณจะอ้างอิงป้ายกํากับ my_data
เป็นการพึ่งพาข้อมูลในการทดสอบได้
ไฟล์ BUILD | ระดับการแชร์ |