Bazel จะสร้างซอฟต์แวร์จากซอร์สโค้ดที่จัดระเบียบในลําดับชั้นไดเรกทอรีที่เรียกว่า "เวิร์กสเปซ" ไฟล์ต้นฉบับในพื้นที่ทํางานจะจัดระเบียบในลําดับชั้นที่ซ้อนกันของแพ็กเกจ โดยแต่ละแพ็กเกจคือไดเรกทอรีที่มีชุดไฟล์ต้นฉบับที่เกี่ยวข้องและไฟล์ BUILD 1 ไฟล์ ไฟล์ BUILD จะระบุเอาต์พุตซอฟต์แวร์ที่สร้างจากแหล่งที่มาได้
Workspace
workspace คือโครงสร้างไดเรกทอรีในระบบไฟล์ที่มีไฟล์ต้นทางของซอฟต์แวร์ที่ต้องการสร้าง แต่ละเวิร์กช็อปจะมีไฟล์ข้อความชื่อ WORKSPACE ซึ่งอาจเป็นไฟล์เปล่า หรือมีการอ้างอิงถึงทรัพยากรภายนอกที่จําเป็นสําหรับสร้างเอาต์พุต
ไดเรกทอรีที่มีไฟล์ชื่อ WORKSPACE จะถือว่าเป็นรูทของพื้นที่ทำงาน ดังนั้น Bazel จะไม่สนใจลําดับชั้นไดเรกทอรีในเวิร์กสเปซที่รูทที่ไดเรกทอรีย่อยซึ่งมีไฟล์ WORKSPACE เนื่องจากเป็นเวิร์กสเปซอื่น
นอกจากนี้ Bazel ยังรองรับไฟล์ WORKSPACE.bazel เป็นอีเมลแทนของไฟล์ WORKSPACE ด้วย
หากมีทั้ง 2 ไฟล์ ระบบจะใช้ WORKSPACE.bazel
ที่เก็บ
โค้ดจะจัดระเบียบไว้ในที่เก็บ ไดเรกทอรีที่มีไฟล์ WORKSPACE
คือรูทของที่เก็บหลักหรือที่เรียกว่า @ รีโพซิทอรีอื่นๆ (ภายนอก) จะกำหนดไว้ในไฟล์ WORKSPACE โดยใช้กฎของ Workspace
กฎของ Workspace ที่รวมอยู่กับ Bazel มีอยู่ในหัวข้อกฎของ Workspace ในสารานุกรมการสร้างและเอกสารประกอบเกี่ยวกับกฎของที่เก็บ Starlark ที่ฝัง
เนื่องจากที่เก็บข้อมูลภายนอกเป็นที่เก็บข้อมูลด้วยเช่นกัน จึงมักจะมีไฟล์ WORKSPACE ด้วย อย่างไรก็ตาม Bazel จะละเว้นไฟล์ WORKSPACE เพิ่มเติมเหล่านี้ โดยเฉพาะอย่างยิ่ง ที่เก็บที่ขึ้นอยู่กับทรานซิทีฟจะไม่เพิ่มโดยอัตโนมัติ
แพ็กเกจ
หน่วยหลักของการจัดระเบียบโค้ดในที่เก็บคือแพ็กเกจ แพ็กเกจคือคอลเล็กชันของไฟล์ที่เกี่ยวข้องและข้อกำหนดวิธีใช้ไฟล์ดังกล่าวเพื่อสร้างอาร์ติแฟกต์เอาต์พุต
แพ็กเกจหมายถึงไดเรกทอรีที่มีไฟล์ชื่อ BUILD (หรือ BUILD.bazel) แพ็กเกจประกอบด้วยไฟล์ทั้งหมดในไดเรกทอรีนั้น รวมถึงไดเรกทอรีย่อยทั้งหมดที่อยู่ภายใต้ไดเรกทอรีนั้น ยกเว้นไดเรกทอรีย่อยที่มีไฟล์ BUILD อยู่ด้วย จากคำจำกัดความนี้ ไฟล์หรือไดเรกทอรีต้องไม่เป็นส่วนหนึ่งของแพ็กเกจที่แตกต่างกัน 2 รายการ
ตัวอย่างเช่น ในลําดับชั้นไดเรกทอรีต่อไปนี้ มีแพ็กเกจ 2 รายการ ได้แก่ my/app และแพ็กเกจย่อย my/app/tests
โปรดทราบว่า my/app/data ไม่ใช่แพ็กเกจ แต่เป็นไดเรกทอรีที่อยู่ในแพ็กเกจ my/app
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
เป้าหมาย
แพ็กเกจคือคอนเทนเนอร์ของเป้าหมาย ซึ่งกำหนดไว้ในไฟล์ BUILD ของแพ็กเกจ เป้าหมายส่วนใหญ่จะเป็น 1 ใน 2 ประเภทหลัก ได้แก่ ไฟล์และกฎ
ไฟล์แบ่งออกเป็น 2 ประเภท ได้แก่ ไฟล์ต้นฉบับมักจะเขียนขึ้นโดยความร่วมมือของผู้คน และส่งไปยังที่เก็บ ไฟล์ที่สร้างขึ้น ซึ่งบางครั้งเรียกว่าไฟล์ที่ดึงข้อมูลมาหรือไฟล์เอาต์พุต จะไม่ได้รับการเช็คอิน แต่สร้างขึ้นจากไฟล์ต้นทาง
เป้าหมายประเภทที่ 2 ประกาศด้วยกฎ อินสแตนซ์ของกฎแต่ละรายการจะระบุความสัมพันธ์ระหว่างชุดอินพุตกับชุดไฟล์เอาต์พุต อินพุตของกฎอาจเป็นไฟล์ต้นทาง แต่ก็อาจเป็นเอาต์พุตของกฎอื่นๆ ได้ด้วย
ในกรณีส่วนใหญ่ อินพุตของกฎจะเป็นไฟล์ต้นฉบับหรือไฟล์ที่สร้างขึ้นก็ได้ สิ่งที่สำคัญคือเนื้อหาของไฟล์นั้น ความจริงข้อนี้ช่วยให้คุณแทนที่ไฟล์ต้นฉบับที่ซับซ้อนด้วยไฟล์ที่สร้างขึ้นโดยกฎได้ง่ายๆ เช่น ในกรณีที่ภาระการดูแลไฟล์ที่มีโครงสร้างสูงด้วยตนเองเริ่มหนักเกินไป และมีคนเขียนโปรแกรมเพื่อดึงข้อมูลไฟล์ ผู้ใช้ไฟล์ดังกล่าวไม่จําเป็นต้องทําการเปลี่ยนแปลงใดๆ ในทางกลับกัน ไฟล์ที่สร้างขึ้นอาจถูกแทนที่ได้อย่างง่ายดายด้วยไฟล์ต้นฉบับที่มีการเปลี่ยนแปลงเฉพาะในเครื่องเท่านั้น
ข้อมูลที่ป้อนลงในกฎอาจรวมถึงกฎอื่นๆ ด้วย ความหมายที่แน่นอนของความสัมพันธ์ดังกล่าวมักค่อนข้างซับซ้อนและขึ้นอยู่กับภาษาหรือกฎ แต่โดยสังเขปแล้วนั้นง่ายมาก กฎห้องสมุด C++ ก อาจใช้กฎห้องสมุด C++ ข เป็นอินพุต ผลของการพึ่งพานี้คือ ไฟล์ส่วนหัวของ B จะพร้อมใช้งานสำหรับ A ในระหว่างการคอมไพล์ สัญลักษณ์ของ B จะพร้อมใช้งานสำหรับ A ในระหว่างการลิงก์ และข้อมูลรันไทม์ของ B จะพร้อมใช้งานสำหรับ A ในระหว่างการเรียกใช้
กฎทั้งหมดมีความแปรปรวนคือ ไฟล์ที่สร้างโดยกฎจะเป็นของแพ็กเกจเดียวกันกับกฎเสมอ และจะสร้างไฟล์ลงในแพ็กเกจอื่นไม่ได้ อย่างไรก็ตาม การที่อินพุตของกฎมาจากแพ็กเกจอื่นนั้นไม่ใช่เรื่องแปลก
กลุ่มแพ็กเกจคือชุดของแพ็กเกจที่มีวัตถุประสงค์เพื่อจํากัดการเข้าถึงกฎบางอย่าง กลุ่มแพ็กเกจจะกำหนดโดยฟังก์ชัน package_group
โดยจะมี 3 คุณสมบัติ ได้แก่ รายการแพ็กเกจที่มี ชื่อ และกลุ่มแพ็กเกจอื่นๆ ที่มี วิธีเดียวที่อนุญาตในการอ้างอิงคือจากแอตทริบิวต์ visibility ของกฎหรือจากแอตทริบิวต์ default_visibility ของฟังก์ชัน package โดยจะไม่สร้างหรือใช้ไฟล์
ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบpackage_group