หน้านี้จะถือว่าคุณคุ้นเคยกับ Bazel และมีคําแนะนําและคําแนะนําเกี่ยวกับโครงสร้างของโปรเจ็กต์เพื่อใช้ประโยชน์จากฟีเจอร์ของ Bazel อย่างเต็มที่
เป้าหมายโดยรวมมีดังนี้
- การใช้ทรัพยากร Dependency แบบละเอียดเพื่ออนุญาตการโหลดพร้อมกันและส่วนเพิ่ม
- เก็บข้อมูลทรัพยากร Dependency ให้แน่นหนาอยู่เสมอ
- ทําให้โค้ดมีโครงสร้างที่ดีและทดสอบได้
- เพื่อสร้างการกําหนดค่าบิวด์ที่เข้าใจและดูแลรักษาได้ง่าย
หลักเกณฑ์เหล่านี้ไม่ใช่ข้อกําหนด: มีเพียงไม่กี่โปรเจ็กต์ที่จะปฏิบัติตามหลักเกณฑ์ทั้งหมดได้ หน้า Landing Page กล่าวว่า "เจ้าหน้าที่จะเสนอรางวัลสุดพิเศษให้แก่บุคคลแรกที่ผลิตโปรแกรมจริงที่ไม่ก่อให้เกิดข้อผิดพลาดเกี่ยวกับการตรวจสอบที่เข้มงวด" อย่างไรก็ตาม การใช้หลักการเหล่านี้ให้มากที่สุดควรทําให้โปรเจ็กต์อ่านได้ง่ายขึ้น มีข้อผิดพลาดน้อยลง และสร้างขึ้นได้เร็วขึ้น
หน้านี้ใช้ระดับข้อกําหนดที่อธิบายไว้ใน RFC นี้
การเรียกใช้บิลด์และการทดสอบ
โปรเจ็กต์ควรเรียกใช้ bazel build //... และ bazel test //... ในสาขาที่เสถียรได้เสมอ เป้าหมายที่จําเป็นแต่ไม่สร้างภายใต้สถานการณ์บางอย่าง (เช่น ต้องมีแฟล็กบิวด์เฉพาะ ไม่สร้างในบางแพลตฟอร์ม ต้องการข้อตกลงการอนุญาตให้ใช้สิทธิ) ควรติดแท็กให้เฉพาะเจาะจงมากที่สุด (เช่น "requires-osx") การติดแท็กนี้ช่วยให้กําหนดเป้าหมายการกรองได้ในระดับที่ละเอียดกว่าแท็ก "ด้วยตนเอง" และอนุญาตให้ผู้ที่ตรวจสอบไฟล์ BUILD เข้าใจว่าข้อจํากัดของเป้าหมายคืออะไร
ทรัพยากร Dependency ของบุคคลที่สาม
คุณสามารถประกาศทรัพยากร Dependency ของบุคคลที่สามได้ ดังนี้
- ประกาศว่าเป็นที่เก็บระยะไกลในไฟล์
WORKSPACE - หรือใส่ไว้ในไดเรกทอรีชื่อ
third_party/ภายใต้ไดเรกทอรีของพื้นที่ทํางาน
ขึ้นอยู่กับไบนารี
ทุกอย่างควรสร้างขึ้นจากแหล่งที่มาทุกครั้งที่ทําได้ โดยทั่วไปแล้วหมายความว่าคุณอาจต้องสร้างไฟล์ BUILD และสร้าง some-library.so จากต้นทาง แทนที่จะขึ้นไลบรารี some-library.so โดยขึ้นอยู่กับเป้าหมายนั้น
การสร้างขึ้นจากแหล่งที่มาเสมอเป็นการตรวจสอบว่าบิลด์ไม่ได้ใช้ไลบรารีที่สร้างขึ้นด้วยแฟล็กที่เข้ากันไม่ได้หรือสถาปัตยกรรมอื่น และยังมีฟีเจอร์บางอย่าง เช่น การครอบคลุม การวิเคราะห์แบบคงที่ หรือการวิเคราะห์แบบไดนามิกที่ใช้ได้กับแหล่งที่มาเท่านั้น
การกำหนดเวอร์ชัน
ต้องการสร้างรหัสทั้งหมดจากส่วนหัวเมื่อใดก็ตามที่ทําได้ เมื่อต้องใช้เวอร์ชันต่างๆ ให้หลีกเลี่ยงการใส่เวอร์ชันไว้ในชื่อเป้าหมาย (เช่น //guava ไม่ใช่ //guava-20.0) การตั้งชื่อนี้ช่วยให้ไลบรารีอัปเดตได้ง่ายขึ้น (ต้องอัปเดตเป้าหมายเพียงรายการเดียวเท่านั้น) และมีความยืดหยุ่นต่อปัญหาเพชรมากกว่า กล่าวคือหากไลบรารีหนึ่งขึ้นอยู่กับ guava-19.0 และอีกไลบรารีหนึ่งขึ้นอยู่กับ guava-20.0 คุณอาจได้ไลบรารีที่พยายามพึ่งพา 2 เวอร์ชันที่ต่างกัน
หากคุณสร้างชื่อแทนที่ทําให้เข้าใจผิดให้ชี้เป้าหมายทั้ง 2 รายการไปยังไลบรารี guava ไฟล์เดียว แสดงว่าไฟล์ BUILD ทําให้เข้าใจผิด
การใช้ไฟล์ .bazelrc
หากต้องการดูตัวเลือกเฉพาะโปรเจ็กต์ ให้ใช้ไฟล์การกําหนดค่า workspace/.bazelrc ของคุณ (ดูรูปแบบ Bazelcc)
หากต้องการรองรับตัวเลือกต่อผู้ใช้สําหรับโปรเจ็กต์ที่คุณไม่ต้องการตรวจสอบการควบคุมแหล่งที่มา ให้ใส่บรรทัดต่อไปนี้
try-import %workspace%/user.bazelrc
(หรือชื่อไฟล์อื่นๆ) ใน workspace/.bazelrc และเพิ่ม user.bazelrc ใน .gitignore
กล่องพัสดุ
ทุกไดเรกทอรีที่มีไฟล์ที่สร้างได้ควรเป็นแพ็กเกจ หากไฟล์ BUILD หมายถึงไฟล์ในไดเรกทอรีย่อย (เช่น srcs = ["a/b/C.java"]) นั่นเป็นสัญญาณที่ควรเพิ่มไฟล์ BUILD ไปยังไดเรกทอรีย่อยนั้น ยิ่งโครงสร้างนี้เกิดขึ้นนานเท่าไร ทรัพยากร Dependency แบบวงกลมที่ระบบจะสร้างขึ้นก็จะมีแนวโน้มสูงขึ้น ขอบเขตของเป้าหมายจะค่อยๆ เพิ่มขึ้น และต้องอัปเดตทรัพยากร Dependency แบบย้อนกลับมากขึ้นเรื่อยๆ