การดำเนินการ
คำสั่งที่จะเรียกใช้ระหว่างการสร้าง เช่น การเรียกใช้คอมไพเลอร์ที่ใช้อาร์ติแฟกต์เป็นอินพุตและสร้างอาร์ติแฟกต์อื่นๆ เป็นเอาต์พุต รวมถึงข้อมูลเมตา เช่น อ argu อาร์กิวเมนต์บรรทัดคำสั่ง คีย์การดำเนินการ ตัวแปรสภาพแวดล้อม และอาร์ติแฟกต์อินพุต/เอาต์พุตที่ประกาศ
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับกฎ
แคชการดำเนินการ
แคชในดิสก์ที่จัดเก็บการแมปการดำเนินการที่ดำเนินการกับเอาต์พุตที่สร้างขึ้น คีย์แคชเรียกว่าคีย์การดำเนินการ คอมโพเนนต์หลักสำหรับรูปแบบการทํางานแบบเพิ่มของ Bazel ระบบจะจัดเก็บแคชไว้ในไดเรกทอรีฐานเอาต์พุต ดังนั้นแคชจะยังคงอยู่แม้ว่าเซิร์ฟเวอร์ Bazel จะรีสตาร์ท
กราฟการกระทํา
กราฟในหน่วยความจําของการดําเนินการและอาร์ติแฟกต์ที่การดําเนินการเหล่านี้อ่านและสร้าง กราฟอาจประกอบด้วยอาร์ติแฟกต์ที่เป็นไฟล์ต้นทาง (เช่น ในระบบไฟล์) รวมถึงอาร์ติแฟกต์ระดับกลาง/ขั้นสุดท้ายที่สร้างขึ้นซึ่งไม่ได้กล่าวถึงในไฟล์ BUILD
สร้างขึ้นระหว่างระยะการวิเคราะห์และใช้ระหว่างระยะการดําเนินการ
การค้นหากราฟการดำเนินการ (aquery)
เครื่องมือการค้นหาที่สามารถค้นหาการดำเนินการของบิลด์ ซึ่งจะช่วยให้คุณวิเคราะห์ได้ว่ากฎการสร้างส่งผลต่อการสร้างงานที่ทำงานจริงอย่างไร
ปุ่มดำเนินการ
คีย์แคชของการดําเนินการ คํานวณตามข้อมูลเมตาของการดำเนินการ ซึ่งอาจรวมถึงคําสั่งที่จะดําเนินการในการดําเนินการ แฟล็กคอมไพเลอร์ ตําแหน่งไลบรารี หรือส่วนหัวของระบบ ทั้งนี้ขึ้นอยู่กับการดำเนินการ เปิดใช้ Bazel เพื่อแคชหรือทำให้การดำเนินการแต่ละรายการเป็นโมฆะอย่างแน่ชัด
ระยะการวิเคราะห์
เฟสที่ 2 ของการสร้าง ประมวลผลกราฟเป้าหมายที่ระบุไว้ในไฟล์ BUILD
เพื่อสร้างกราฟการดำเนินการในหน่วยความจำซึ่งกำหนดลำดับการดำเนินการที่จะเรียกใช้ในระหว่างระยะการดําเนินการ ระยะนี้คือระยะที่ประเมินการใช้งานกฎ
อาร์ติแฟกต์
ไฟล์ต้นฉบับหรือไฟล์ที่สร้างขึ้น หรืออาจเป็นไดเรกทอรีของไฟล์ที่เรียกว่ารายการในต้นไม้
อาร์ติแฟกต์อาจเป็นอินพุตสําหรับการดําเนินการหลายรายการ แต่ต้องสร้างขึ้นโดยการดําเนินการเพียงรายการเดียวเท่านั้น
คุณระบุอาร์ติแฟกต์ที่สอดคล้องกับเป้าหมายไฟล์ได้ด้วยป้ายกำกับ
อัตราส่วน
กลไกสําหรับกฎในการสร้างการดําเนินการเพิ่มเติมในข้อกําหนด เช่น หากเป้าหมาย ก ขึ้นอยู่กับ ข ผู้ใช้สามารถใช้แง่มุมใน ก ที่ขึ้นขอบความเกี่ยวข้องไปยัง ข และเรียกใช้การดำเนินการเพิ่มเติมใน ข เพื่อสร้างและรวบรวมไฟล์เอาต์พุตเพิ่มเติม ระบบจะแคชการดําเนินการเพิ่มเติมเหล่านี้ไว้และนําไปใช้ซ้ำระหว่างเป้าหมายที่จําเป็นต้องใช้แง่มุมเดียวกัน สร้างด้วย
aspect()
ฟังก์ชัน Starlark Build API สามารถใช้เพื่อดำเนินการต่างๆ เช่น สร้างข้อมูลเมตาสำหรับ IDE และสร้างการดำเนินการสำหรับการแก้ไขโค้ด
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับแง่มุม
การแสดงภาพซ้อนภาพ
กลไกการคอมโพสิชันที่สามารถใช้แง่มุมกับผลลัพธ์ของแง่มุมอื่นๆ ได้ ตัวอย่างเช่น คุณสามารถใช้แง่มุมที่สร้างข้อมูลให้ IDE ใช้ได้กับแง่มุมที่สร้างไฟล์ .java
จาก proto
หากต้องการให้แง่มุม A
มีผลเหนือแง่มุม B
ผู้ให้บริการที่ B
โฆษณาในแอตทริบิวต์ provides
ต้องตรงกับสิ่งที่ A
ประกาศว่าต้องการในแอตทริบิวต์ required_aspect_providers
แอตทริบิวต์
พารามิเตอร์ของกฎที่ใช้แสดงข้อมูลการสร้างต่อเป้าหมาย
ตัวอย่างเช่น srcs
, deps
และ copts
ซึ่งจะประกาศไฟล์ต้นฉบับของเป้าหมาย ไลบรารีที่ใช้ร่วมกัน และตัวเลือกคอมไพเลอร์ที่กำหนดเองตามลำดับ แอตทริบิวต์ที่พร้อมใช้งานสําหรับเป้าหมายหนึ่งๆ จะขึ้นอยู่กับประเภทกฎ
.bazelrc
ไฟล์การกําหนดค่าของ Bazel ใช้เพื่อเปลี่ยนค่าเริ่มต้นสําหรับFlag เริ่มต้นและFlag ของคําสั่ง รวมถึงเพื่อกําหนดกลุ่มตัวเลือกทั่วไปซึ่งสามารถตั้งค่าร่วมกันในบรรทัดคําสั่งของ Bazel โดยใช้ Flag --config
Bazel สามารถรวมการตั้งค่าจากไฟล์ bazelrc หลายไฟล์ (ทั้งระบบ ต่อพื้นที่ทํางาน ต่อผู้ใช้ หรือจากตําแหน่งที่กำหนดเอง) และไฟล์ bazelrc
ยังนําเข้าการตั้งค่าจากไฟล์ bazelrc
อื่นๆ ได้ด้วย
Blaze
Bazel เวอร์ชันภายในของ Google ระบบบิลด์หลักของ Google สำหรับที่เก็บแบบโมโน
ไฟล์ BUILD
ไฟล์ BUILD
คือไฟล์การกําหนดค่าหลักที่บอก Bazel ว่าต้องสร้างเอาต์พุตซอฟต์แวร์ใด รายการใดบ้างที่ต้องพึ่งพา และวิธีสร้าง Bazel จะรับไฟล์ BUILD
เป็นอินพุต และใช้ไฟล์ดังกล่าวเพื่อสร้างกราฟของข้อกําหนด และดึงข้อมูลการดําเนินการที่ต้องทำเพื่อสร้างเอาต์พุตซอฟต์แวร์ระดับกลางและขั้นสุดท้าย ไฟล์ BUILD
จะทําเครื่องหมายไดเรกทอรีและไดเรกทอรีย่อยที่ไม่มีไฟล์ BUILD
เป็นแพ็กเกจ และอาจมีเป้าหมายที่สร้างขึ้นโดยกฎ หรือจะตั้งชื่อไฟล์เป็น
BUILD.bazel
ก็ได้
ไฟล์ BUILD.bazel
ดูBUILD
ไฟล์ มีความสำคัญเหนือกว่าไฟล์ BUILD
ในไดเรกทอรีเดียวกัน
ไฟล์ .bzl
ไฟล์ที่กําหนดกฎ มาโคร และค่าคงที่ที่เขียนใน Starlark จากนั้นจะนําเข้าข้อมูลเหล่านี้ไปยังBUILD
ไฟล์ได้โดยใช้ฟังก์ชัน load()
สร้างกราฟ
กราฟทรัพยากร Dependency ที่ Bazel สร้างและเรียกใช้เพื่อทำการบิลด์ ซึ่งรวมถึงโหนดต่างๆ เช่น เป้าหมาย เป้าหมายที่กําหนดค่าแล้ว การดําเนินการ และอาร์ติแฟกต์ ระบบจะถือว่าบิลด์เสร็จสมบูรณ์เมื่ออาร์ติแฟกต์ทั้งหมดที่ชุดเป้าหมายที่ขอใช้นั้นได้รับการยืนยันแล้วว่าเป็นเวอร์ชันล่าสุด
การตั้งค่าบิลด์
การกําหนดค่าที่ Starlark กำหนด ทรานซิชันสามารถตั้งค่าการสร้างเพื่อเปลี่ยนการกำหนดค่าของกราฟย่อย หากแสดงต่อผู้ใช้เป็นFlag บรรทัดคำสั่ง หรือที่เรียกว่า Flag การสร้าง
บิลด์ที่สะอาด
บิลด์ที่ไม่ได้ใช้ผลลัพธ์ของบิลด์ก่อนหน้า โดยทั่วไปแล้ววิธีนี้จะช้ากว่าบิลด์แบบเพิ่ม แต่มักถือว่าถูกต้องกว่า Bazel รับประกันว่าทั้งบิลด์ที่สะอาดและบิลด์แบบเพิ่มจะถูกต้องเสมอ
รูปแบบไคลเอ็นต์-เซิร์ฟเวอร์
ไคลเอ็นต์บรรทัดคำสั่ง bazel
จะเริ่มต้นเซิร์ฟเวอร์เบื้องหลังบนเครื่องโดยอัตโนมัติเพื่อเรียกใช้คําสั่ง Bazel เซิร์ฟเวอร์จะยังคงทำงานอยู่สำหรับคำสั่งต่างๆ แต่จะหยุดโดยอัตโนมัติหลังจากไม่มีการใช้งานเป็นระยะเวลาหนึ่ง (หรือผ่านคำสั่ง "bazel shutdown" อย่างชัดแจ้ง) การแยก Bazel เป็นเซิร์ฟเวอร์และไคลเอ็นต์จะช่วยกระจายเวลาเริ่มต้นของ JVM และรองรับการสร้างแบบเพิ่มได้เร็วขึ้นเนื่องจากกราฟการดำเนินการจะยังคงอยู่ในหน่วยความจำสำหรับคำสั่งต่างๆ
คำสั่ง
ใช้ในบรรทัดคำสั่งเพื่อเรียกใช้ฟังก์ชัน Bazel ต่างๆ เช่น bazel
build
, bazel test
, bazel run
และ bazel query
Flag คำสั่ง
ชุด Flag สำหรับคําสั่งหนึ่งๆ โดยเฉพาะ ระบุ Flag ของคําสั่งหลังคําสั่ง (bazel build <command flags>
) โดย Flag จะใช้กับคําสั่งได้อย่างน้อย 1 รายการ เช่น --configure
เป็น Flag สําหรับคําสั่ง bazel sync
โดยเฉพาะ แต่ --keep_going
ใช้กับ sync
, build
, test
และอื่นๆ ได้ โดยปกติแล้วระบบจะใช้ Flag เพื่อการกำหนดค่า ดังนั้นการเปลี่ยนแปลงค่า Flag อาจทําให้ Bazel ลบล้างกราฟในหน่วยความจําและเริ่มระยะการวิเคราะห์อีกครั้ง
การกำหนดค่า
ข้อมูลนอกคําจํากัดความของกฎที่ส่งผลต่อวิธีสร้างการดําเนินการของกฎ บิลด์ทุกรายการมีการกําหนดค่าอย่างน้อย 1 รายการที่ระบุแพลตฟอร์มเป้าหมาย ตัวแปรสภาพแวดล้อมการดำเนินการ และFlag การสร้างบรรทัดคำสั่ง การเปลี่ยนอาจสร้างการกำหนดค่าเพิ่มเติม เช่น สําหรับเครื่องมือโฮสต์หรือการคอมไพล์ข้าม
ดูข้อมูลเพิ่มเติมได้ที่ การกําหนดค่า
การตัดการกำหนดค่า
กระบวนการรวมเฉพาะการกําหนดค่าที่เป้าหมายจําเป็นต้องใช้เท่านั้น เช่น หากคุณสร้างไบนารี Java //:j
ที่มี C++ Dependency //:c
จะเป็นการสิ้นเปลืองหากรวมค่าของ --javacopt
ไว้ในการกำหนดค่าของ //:c
เนื่องจากการเปลี่ยนแปลง --javacopt
จะทําให้ C++ ไม่สามารถแคชการสร้างได้โดยไม่จําเป็น
คําค้นหาที่กําหนดค่า (cquery)
เครื่องมือการค้นหาที่ค้นหาเป้าหมายที่กําหนดค่าไว้ (หลังจากระยะการวิเคราะห์เสร็จสมบูรณ์) ซึ่งหมายความว่า select()
และFlag การสร้าง (เช่น
--platforms
) จะแสดงในผลการค้นหาอย่างถูกต้อง
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบ cquery
เป้าหมายที่กําหนดค่า
ผลลัพธ์ของการประเมินเป้าหมายด้วยการกําหนดค่า ระยะการวิเคราะห์จะสร้างข้อมูลนี้โดยการรวมตัวเลือกของบิลด์เข้ากับเป้าหมายที่ต้องสร้าง
เช่น หาก //:foo
บิลด์สำหรับสถาปัตยกรรมที่แตกต่างกัน 2 แบบในบิลด์เดียวกัน ก็จะมีการกำหนดค่าเป้าหมาย 2 รายการ ได้แก่ <//:foo, x86>
และ <//:foo, arm>
ความถูกต้อง
บิลด์จะถูกต้องเมื่อเอาต์พุตแสดงสถานะของอินพุตแบบทรานซิทีฟอย่างถูกต้อง Bazel มุ่งมั่นที่จะเป็นระบบปิด สามารถทำซ้ำได้ และทำให้การวิเคราะห์การสร้างและการดำเนินการมีการกำหนดไว้ล่วงหน้า เพื่อให้ได้บิลด์ที่ถูกต้อง
การขึ้นต่อกัน
ขอบที่กําหนดทิศทางระหว่างเป้าหมาย 2 รายการ เป้าหมาย //:foo
มีความขึ้นกับเป้าหมาย //:bar
หากค่าแอตทริบิวต์ของ //:foo
มีการอ้างอิงถึง //:bar
//:foo
มีการพึ่งพาการดำเนินการใน //:bar
หากการดำเนินการใน //:foo
ขึ้นอยู่กับอาร์ติแฟกต์อินพุตที่สร้างขึ้นโดยการดำเนินการใน //:bar
ในบางบริบท คำว่า "โมดูล" อาจหมายถึงทรัพยากรภายนอกด้วย ดูหัวข้อโมดูล
Depset
โครงสร้างข้อมูลสําหรับรวบรวมข้อมูลเกี่ยวกับข้อกําหนดเบื้องต้นแบบเปลี่ยนผ่าน เพิ่มประสิทธิภาพเพื่อให้การผสาน Depset ประหยัดเวลาและพื้นที่เก็บข้อมูล เนื่องจากเป็นเรื่องปกติที่จะมี Depset ขนาดใหญ่มาก (ไฟล์หลายแสนไฟล์) ติดตั้งใช้งานเพื่ออ้างอิงชุดข้อมูลอื่นๆ แบบซ้ำซ้อนเพื่อเหตุผลด้านประสิทธิภาพพื้นที่เก็บข้อมูล การติดตั้งใช้งานกฎไม่ควร "ยุบ" ชุดข้อมูลโดยแปลงเป็นลิสต์ เว้นแต่ว่ากฎจะอยู่ในระดับบนสุดของกราฟการสร้าง การผสานชุดข้อมูลขนาดใหญ่จะทำให้เกิดการใช้หน่วยความจําอย่างมาก หรือที่เรียกว่าชุดที่ฝังอยู่ในการใช้งานภายในของ Bazel
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับชุดข้อมูล
แคชของดิสก์
พื้นที่เก็บข้อมูล Blob ในดิสก์ภายในสำหรับฟีเจอร์การแคชจากระยะไกล ใช้ร่วมกับที่เก็บข้อมูล Blob ระยะไกลจริงได้
Distdir
ไดเรกทอรีแบบอ่านอย่างเดียวที่มีไฟล์ที่ Bazel จะดึงมาจากอินเทอร์เน็ตโดยใช้กฎของที่เก็บ เปิดใช้บิลด์ให้ทำงานแบบออฟไลน์ได้อย่างเต็มที่
การดำเนินการแบบไดนามิก
กลยุทธ์การดําเนินการที่เลือกระหว่างการดําเนินการแบบภายในและแบบระยะไกลตาม heuristics ต่างๆ และใช้ผลลัพธ์การดําเนินการของวิธีการที่ประสบความสําเร็จเร็วกว่า การดำเนินการบางอย่างจะดำเนินการได้เร็วขึ้นเมื่อทำในเครื่อง (เช่น การลิงก์) และการดำเนินการอื่นๆ จะดำเนินการได้เร็วขึ้นเมื่อทำจากระยะไกล (เช่น การคอมไพล์แบบขนานได้สูง) กลยุทธ์การเรียกใช้แบบไดนามิกจะให้เวลาสร้างที่เพิ่มขึ้นและสะอาดที่สุด
ระยะการดําเนินการ
ระยะที่ 3 ของการสร้าง เรียกใช้การดำเนินการในกราฟการดำเนินการที่สร้างขึ้นในระยะการวิเคราะห์ การดำเนินการเหล่านี้จะเรียกใช้ไฟล์ปฏิบัติการ (คอมไพเลอร์ สคริปต์) เพื่ออ่านและเขียนอาร์ติแฟกต์ กลยุทธ์การสร้างจะควบคุมวิธีดำเนินการเหล่านี้ เช่น การดำเนินการในเครื่อง ระยะไกล ไดนามิก แซนด์บ็อกซ์ ด็อกเกอร์ และอื่นๆ
รูทการดำเนินการ
ไดเรกทอรีในฐานเอาต์พุตของเวิร์กスペース ซึ่งจะเรียกใช้การดำเนินการในเครื่องในบิลด์ที่ไม่ใช่แซนด์บ็อกซ์ เนื้อหาของไดเรกทอรีส่วนใหญ่เป็นลิงก์สัญลักษณ์ของอาร์ติแฟกต์อินพุตจากเวิร์กスペース นอกจากนี้รูทการดําเนินการยังมีลิงก์สัญลักษณ์ไปยังที่เก็บข้อมูลภายนอกเป็นอินพุตอื่นๆ และไดเรกทอรี bazel-out
เพื่อจัดเก็บเอาต์พุต เตรียมไว้ในช่วงระยะการโหลดโดยการสร้างป่าลิงก์สัญลักษณ์ของไดเรกทอรีที่แสดงถึงการนำส่งแบบสื่อกลางของแพ็กเกจที่บิลด์นั้นใช้ เข้าถึงได้โดยใช้ bazel info
execution_root
ในบรรทัดคำสั่ง
ไฟล์
Hermeticity
บิวด์จะปิดสนิทหากไม่มีปัจจัยภายนอกที่ส่งผลต่อการดำเนินการบิวด์และทดสอบ ซึ่งช่วยให้มั่นใจได้ว่าผลลัพธ์จะแน่นอนและถูกต้อง ตัวอย่างเช่น โดยทั่วไปแล้วบิลด์แบบปิดผนึกจะไม่อนุญาตให้เครือข่ายเข้าถึงการดำเนินการ จำกัดการเข้าถึงอินพุตที่ประกาศ ใช้การประทับเวลาและเขตเวลาแบบคงที่ จำกัดการเข้าถึงตัวแปรสภาพแวดล้อม และใช้เมล็ดพันธุ์แบบคงที่สำหรับเครื่องมือสร้างตัวเลขสุ่ม
บิลด์ที่เพิ่มขึ้น
บิลด์แบบเพิ่มจะนําผลลัพธ์ของบิลด์ก่อนหน้ามาใช้ซ้ำเพื่อลดเวลาในการสร้างและการใช้ทรัพยากร การตรวจสอบและแคชทรัพยากร Dependency มีจุดประสงค์เพื่อให้ได้ผลลัพธ์ที่ถูกต้องสำหรับบิลด์ประเภทนี้ การสร้างแบบเพิ่มเป็นกระบวนการที่ตรงข้ามกับการสร้างแบบล้าง
ป้ายกำกับ
ตัวระบุเป้าหมาย โดยทั่วไปมีรูปแบบเป็น @repo//path/to/package:target
โดยที่ repo
คือชื่อ (ที่ปรากฏ) ของที่เก็บที่มีเป้าหมาย path/to/package
คือเส้นทางไปยังไดเรกทอรีที่มีไฟล์ BUILD
ที่ประกาศเป้าหมาย (ไดเรกทอรีนี้เรียกอีกอย่างว่าแพ็กเกจ) และ target
คือชื่อของเป้าหมาย คุณอาจละเว้นบางส่วนของไวยากรณ์นี้ ทั้งนี้ขึ้นอยู่กับสถานการณ์
ดูเพิ่มเติม: ป้ายกำกับ
ระยะการโหลด
ระยะแรกของการสร้างที่ Bazel เรียกใช้ไฟล์ BUILD
เพื่อสร้างแพ็กเกจ ระบบจะประเมินมาโครและฟังก์ชันบางอย่าง เช่น glob()
ในขั้นตอนนี้ แทรกอยู่ในระยะที่ 2 ของการสร้าง ซึ่งเป็นระยะการวิเคราะห์เพื่อสร้างกราฟเป้าหมาย
มาโคร
กลไกในการเขียนประกาศเป้าหมายกฎหลายรายการเข้าด้วยกันภายใต้ฟังก์ชัน Starlark เดียว เปิดใช้การนํารูปแบบประกาศกฎทั่วไปไปใช้ซ้ำในไฟล์ BUILD
ขยายไปยังเป้าหมายกฎพื้นฐานที่มีการประกาศในช่วงระยะการโหลด
ดูเพิ่มเติม: เอกสารประกอบเกี่ยวกับมาโคร
Mnemonic
สตริงสั้นๆ ที่มนุษย์อ่านได้ซึ่งผู้เขียนกฎเลือกไว้เพื่อให้เข้าใจการดำเนินการในกฎได้อย่างรวดเร็ว คุณสามารถใช้เป็นตัวระบุสำหรับการเลือกกลยุทธ์การสร้าง ตัวอย่างคําช่วยจําสําหรับการดําเนินการ ได้แก่ Javac
จากกฎ Java, CppCompile
จากกฎ C++ และ AndroidManifestMerger
จากกฎ Android
โมดูล
โปรเจ็กต์ Bazel ที่มีได้หลายเวอร์ชัน โดยแต่ละเวอร์ชันอาจมีการพึ่งพาโมดูลอื่นๆ ซึ่งคล้ายกับแนวคิดที่คุ้นเคยในระบบการจัดการทรัพยากรอื่นๆ เช่น อาร์ติแฟกต์ Maven, แพ็กเกจ npm, โมดูล Go หรือ Crate ของ Cargo โมดูลเป็นโครงสร้างพื้นฐานของระบบการจัดการทรัพยากรภายนอกของ Bazel
แต่ละโมดูลได้รับการสนับสนุนจาก repo ที่มีไฟล์ MODULE.bazel
ที่รูท ไฟล์นี้มีข้อมูลเมตาเกี่ยวกับโมดูลเอง (เช่น ชื่อและเวอร์ชัน) โมดูลที่ขึ้นต่อกันโดยตรง และข้อมูลอื่นๆ อีกมากมาย รวมถึงการลงทะเบียนเครื่องมือและอินพุตส่วนขยายโมดูล
ข้อมูลเมตาของโมดูลจะโฮสต์ในรีจิสทรี Bazel
ดูข้อมูลเพิ่มเติมได้ที่ โมดูล Bazel
ส่วนขยายโมดูล
ตรรกะที่สามารถเรียกใช้เพื่อสร้าง repos โดยการอ่านอินพุตจากกราฟทรัพยากร Dependency ของ module และเรียกใช้repo rules ส่วนขยายโมดูลมีความสามารถคล้ายกับกฎของ repo ซึ่งช่วยให้เข้าถึงอินเทอร์เน็ต ดำเนินการ I/O ของไฟล์ และอื่นๆ ได้
ดูข้อมูลเพิ่มเติมได้ที่ ส่วนขยายโมดูล
กฎของเนทีฟ
กฎที่สร้างไว้ใน Bazel และใช้งานใน Java กฎดังกล่าวจะปรากฏในไฟล์ .bzl
เป็นฟังก์ชันในโมดูลเนทีฟ (เช่น native.cc_library
หรือ native.java_library
) ระบบจะสร้างกฎที่ผู้ใช้กำหนด (ไม่ใช่เนทีฟ) โดยใช้ Starlark
ฐานเอาต์พุต
ไดเรกทอรีเฉพาะพื้นที่ทํางานสําหรับจัดเก็บไฟล์เอาต์พุตของ Bazel ใช้เพื่อแยกเอาต์พุตออกจากสคีมาซอร์สโค้ดของพื้นที่ทํางาน (รีพอสิทหลัก) อยู่ในรูทผู้ใช้เอาต์พุต
กลุ่มเอาต์พุต
กลุ่มไฟล์ที่คาดว่าจะสร้างขึ้นเมื่อ Bazel บิลด์เป้าหมายเสร็จแล้ว กฎจะใส่เอาต์พุตปกติไว้ใน "กลุ่มเอาต์พุตเริ่มต้น" (เช่น ไฟล์ .jar
ของ java_library
, .a
และ .so
สำหรับเป้าหมาย cc_library
) กลุ่มเอาต์พุตเริ่มต้นคือกลุ่มเอาต์พุตที่มีการสร้างอาร์ติแฟกต์เมื่อมีการขอเป้าหมายในบรรทัดคำสั่ง
กฎสามารถกําหนดกลุ่มเอาต์พุตที่มีชื่อเพิ่มเติมซึ่งระบุได้อย่างชัดเจนในไฟล์ BUILD
(กฎ filegroup
) หรือบรรทัดคําสั่ง (แฟล็ก --output_groups
)
เอาต์พุตรูทผู้ใช้
ไดเรกทอรีเฉพาะผู้ใช้สำหรับจัดเก็บเอาต์พุตของ Bazel ชื่อไดเรกทอรีจะมาจากชื่อผู้ใช้ของระบบ ป้องกันไม่ให้ไฟล์เอาต์พุตทับซ้อนกันหากผู้ใช้หลายคนสร้างโปรเจ็กต์เดียวกันในระบบในเวลาเดียวกัน มีไดเรกทอรีย่อยที่สอดคล้องกับเอาต์พุตการสร้างของพื้นที่ทำงานแต่ละแห่ง หรือที่เรียกว่าฐานเอาต์พุต
แพ็กเกจ
ชุดเป้าหมายที่กําหนดโดยไฟล์ BUILD
ชื่อแพ็กเกจคือเส้นทางของไฟล์ BUILD
สัมพัทธ์กับรูท repo แพ็กเกจอาจมีแพ็กเกจย่อยหรือไดเรกทอรีย่อยที่มีBUILD
ไฟล์ ซึ่งจะทำให้เกิดลําดับชั้นของแพ็กเกจ
กลุ่มแพ็กเกจ
เป้าหมายที่แสดงชุดแพ็กเกจ มักใช้ในค่าแอตทริบิวต์ visibility
แพลตฟอร์ม
"ประเภทเครื่อง" ที่เกี่ยวข้องกับบิลด์ ซึ่งรวมถึงเครื่องที่ Bazel ทำงานอยู่ (แพลตฟอร์ม "โฮสต์") เครื่องมือสร้างบนเครื่องที่ทำงานอยู่ ("แพลตฟอร์ม "exec") และเครื่องเป้าหมายที่สร้างขึ้นมาเพื่อใช้ ("แพลตฟอร์มเป้าหมาย")
ผู้ให้บริการ
สคีมาอธิบายหน่วยข้อมูลที่จะส่งระหว่างเป้าหมายกฎตามความสัมพันธ์แบบมีลําดับชั้น โดยปกติแล้วไฟล์นี้จะมีข้อมูล เช่น ตัวเลือกคอมไพเลอร์ ไฟล์ต้นทางหรือไฟล์เอาต์พุตแบบทรานซิทีฟ และข้อมูลเมตาของบิลด์ ใช้ร่วมกับ depsets บ่อยครั้งเพื่อจัดเก็บข้อมูลที่ส่งผ่านซึ่งสะสมไว้อย่างมีประสิทธิภาพ ตัวอย่างผู้ให้บริการในตัวคือ DefaultInfo
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบของผู้ให้บริการ
คําค้นหา (แนวคิด)
กระบวนการวิเคราะห์กราฟการสร้างเพื่อทำความเข้าใจพร็อพเพอร์ตี้เป้าหมายและโครงสร้างการพึ่งพา Bazel รองรับรูปแบบการค้นหา 3 รูปแบบ ได้แก่ query, cquery และ aquery
query (คําสั่ง)
เครื่องมือการค้นหาที่ทำงานกับกราฟเป้าหมายหลังระยะการโหลดของบิลด์ ซึ่งจะดำเนินการได้ค่อนข้างเร็ว แต่ไม่สามารถวิเคราะห์ผลของ select()
, build flag, artifact หรือ build action
ดูข้อมูลเพิ่มเติมได้ที่ วิธีใช้การค้นหา ข้อมูลอ้างอิงการค้นหา
ที่เก็บ
ต้นไม้ไดเรกทอรีที่มีไฟล์เครื่องหมายขอบเขตที่รูท ซึ่งมีไฟล์ต้นฉบับที่ใช้ได้ในบิลด์ Bazel มักย่อเป็น repo
ไฟล์เครื่องหมายขอบเขตของ repo อาจเป็น MODULE.bazel
(บ่งบอกว่า repo นี้แสดงโมดูล Bazel), REPO.bazel
หรือในบริบทเดิม WORKSPACE
หรือ WORKSPACE.bazel
ไฟล์เครื่องหมายขอบเขตของรีโปจะระบุขอบเขตของรีโป โดยไฟล์ดังกล่าวจะอยู่ในไดเรกทอรีได้หลายไฟล์
repo หลักคือ repo ที่เรียกใช้คำสั่ง Bazel ในปัจจุบัน
ที่เก็บข้อมูลภายนอกจะกำหนดโดยการระบุโมดูลในMODULE.bazel
ไฟล์ หรือเรียกใช้กฎของที่เก็บข้อมูลในส่วนขยายของโมดูล โดยสามารถดึงข้อมูลได้ตามคําขอไปยังตําแหน่ง "วิเศษ" บนดิสก์ที่กำหนดไว้ล่วงหน้า
แต่ละที่เก็บจะมีชื่อ Canonical ที่ไม่ซ้ำกันแบบคงที่ และอาจมีชื่อที่ปรากฏแตกต่างกันเมื่อดูจากที่เก็บอื่นๆ
ดูข้อมูลเพิ่มเติมได้ที่ภาพรวมการอ้างอิงภายนอก
แคชที่เก็บ
แคชที่ระบุเนื้อหาซึ่งแชร์สำหรับไฟล์ที่ Bazel ดาวน์โหลดสำหรับบิลด์ ซึ่งแชร์ได้ทั่วทั้งเวิร์กスペース เปิดใช้บิลด์แบบออฟไลน์หลังจากการดาวน์โหลดครั้งแรก มักใช้เพื่อแคชไฟล์ที่ดาวน์โหลดผ่านกฎของที่เก็บ เช่น http_archive
และ API กฎของที่เก็บ เช่น repository_ctx.download
ระบบจะแคชไฟล์ก็ต่อเมื่อมีระบุการตรวจสอบ SHA-256 ไว้สำหรับการดาวน์โหลด
กฎที่เก็บ
สคีมาสำหรับคําจํากัดความของที่เก็บข้อมูลที่บอก Bazel ว่าจะแสดง (หรือ "ดึงข้อมูล") ที่เก็บข้อมูลอย่างไร มักเรียกสั้นๆ ว่ากฎของ repo
Bazel จะเรียกใช้กฎของรีโปภายในเพื่อกำหนดรีโปที่รองรับโดยโมดูล หรือส่วนขยายโมดูลจะเรียกใช้กฎได้
กฎของรีโปสามารถเข้าถึงอินเทอร์เน็ตหรือดำเนินการ I/O ของไฟล์ได้ กฎของรีโปที่ใช้กันมากที่สุดคือ http_archive
เพื่อดาวน์โหลดไฟล์เก็บถาวรที่มีไฟล์ต้นฉบับจากอินเทอร์เน็ต
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับกฎของรีโป
ความสามารถในการทำซ้ำ
พร็อพเพอร์ตี้ของบิลด์หรือการทดสอบที่ชุดอินพุตของบิลด์หรือการทดสอบจะสร้างชุดเอาต์พุตเดียวกันทุกครั้ง ไม่ว่าเวลา วิธีการ หรือสภาพแวดล้อมจะเป็นอย่างไร โปรดทราบว่าข้อมูลนี้ไม่ได้หมายความว่าเอาต์พุตถูกต้องหรือเป็นเอาต์พุตที่ต้องการ
กฎ
สคีมาสำหรับการกำหนดเป้าหมายของกฎในไฟล์ BUILD
เช่น cc_library
จากมุมมองของผู้เขียนไฟล์ BUILD
กฎประกอบด้วยชุดแอตทริบิวต์และตรรกะกล่องดำ ตรรกะจะบอกเป้าหมายกฎเกี่ยวกับวิธีสร้างอาร์ติแฟกต์เอาต์พุตและส่งข้อมูลไปยังเป้าหมายกฎอื่นๆ จากมุมมองของผู้เขียน .bzl
กฎเป็นวิธีหลักในการขยาย Bazel ให้รองรับภาษาโปรแกรมและสภาพแวดล้อมใหม่ๆ
ระบบจะสร้างอินสแตนซ์ของกฎเพื่อสร้างเป้าหมายกฎในระยะการโหลด ในระยะการวิเคราะห์ เป้าหมายของกฎจะสื่อสารข้อมูลไปยังทรัพยากร Dependency ดาวน์สตรีมในรูปแบบผู้ให้บริการ และลงทะเบียนการดำเนินการที่อธิบายวิธีสร้างอาร์ติแฟกต์เอาต์พุต ระบบจะเรียกใช้การดำเนินการเหล่านี้ในระยะการดําเนินการ
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับกฎ
เป้าหมายของกฎ
เป้าหมายที่เป็นอินสแตนซ์ของกฎ ตรงข้ามกับเป้าหมายไฟล์และกลุ่มแพ็กเกจ โปรดอย่าสับสนกับกฎ
ไฟล์รันไทม์
Dependency รันไทม์ของเป้าหมายที่เรียกใช้งานได้ โดยทั่วไปแล้ว ไฟล์ปฏิบัติการคือเอาต์พุตที่เรียกใช้งานได้ของกฎทดสอบ และไฟล์รันไทม์คือข้อมูลที่ต้องอาศัยรันไทม์ของการทดสอบ ก่อนเรียกใช้ไฟล์ปฏิบัติการ (ระหว่างการทดสอบ Bazel) Bazel จะเตรียมโครงสร้างของไฟล์รันไทม์ควบคู่ไปกับไฟล์ปฏิบัติการทดสอบตามโครงสร้างไดเรกทอรีต้นทาง
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับ Runfiles
การทำแซนด์บ็อกซ์
เทคนิคในการแยกการดำเนินการที่ทำงานอยู่ภายในรูทการเรียกใช้ที่ถูกจํากัดและชั่วคราว ซึ่งช่วยให้มั่นใจว่าการดำเนินการดังกล่าวจะไม่อ่านอินพุตที่ไม่ได้ประกาศหรือเขียนเอาต์พุตที่ไม่ได้ประกาศ การใช้แซนด์บ็อกซ์ช่วยเพิ่มการปิดผนึกได้อย่างมาก แต่มักจะมีต้นทุนด้านประสิทธิภาพและต้องใช้การรองรับจากระบบปฏิบัติการ ค่าใช้จ่ายด้านประสิทธิภาพจะขึ้นอยู่กับแพลตฟอร์ม ใน Linux จะไม่ส่งผลมากนัก แต่อาจทำให้ใช้แซนด์บ็อกซ์ไม่ได้ใน macOS
Skyframe
Skyframe เป็นเฟรมเวิร์กหลักสำหรับการประเมินแบบขนาน ฟังก์ชันการทำงาน และแบบเพิ่มของ Bazel
การปั๊มวัสดุ
ฟีเจอร์สําหรับฝังข้อมูลเพิ่มเติมลงในอาร์ติแฟกต์ที่ Bazel สร้างขึ้น เช่น สามารถใช้สำหรับการควบคุมแหล่งที่มา เวลาสร้าง และข้อมูลอื่นๆ เกี่ยวกับเวิร์กスペースหรือสภาพแวดล้อมสำหรับบิลด์รุ่น
เปิดใช้ผ่าน--workspace_status_command
Flag และกฎที่รองรับแอตทริบิวต์การประทับ
Starlark
ภาษาส่วนขยายสําหรับเขียนกฎและมาโคร ชุดย่อยของ Python ที่จำกัด (ทางไวยากรณ์และไวยากรณ์) ซึ่งมีไว้เพื่อวัตถุประสงค์ในการกําหนดค่าและเพื่อประสิทธิภาพที่ดียิ่งขึ้น ใช้นามสกุล .bzl
file ไฟล์ BUILD
ใช้ Starlark เวอร์ชันที่จำกัดมากขึ้น (เช่น ไม่มีคําจํากัดความของฟังก์ชัน def
) ซึ่งก่อนหน้านี้เรียกว่า Skylark
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับภาษา Starlark
แฟล็กการเริ่มต้น
ชุด Flag ที่ระบุระหว่าง bazel
กับคำสั่ง เช่น bazel --host_jvm_debug
build Flag เหล่านี้จะแก้ไขการกําหนดค่าของเซิร์ฟเวอร์ Bazel ดังนั้นการแก้ไข Flag การเริ่มต้นระบบจะทําให้เซิร์ฟเวอร์รีสตาร์ท แฟล็กการเริ่มต้นไม่เจาะจงสำหรับคำสั่งใดคำสั่งหนึ่ง
เป้าหมาย
ออบเจ็กต์ที่กําหนดไว้ในไฟล์ BUILD
และระบุด้วยป้ายกํากับ เป้าหมายแสดงถึงหน่วยที่สามารถสร้างได้ของพื้นที่ทํางานจากมุมมองของผู้ใช้ปลายทาง
เป้าหมายที่ประกาศโดยการสร้างอินสแตนซ์กฎเรียกว่าเป้าหมายของกฎ เป้าหมายเหล่านี้อาจเรียกใช้ได้ (เช่น cc_binary
) หรือทดสอบได้ (เช่น cc_test
) ทั้งนี้ขึ้นอยู่กับกฎ โดยปกติแล้วเป้าหมายของกฎจะขึ้นอยู่กับเป้าหมายอื่นๆ ผ่านแอตทริบิวต์ (เช่น deps
) ความสัมพันธ์เหล่านี้เป็นพื้นฐานของกราฟเป้าหมาย
นอกจากเป้าหมายของกฎแล้ว ยังมีเป้าหมายไฟล์และเป้าหมายกลุ่มแพ็กเกจด้วย เป้าหมายไฟล์จะสอดคล้องกับอาร์ติแฟกต์ที่อ้างอิงภายในไฟล์ BUILD
ในกรณีพิเศษ ระบบจะถือว่าไฟล์ BUILD
ของแพ็กเกจใดก็ตามเป็นเป้าหมายไฟล์ต้นฉบับในแพ็กเกจนั้นเสมอ
ระบบจะค้นพบเป้าหมายในช่วงระยะการโหลด ในระหว่างระยะการวิเคราะห์ ระบบจะเชื่อมโยงเป้าหมายกับการกำหนดค่าการสร้างเพื่อสร้างเป้าหมายที่กำหนดค่าไว้
กราฟเป้าหมาย
กราฟในหน่วยความจำของเป้าหมายและรายการที่เกี่ยวข้อง สร้างขึ้นในระหว่างระยะการโหลดและใช้เป็นแหล่งข้อมูลในระยะการวิเคราะห์
รูปแบบเป้าหมาย
วิธีระบุกลุ่มเป้าหมายในบรรทัดคำสั่ง รูปแบบที่ใช้กันโดยทั่วไป ได้แก่ :all
(เป้าหมายกฎทั้งหมด), :*
(เป้าหมายกฎ + ไฟล์ทั้งหมด), ...
(แพ็กเกจปัจจุบันและแพ็กเกจย่อยทั้งหมดแบบซ้ำซ้อน) ใช้ร่วมกันได้ เช่น //...:*
หมายถึงเป้าหมายกฎและไฟล์ทั้งหมดในแพ็กเกจทั้งหมดแบบย้อนกลับจากรูทของ workspace
การทดสอบ
กฎเป้าหมายที่สร้างอินสแตนซ์จากกฎทดสอบ จึงมีไฟล์ปฏิบัติการทดสอบ รหัสผลลัพธ์เป็น 0 จากการทำงานเสร็จสมบูรณ์ของไฟล์ปฏิบัติการบ่งชี้ว่าการทดสอบสำเร็จ สัญญาที่แน่นอนระหว่าง Bazel กับการทดสอบ (เช่น ตัวแปรสภาพแวดล้อมการทดสอบ วิธีการรวบรวมผลลัพธ์การทดสอบ) จะระบุไว้ในสารานุกรมการทดสอบ
เครื่องมือ
ชุดเครื่องมือในการสร้างเอาต์พุตสำหรับภาษาหนึ่งๆ โดยปกติแล้ว เครื่องมือนี้จะประกอบด้วยคอมไพเลอร์ ลิงเกอร์ อินเทอร์พรีเตอร์ หรือ/และโปรแกรมตรวจไวยากรณ์ เครื่องมือชุดค่าผสมยังอาจแตกต่างกันไปตามแพลตฟอร์มด้วย กล่าวคือ คอมโพเนนต์ของเครื่องมือชุดค่าผสมคอมไพเลอร์ Unix อาจแตกต่างจากคอมโพเนนต์ของตัวแปร Windows แม้ว่าเครื่องมือชุดค่าผสมจะใช้กับภาษาเดียวกันก็ตาม การเลือกเครื่องมือทางเทคนิคที่เหมาะสมสําหรับแพลตฟอร์มเรียกว่า "การแก้ปัญหาเกี่ยวกับเครื่องมือทางเทคนิค"
เป้าหมายระดับบนสุด
เป้าหมายการสร้างจะเป็นระดับบนสุดหากมีการขอในบรรทัดคำสั่ง Bazel ตัวอย่างเช่น หาก //:foo
ขึ้นอยู่กับ //:bar
และมีการเรียกใช้ bazel build //:foo
การสร้างครั้งนี้ //:foo
จะเป็นระดับบนสุดและ //:bar
จะไม่ได้เป็นระดับบนสุด แม้ว่าจะต้องสร้างทั้ง 2 เป้าหมายก็ตาม ความแตกต่างที่สําคัญระหว่างเป้าหมายระดับบนสุดกับเป้าหมายที่ไม่ใช่ระดับบนสุดคือแฟล็กคำสั่งที่ตั้งค่าในบรรทัดคำสั่งของ Bazel (หรือผ่าน .bazelrc) จะตั้งค่าการกําหนดค่าสําหรับเป้าหมายระดับบนสุด แต่อาจแก้ไขโดยการเปลี่ยนผ่านสําหรับเป้าหมายที่ไม่ใช่ระดับบนสุด
ทรานซิชัน
การแมปสถานะการกําหนดค่าจากค่าหนึ่งไปยังอีกค่าหนึ่ง ช่วยให้เป้าหมายในกราฟการสร้างมีการกําหนดค่าที่แตกต่างกันได้ แม้ว่าจะสร้างจากกฎเดียวกันก็ตาม การใช้งานทรานซิชันที่พบบ่อยคือการใช้กับทรานซิชันแยก ซึ่งมีการแยกกราฟเป้าหมายออกเป็นหลายส่วนโดยมีการกําหนดค่าที่แตกต่างกันสําหรับแต่ละส่วน เช่น คุณสามารถสร้าง APK ของ Android ที่มีไบนารีแบบเนทีฟที่คอมไพล์สำหรับ ARM และ x86 โดยใช้การเปลี่ยนผ่านแบบแยกในบิลด์เดียว
ดูข้อมูลเพิ่มเติมได้ที่ ทรานซิชันที่กําหนดโดยผู้ใช้
อาร์ติแฟกต์ต้นไม้
อาร์ติแฟกต์ที่แสดงถึงคอลเล็กชันไฟล์ เนื่องจากไฟล์เหล่านี้ไม่ใช่อาร์ติแฟกต์ การดำเนินการที่ทำงานกับไฟล์เหล่านี้จึงต้องลงทะเบียนอาร์ติแฟกต์ต้นไม้เป็นอินพุตหรือเอาต์พุตแทน
ระดับการแชร์
กลไกการป้องกันการพึ่งพาที่ไม่ต้องการในระบบบิลด์มี 2 อย่าง ได้แก่ ระดับการเข้าถึงเป้าหมายสำหรับควบคุมว่าเป้าหมายอื่นๆ จะอ้างอิงเป้าหมายได้หรือไม่ และระดับการโหลดสำหรับควบคุมว่าไฟล์ BUILD
หรือ .bzl
จะโหลดไฟล์ .bzl
หนึ่งๆ ได้หรือไม่ หากไม่มีบริบท "การแสดงผล" มักจะหมายถึงการแสดงผลเป้าหมาย
ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบเกี่ยวกับระดับการเข้าถึง
Workspace
สภาพแวดล้อมที่คำสั่ง Bazel ทั้งหมดใช้ร่วมกันจะทำงานจากที่เก็บข้อมูลหลักเดียวกัน
โปรดทราบว่าที่ผ่านมาแนวคิด "ที่เก็บข้อมูล" และ "เวิร์กスペース" มักสับสนกัน คำว่า "เวิร์กスペース" มักใช้เพื่ออ้างอิงถึงที่เก็บข้อมูลหลัก และบางครั้งยังใช้เป็นคำพ้องความหมายของ "ที่เก็บข้อมูล" ด้วย คุณควรหลีกเลี่ยงการใช้คำดังกล่าวเพื่อความชัดเจน