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