คำสั่งและตัวเลือก

รายงานปัญหา ดูแหล่งที่มา

หน้านี้ครอบคลุมตัวเลือกที่ใช้ได้กับคำสั่งต่างๆ ของ Bazel เช่น bazel build, bazel run และ bazel test หน้านี้ใช้ร่วมกับรายการคำสั่งของ Bazel ในสร้างด้วย Bazel

ไวยากรณ์เป้าหมาย

บางคำสั่ง เช่น build หรือ test จะทำงานในรายการเป้าหมายได้ โดยใช้ไวยากรณ์ที่ยืดหยุ่นกว่าป้ายกำกับ ซึ่งอธิบายไว้ในการระบุเป้าหมายที่จะสร้าง

ตัวเลือก

ส่วนต่อไปนี้จะอธิบายตัวเลือกที่มีระหว่างการสร้าง เมื่อใช้ --long ในคำสั่งช่วยเหลือ ข้อความช่วยเหลือออนไลน์จะมีข้อมูลสรุปเกี่ยวกับความหมาย ประเภท และค่าเริ่มต้นของแต่ละตัวเลือก

ตัวเลือกส่วนใหญ่สามารถระบุได้เพียงครั้งเดียวเท่านั้น เมื่อระบุหลายครั้ง อินสแตนซ์สุดท้ายจะชนะ ระบุตัวเลือกที่สามารถระบุได้หลายครั้งไว้ในความช่วยเหลือออนไลน์ด้วยข้อความ "อาจใช้หลายครั้ง"

ตำแหน่งพัสดุ

--package_path

ตัวเลือกนี้จะระบุชุดไดเรกทอรีที่มีการค้นหาเพื่อค้นหาไฟล์ BUILD สำหรับแพ็กเกจที่ระบุ

บาเซลพบพัสดุด้วยการค้นหาเส้นทางพัสดุ นี่คือรายการไดเรกทอรีที่เรียงลำดับตาม Bazel ที่คั่นด้วยโคลอน แต่ละไดเรกทอรีเป็นรูทของโครงสร้างแหล่งที่มาบางส่วน

หากต้องการระบุเส้นทางแพ็กเกจที่กำหนดเองโดยใช้ตัวเลือก --package_path ให้ทำดังนี้

  % bazel build --package_path %workspace%:/some/other/root

องค์ประกอบเส้นทางแพ็กเกจสามารถระบุได้ 3 รูปแบบ ดังนี้

1. หากอักขระตัวแรกคือ / เส้นทางจะเป็นสัมบูรณ์
2. หากเส้นทางขึ้นต้นด้วย %workspace% ระบบจะนำเส้นทางนั้นไปสัมพันธ์กับไดเรกทอรีที่ล้อมกรอบซึ่งอยู่ใกล้ที่สุด ตัวอย่างเช่น หากไดเรกทอรีที่ใช้งานอยู่คือ /home/bob/clients/bob_client/bazel/foo สตริง %workspace% ในเส้นทางแพ็กเกจจะขยายเป็น /home/bob/clients/bob_client/bazel
3. ส่วนข้อมูลอื่นๆ จะเกี่ยวข้องกับไดเรกทอรีที่ใช้งานอยู่ ซึ่งมักไม่ใช่สิ่งที่คุณตั้งใจจะทำ และอาจทำงานโดยไม่คาดคิดหากคุณใช้ Bazel จากไดเรกทอรีที่อยู่ด้านล่างพื้นที่ทำงานของ Bazel ตัวอย่างเช่น หากคุณใช้องค์ประกอบเส้นทางแพ็กเกจ . และจากนั้นจึงป้อน cd ลงในไดเรกทอรี /home/bob/clients/bob_client/bazel/foo แพ็กเกจก็จะได้รับการแก้ไขจากไดเรกทอรี /home/bob/clients/bob_client/bazel/foo

หากใช้เส้นทางแพ็กเกจที่ไม่ใช่ค่าเริ่มต้น ให้ระบุเส้นทางดังกล่าวในไฟล์การกำหนดค่า Basl เพื่อความสะดวก

Bazel ไม่ได้กำหนดแพ็กเกจใดๆ ให้อยู่ในไดเรกทอรีปัจจุบัน คุณจึงสร้างจากพื้นที่ทำงาน Bazel ที่ว่างเปล่าได้หากพบแพ็กเกจที่จำเป็นทั้งหมดที่อื่นในเส้นทางแพ็กเกจ

ตัวอย่าง: การสร้างจากไคลเอ็นต์ที่ว่างเปล่า

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

ตัวเลือกนี้จะระบุรายการแพ็กเกจที่คั่นด้วยคอมมาซึ่ง Bazel ควรพิจารณาว่าลบออก และไม่พยายามโหลดจากไดเรกทอรีใดๆ บนเส้นทางแพ็กเกจ ซึ่งจะใช้จำลองการลบแพ็กเกจได้โดยไม่ต้องลบแพ็กเกจจริง ตัวเลือกนี้ส่งได้หลายครั้ง ซึ่งในกรณีนี้ รายการแต่ละรายการจะเชื่อมโยงกัน

การตรวจสอบข้อผิดพลาด

ตัวเลือกเหล่านี้จะควบคุมการตรวจสอบข้อผิดพลาดและ/หรือคำเตือนของ Bazel

--[no]check_visibility

หากตั้งค่านโยบายนี้เป็น "เท็จ" ระบบจะลดระดับการตรวจสอบระดับการเข้าถึงเป็นคําเตือน ค่าเริ่มต้นของตัวเลือกนี้คือ true ดังนั้นการตรวจสอบระดับการเข้าถึงจะเป็นไปโดยค่าเริ่มต้น

--output_filter=regex

ตัวเลือก --output_filter จะแสดงเฉพาะคำเตือนการสร้างและการคอมไพล์สำหรับเป้าหมายที่ตรงกับนิพจน์ทั่วไปเท่านั้น หากเป้าหมายไม่ตรงกับนิพจน์ทั่วไปที่กำหนดและการดำเนินการสำเร็จ ระบบจะทิ้งเอาต์พุตมาตรฐานและข้อผิดพลาดมาตรฐานไป

ค่าทั่วไปสำหรับตัวเลือกนี้มีดังนี้

`--output_filter='^//(first/project|second/project):'`	แสดงเอาต์พุตสำหรับแพ็กเกจที่ระบุ
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`	ไม่ต้องแสดงเอาต์พุตสำหรับแพ็กเกจที่ระบุ
`--output_filter=`	แสดงทุกอย่าง
`--output_filter=DONT_MATCH_ANYTHING`	ไม่แสดงอะไรเลย

แฟล็กเครื่องมือ

ตัวเลือกเหล่านี้จะควบคุมตัวเลือกที่ Bazel จะส่งไปยังเครื่องมืออื่นๆ

--copt=cc-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์ อาร์กิวเมนต์จะถูกส่งผ่านไปยังคอมไพเลอร์เมื่อใดก็ตามที่มีการเรียกใช้สำหรับการประมวลผลล่วงหน้า การคอมไพล์ และ/หรือการรวมโค้ด C, C++ หรือแอสเซมเมอร์ และระบบจะไม่ส่งต่อรหัสดังกล่าวเมื่อลิงก์

ตัวเลือกนี้ใช้ได้หลายครั้ง เช่น

  % bazel build --copt="-g0" --copt="-fpic" //foo

จะรวบรวมไลบรารี foo โดยไม่มีตารางการแก้ไขข้อบกพร่อง ซึ่งจะสร้างโค้ดที่ไม่ขึ้นอยู่กับตำแหน่ง

หมายเหตุ: การเปลี่ยนการตั้งค่า --copt จะบังคับให้มีการคอมไพล์ไฟล์ออบเจ็กต์ที่ได้รับผลกระทบทั้งหมดอีกครั้ง นอกจากนี้ โปรดทราบว่าค่า copt ที่ระบุไว้ในกฎการสร้าง cc_library หรือ cc_binary ที่เฉพาะเจาะจงจะอยู่ในบรรทัดคำสั่งของคอมไพเลอร์ หลังตัวเลือกเหล่านี้

คำเตือน: ตัวเลือกเฉพาะ C++ (เช่น -fno-implicit-templates) ควรระบุไว้ใน --cxxopt ไม่ใช่ใน --copt ในทำนองเดียวกัน ตัวเลือกเฉพาะ C (เช่น -Wstrict-prototypes) ควรระบุใน --conlyopt ไม่ใช่ copt ในทำนองเดียวกัน คุณควรระบุตัวเลือกของคอมไพเลอร์ที่เฉพาะเอฟเฟกต์ในเวลาลิงก์ (เช่น -l) ใน --linkopt ไม่ใช่ --copt

--host_copt=cc-option

ตัวเลือกนี้จะใช้อาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับที่คอมไพล์ในการกำหนดค่าผู้บริหาร ตัวเลือกนี้คล้ายกับตัวเลือก --copt แต่จะมีผลกับการกำหนดค่าการดำเนินการเท่านั้น

--host_conlyopt=cc-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับ C ที่คอมไพล์ในการกำหนดค่าผู้บริหาร ซึ่งคล้ายกับตัวเลือก --conlyopt แต่จะมีผลกับการกำหนดค่าการดำเนินการเท่านั้น

--host_cxxopt=cc-option

ตัวเลือกนี้จะใช้อาร์กิวเมนต์ซึ่งจะส่งไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับ C++ ที่คอมไพล์ในการกำหนดค่าการดำเนินการ ตัวเลือกนี้คล้ายกับตัวเลือก --cxxopt แต่จะมีผลกับการกำหนดค่าการดำเนินการเท่านั้น

--host_linkopt=linker-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยัง Linker สำหรับไฟล์ต้นฉบับที่คอมไพล์ในการกำหนดค่าการดำเนินการ ซึ่งคล้ายกับตัวเลือก --linkopt แต่จะมีผลกับการกำหนดค่าการดำเนินการเท่านั้น

--conlyopt=cc-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ซึ่งจะส่งไปยังคอมไพเลอร์เมื่อคอมไพล์ไฟล์ต้นฉบับ C

ซึ่งคล้ายกับ --copt แต่จะมีผลกับการคอมไพล์ C เท่านั้น ไม่ได้ใช้กับการคอมไพล์หรือการลิงก์ C++ เพื่อให้คุณส่งผ่านตัวเลือกเฉพาะ C (เช่น -Wno-pointer-sign) โดยใช้ --conlyopt ได้

หมายเหตุ: พารามิเตอร์ Copt ที่ระบุไว้ในกฎบิลด์ cc_library หรือ cc_binary ที่เฉพาะเจาะจงจะอยู่ในบรรทัดคำสั่งของคอมไพเลอร์หลังตัวเลือกเหล่านี้

--cxxopt=cc-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ซึ่งจะส่งไปยังคอมไพเลอร์เมื่อคอมไพล์ไฟล์ต้นฉบับของ C++

วิธีนี้คล้ายกับ --copt แต่จะมีผลกับการคอมไพล์ C++ เท่านั้น ไม่ใช้กับการคอมไพล์ C หรือการลิงก์ เพื่อให้คุณส่งผ่านตัวเลือกเฉพาะของ C++ (เช่น -fpermissive หรือ -fno-implicit-templates) ได้โดยใช้ --cxxopt

เช่น

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

หมายเหตุ: พารามิเตอร์ Copt ที่แสดงในกฎบิลด์ cc_library หรือ cc_binary บางอย่างจะอยู่ในบรรทัดคำสั่งของคอมไพเลอร์หลังตัวเลือกเหล่านี้

--linkopt=linker-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ซึ่งจะส่งไปยังคอมไพเลอร์เมื่อลิงก์

ซึ่งคล้ายกับ --copt แต่จะมีผลกับการลิงก์เท่านั้น ไม่ใช้กับการคอมไพล์ เพื่อให้คุณส่งผ่านตัวเลือกคอมไพเลอร์ที่เหมาะสมในช่วงเวลาของลิงก์ (เช่น -lssp หรือ -Wl,--wrap,abort) โดยใช้ --linkopt ได้ เช่น

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

นอกจากนี้ กฎในการสร้างยังระบุตัวเลือกลิงก์ในแอตทริบิวต์ได้ด้วย โดยการตั้งค่าของตัวเลือกนี้จะมีความสำคัญเหนือกว่าเสมอ รวมทั้งดู cc_library.linkopts

--strip (always|never|sometimes)

ตัวเลือกนี้จะกำหนดว่า Bazel จะนำข้อมูลการแก้ไขข้อบกพร่องออกจากไบนารีและไลบรารีที่แชร์ทั้งหมดหรือไม่ โดยเรียกใช้ Linker ด้วยตัวเลือก -Wl,--strip-debug --strip=always หมายความว่าจะตัดข้อมูลการแก้ไขข้อบกพร่องออกเสมอ --strip=never หมายความว่าจะไม่มีการนำข้อมูลการแก้ไขข้อบกพร่องออก ค่าเริ่มต้นของ --strip=sometimes หมายถึงตัดหาก --compilation_mode เป็น fastbuild

  % bazel build --strip=always //foo:bar

จะรวบรวมเป้าหมายในขณะที่นำข้อมูลการแก้ไขข้อบกพร่องออกจากไบนารีที่สร้างขึ้นทั้งหมด

หมายเหตุ: หากต้องการข้อมูลการแก้ไขข้อบกพร่อง การปิดใช้การลบวิดีโอเพียงอย่างเดียวนั้นยังไม่เพียงพอ คุณต้องตรวจสอบว่าข้อมูลการแก้ไขข้อบกพร่องสร้างขึ้นโดยคอมไพเลอร์ ซึ่งดำเนินการได้โดยใช้ -c dbg หรือ --copt -g

ตัวเลือก --strip ของ Bazel สอดคล้องกับตัวเลือก --strip-debug ของ ld นั่นคือจะลบเฉพาะข้อมูลการแก้ไขข้อบกพร่องเท่านั้น หากคุณต้องการตัดสัญลักษณ์ทั้งหมดออกด้วยเหตุผลใดก็ตาม ไม่ใช่แค่สัญลักษณ์แก้ไขข้อบกพร่อง คุณจะต้องใช้ตัวเลือก --strip-all ของ ld ที่ทําได้โดยการส่ง --linkopt=-Wl,--strip-all ไปยัง Bazel และโปรดทราบว่าการตั้งค่าแฟล็ก --strip ของ Bazel จะลบล้าง --linkopt=-Wl,--strip-all ดังนั้นคุณควรตั้งค่าอย่างใดอย่างหนึ่งเท่านั้น

หากสร้างไบนารีเดียวและต้องการตัดสัญลักษณ์ทั้งหมดออก คุณจะส่ง --stripopt=--strip-all และสร้างเป้าหมายเวอร์ชัน //foo:bar.stripped อย่างชัดแจ้งได้ด้วย ตามที่อธิบายไว้ในส่วนเกี่ยวกับ --stripopt การดำเนินการนี้จะใช้การตัดข้อความหลังจากลิงก์ไบนารีสุดท้ายแล้ว แทนที่จะรวมการดำเนินการลิงก์ทั้งหมดของบิลด์

--stripopt=strip-option

นี่เป็นตัวเลือกเพิ่มเติมที่ส่งไปยังคำสั่ง strip เมื่อสร้างไบนารี *.stripped โดยมีค่าเริ่มต้นเป็น -S -p ตัวเลือกนี้ใช้ได้หลายครั้ง

หมายเหตุ: --stripopt ไม่มีผลกับการลบไบนารีหลักที่มี [--strip](#flag--strip)=(always|sometimes)

--fdo_instrument=profile-output-dir

ตัวเลือก --fdo_instrument จะเปิดใช้การสร้างเอาต์พุตโปรไฟล์ FDO (การเพิ่มประสิทธิภาพความคิดเห็นโดยตรง) เมื่อดำเนินการไบนารี C/C++ ที่สร้างขึ้น สำหรับ GCC อาร์กิวเมนต์ที่ระบุจะใช้เป็น คำนำหน้าไดเรกทอรีสำหรับโครงสร้างไดเรกทอรีไฟล์ต่อออบเจ็กต์ของไฟล์ .gcda ที่มีข้อมูลโปรไฟล์สำหรับไฟล์ .o แต่ละไฟล์

เมื่อสร้างโครงสร้างข้อมูลโปรไฟล์แล้ว แผนผังโปรไฟล์ควรจะถูกบีบอัดและระบุไปยังตัวเลือก Bazel เพื่อเปิดใช้งานการคอมไพล์ที่เพิ่มประสิทธิภาพ FDO--fdo_optimize=profile-zip

สำหรับคอมไพเลอร์ LLVM อาร์กิวเมนต์ยังเป็นไดเรกทอรีที่ใช้ดัมพ์ไฟล์ข้อมูลโปรไฟล์ LLVM ดิบด้วย ตัวอย่างเช่น --fdo_instrument=/path/to/rawprof/dir/

ใช้ตัวเลือก --fdo_instrument และ --fdo_optimize พร้อมกันไม่ได้

--fdo_optimize=profile-zip

ตัวเลือก --fdo_optimize จะใช้ข้อมูลโปรไฟล์ไฟล์ต่อออบเจ็กต์เพื่อเพิ่มประสิทธิภาพ FDO (การเพิ่มประสิทธิภาพที่มุ่งเน้นความคิดเห็น) เมื่อคอมไพล์ สำหรับ GCC อาร์กิวเมนต์ที่ระบุคือไฟล์ ZIP ที่มีโครงสร้างไฟล์ .gcda ที่สร้างไว้ก่อนหน้านี้ของไฟล์ .gcda ซึ่งมีข้อมูลโปรไฟล์ของไฟล์ .o แต่ละไฟล์

หรืออาร์กิวเมนต์ที่ระบุอาจชี้ไปยังโปรไฟล์อัตโนมัติที่ระบุโดยส่วนขยาย .afdo ก็ได้

หมายเหตุ: ตัวเลือกนี้จะยอมรับป้ายกำกับที่แปลงเป็นไฟล์ต้นฉบับด้วย คุณอาจต้องเพิ่มคำสั่ง exports_files ไปยังแพ็กเกจที่เกี่ยวข้องเพื่อให้ Bazel ดูไฟล์ได้

สำหรับคอมไพเลอร์ LLVM อาร์กิวเมนต์ที่ระบุควรชี้ไปยังไฟล์เอาต์พุตโปรไฟล์ LLVM ที่จัดทำดัชนีซึ่งจัดเตรียมโดยเครื่องมือ llvm-profdata และควรมีส่วนขยาย .profdata

ใช้ตัวเลือก --fdo_instrument และ --fdo_optimize พร้อมกันไม่ได้

--java_language_version=version

ตัวเลือกนี้จะระบุเวอร์ชันของซอร์ส Java เช่น

  % bazel build --java_language_version=8 java/com/example/common/foo:all

และอนุญาตเฉพาะโครงสร้างที่เข้ากันได้กับข้อกำหนดของ Java 8 ค่าเริ่มต้นคือ 11 --> ค่าที่เป็นไปได้คือ 8, 9, 10, 11, 14 และ 15 และอาจขยายได้โดยการลงทะเบียน Toolchain ของ Java ที่กำหนดเองโดยใช้ default_java_toolchain

--tool_java_language_version=version

เวอร์ชันภาษา Java ที่ใช้ในการสร้างเครื่องมือที่ดำเนินการในระหว่างบิลด์ ค่าเริ่มต้นคือ 11

--java_runtime_version=version

ตัวเลือกนี้จะระบุเวอร์ชันของ JVM ที่จะใช้เพื่อเรียกใช้โค้ดและทำการทดสอบ ตัวอย่างเช่น

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

ดาวน์โหลด JDK 11 จากที่เก็บระยะไกลและเรียกใช้แอปพลิเคชัน Java โดยใช้ที่เก็บดังกล่าว

ค่าเริ่มต้นคือ local_jdk ค่าที่เป็นไปได้คือ local_jdk, local_jdk_version, remotejdk_11 และ remotejdk_17 คุณขยายค่าได้โดยการลงทะเบียน JVM ที่กำหนดเองโดยใช้กฎที่เก็บ local_java_repository หรือ remote_java_repository

--tool_java_runtime_version=version

เวอร์ชันของ JVM ที่ใช้เพื่อเรียกใช้เครื่องมือที่จำเป็นระหว่างการสร้าง ค่าเริ่มต้นคือ remotejdk_11

--jvmopt=jvm-option

ตัวเลือกนี้อนุญาตให้ส่งผ่านอาร์กิวเมนต์ตัวเลือกไปยัง Java VM ซึ่งจะใช้กับอาร์กิวเมนต์ขนาดใหญ่ เพียงรายการเดียว หรือหลายๆ ครั้งกับอาร์กิวเมนต์แต่ละรายการก็ได้ เช่น

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

จะใช้ VM ของเซิร์ฟเวอร์เพื่อเปิดไบนารีของ Java ทั้งหมด และตั้งค่าขนาดฮีปเริ่มต้นสำหรับ VM เป็น 256 MB

--javacopt=javac-option

ตัวเลือกนี้อนุญาตให้ส่งผ่านอาร์กิวเมนต์ตัวเลือกไปยัง javac ซึ่งจะใช้กับอาร์กิวเมนต์ขนาดใหญ่ เพียงรายการเดียว หรือหลายๆ ครั้งกับอาร์กิวเมนต์แต่ละรายการก็ได้ เช่น

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

จะสร้าง java_binary ใหม่ด้วยข้อมูลการแก้ไขข้อบกพร่องเริ่มต้นของ javac (แทนค่าเริ่มต้นของ bazel)

ระบบจะส่งตัวเลือกนี้ไปยัง javac หลังตัวเลือกเริ่มต้นในตัวของ Bazel สำหรับ javac และก่อนตัวเลือกตามกฎ ข้อกำหนดสุดท้ายของตัวเลือกใดๆ ที่ต้องการให้ Javac ชนะ ตัวเลือกเริ่มต้นสำหรับ Javac มีดังนี้

  -source 8 -target 8 -encoding UTF-8

หมายเหตุ: การเปลี่ยนการตั้งค่า --javacopt จะบังคับให้มีการคอมไพล์ชั้นเรียนที่ได้รับผลกระทบทั้งหมดอีกครั้ง นอกจากนี้ โปรดทราบว่าพารามิเตอร์ Javacopts ที่ระบุไว้ในกฎบิลด์ java_library หรือ java_binary ที่เฉพาะเจาะจงจะอยู่ในบรรทัดคำสั่ง javac หลังตัวเลือกเหล่านี้

ด้วย

--strict_java_deps (default|strict|off|warn|error)

ตัวเลือกนี้จะควบคุมว่า Javac จะตรวจสอบการขึ้นต่อกันโดยตรงที่ขาดหายไปหรือไม่ เป้าหมาย Java ต้องประกาศเป้าหมายที่ใช้โดยตรงทั้งหมดอย่างชัดแจ้งเป็นทรัพยากร Dependency แฟล็กนี้สั่งให้ Javac ระบุ Jars ที่ใช้จริงสำหรับการตรวจสอบไฟล์ Java แต่ละไฟล์ และแจ้งเตือน/ข้อผิดพลาดหากไม่ใช่เอาต์พุตของทรัพยากร Dependency โดยตรงของเป้าหมายปัจจุบัน

• off หมายถึงปิดใช้การตรวจสอบอยู่
• warn หมายความว่า Javac จะสร้างคำเตือน Java มาตรฐานของประเภท [strict] สำหรับทรัพยากร Dependency โดยตรงแต่ละรายการที่ขาดหายไป
• default, strict และ error ทุก JavaScript จะแสดงข้อผิดพลาดแทนคำเตือน ซึ่งทำให้สร้างเป้าหมายปัจจุบันไม่สำเร็จหากไม่พบทรัพยากร Dependency โดยตรง ซึ่งจะเป็นการทำงานเริ่มต้นเมื่อไม่ได้ระบุการตั้งค่าสถานะด้วย

สร้างอรรถศาสตร์

ตัวเลือกเหล่านี้จะมีผลต่อคำสั่งบิลด์และ/หรือเนื้อหาไฟล์เอาต์พุต

--compilation_mode (fastbuild|opt|dbg) (-ค)

ตัวเลือก --compilation_mode (มักจะย่อลงเป็น -c โดยเฉพาะ -c opt) จะรับอาร์กิวเมนต์ fastbuild, dbg หรือ opt และส่งผลต่อตัวเลือกการสร้างโค้ด C/C++ ต่างๆ เช่น ระดับการเพิ่มประสิทธิภาพและความสมบูรณ์ของตารางแก้ไขข้อบกพร่อง Bazel ใช้ไดเรกทอรีเอาต์พุตที่แตกต่างกันสำหรับโหมดการคอมไพล์แต่ละโหมด คุณจึงสลับไปมาระหว่างโหมดต่างๆ ได้โดยไม่ต้องสร้างใหม่ทุกครั้ง

• fastbuild หมายความว่าสร้างเร็วที่สุดเท่าที่จะเป็นไปได้ คือสร้างข้อมูลการแก้ไขข้อบกพร่องให้น้อยที่สุด (-gmlt -Wl,-S) และไม่ต้องเพิ่มประสิทธิภาพ ตัวเลือกนี้เป็นค่าเริ่มต้น หมายเหตุ: ระบบจะไม่ตั้งค่า -DNDEBUG
• dbg หมายถึงสร้างที่มีการเปิดใช้การแก้ไขข้อบกพร่อง (-g) เพื่อให้คุณใช้ gdb (หรือโปรแกรมแก้ไขข้อบกพร่องอื่น) ได้
• opt หมายถึงมีการเปิดใช้บิลด์ที่เปิดใช้การเพิ่มประสิทธิภาพ และปิดใช้การเรียก assert() (-O2 -DNDEBUG) ระบบจะไม่สร้างข้อมูลการแก้ไขข้อบกพร่องในโหมด opt เว้นแต่คุณจะผ่าน --copt -g ด้วย

--cpu=cpu

ตัวเลือกนี้จะระบุสถาปัตยกรรม CPU เป้าหมายที่จะใช้สำหรับการคอมไพล์ไบนารีระหว่างบิลด์

หมายเหตุ: อนุญาตให้ใช้ชุดค่าผสมข้ามเวอร์ชัน เวอร์ชันของคอมไพเลอร์ และ CPU เป้าหมายได้ก็ต่อเมื่อได้ระบุไว้ในไฟล์ CROSSTOOL ที่ใช้อยู่ในปัจจุบันเท่านั้น

--action_env=VAR=VALUE

ระบุชุดตัวแปรสภาพแวดล้อมที่ใช้ได้ในระหว่างการดำเนินการทั้งหมด คุณระบุตัวแปรได้ด้วยชื่อ ซึ่งในกรณีนี้จะนำค่ามาจากสภาพแวดล้อมการเรียกใช้ หรือโดยคู่ name=value ซึ่งจะตั้งค่าโดยไม่ขึ้นอยู่กับสภาพแวดล้อมการเรียกใช้

ระบุการแจ้งว่าไม่เหมาะสม --action_env นี้ได้หลายครั้ง หากมีการระบุค่าให้กับตัวแปรเดียวกันในแฟล็ก --action_env หลายรายการ การมอบหมายล่าสุดจะชนะ

--experimental_action_listener=label

คำเตือน: เลิกใช้งานการดำเนินการเพิ่มเติมแล้ว โปรดใช้มุมมองแทน

ตัวเลือก experimental_action_listener จะสั่งให้ Bazel ใช้รายละเอียดจากกฎ action_listener ที่ระบุโดย label เพื่อแทรก extra_actions ลงในกราฟบิลด์

--[no]experimental_extra_action_top_level_only

คำเตือน: เลิกใช้งานการดำเนินการเพิ่มเติมแล้ว โปรดใช้ aspects แทน

หากใช้ตัวเลือกนี้เป็น "จริง" ระบบจะกำหนดเวลาการดำเนินการเพิ่มเติมที่ระบุโดยตัวเลือกบรรทัดคำสั่ง --experimental_action_listener สำหรับเป้าหมายระดับบนสุดเท่านั้น

--experimental_extra_action_filter=regex

คำเตือน: เลิกใช้งานการดำเนินการเพิ่มเติมแล้ว โปรดใช้ aspects แทน

ตัวเลือก experimental_extra_action_filter จะสั่งให้ Bazel กรองชุดเป้าหมายเพื่อตั้งเวลาให้ extra_actions

แฟล็กนี้ใช้งานได้ร่วมกับแฟล็ก --experimental_action_listener เท่านั้น

โดยค่าเริ่มต้น extra_actions ทั้งหมดที่ปิดแบบทางอ้อมของเป้าหมายที่จะสร้างที่ขอจะได้รับการกำหนดเวลาสำหรับการดำเนินการ --experimental_extra_action_filter จะจำกัดการตั้งเวลาไว้ที่ extra_actions ที่ป้ายกำกับของเจ้าของตรงกับนิพจน์ทั่วไปที่ระบุ

ตัวอย่างต่อไปนี้จะจำกัดการตั้งเวลา extra_actions ให้มีผลเฉพาะกับการดำเนินการที่ป้ายกำกับของเจ้าของมี "/bar/"

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

ตัวเลือกนี้จะระบุชื่อสถาปัตยกรรม CPU ที่ควรใช้ในการสร้างเครื่องมือโฮสต์

--android_platforms=platform[,platform]*

แพลตฟอร์มสำหรับสร้างกฎ deps แบบทรานซิชันของ android_binary (โดยเฉพาะสำหรับทรัพยากร Dependency แบบเนทีฟ เช่น C++) ตัวอย่างเช่น หาก cc_library ปรากฏใน deps ทรานซิชันของกฎ android_binary ระบบจะสร้างขึ้นครั้งเดียวสำหรับแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms สำหรับกฎ android_binary และรวมไว้ในเอาต์พุตสุดท้าย

ไม่มีค่าเริ่มต้นสำหรับ Flag นี้: ต้องกำหนดและใช้แพลตฟอร์ม Android ที่กำหนดเอง

สร้างไฟล์ .so 1 ไฟล์และรวมแพ็กเกจไว้ใน APK ของแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms ชื่อไฟล์ .so นำหน้าชื่อของกฎ android_binary ด้วย "lib" เช่น หากชื่อของ android_binary คือ "foo" ไฟล์จะเป็น libfoo.so

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

เมื่อปรากฏขึ้น ระบบจะสร้างไฟล์ C++ ที่มีป้ายกำกับหรือเส้นทางการดำเนินการตรงกับนิพจน์ทั่วไปสำหรับรวมรายการใดรายการหนึ่งและไม่ตรงกับนิพจน์การยกเว้นใดๆ ด้วยตัวเลือกที่ระบุ การจับคู่ป้ายกำกับใช้รูปแบบ Canonical ของป้ายกำกับ (เช่น //package:label_name)

เส้นทางการดำเนินการเป็นเส้นทางสัมพัทธ์ไปยังไดเรกทอรีพื้นที่ทำงานของคุณ รวมถึงชื่อฐาน (รวมถึงนามสกุล) ของไฟล์ C++ รวมถึงคำนำหน้าที่ขึ้นอยู่กับแพลตฟอร์มด้วย

หมายเหตุ: ระบบจะเลือกใช้ป้ายกำกับหรือเส้นทางการดำเนินการเพียงรายการเดียวที่ตรงกับตัวเลือก

หากต้องการจับคู่ไฟล์ที่สร้างขึ้น (เช่น เอาต์พุต Genrule) Bazel จะใช้ได้เฉพาะเส้นทางการดำเนินการเท่านั้น ในกรณีนี้ regexp ไม่ควรขึ้นต้นด้วย "//" เนื่องจากไม่ตรงกับเส้นทางการดำเนินการใดๆ ชื่อแพ็กเกจอาจใช้ดังนี้ --per_file_copt=base/.*\.pb\.cc@-g0. การดำเนินการนี้จะจับคู่ทุก .pb.cc ไฟล์ภายใต้ไดเรกทอรีที่ชื่อ base

ตัวเลือกนี้ใช้ได้หลายครั้ง

ระบบจะใช้ตัวเลือกดังกล่าวไม่ว่าจะใช้โหมดการคอมไพล์แบบใดก็ตาม ตัวอย่างเช่น คุณจะคอมไพล์ด้วย --compilation_mode=opt และเลือกคอมไพล์บางไฟล์ที่มีการเปิดใช้การเพิ่มประสิทธิภาพที่รัดกุมยิ่งขึ้นได้ หรืออาจมีการปิดใช้การเพิ่มประสิทธิภาพ

โปรดทราบ: หากไฟล์บางไฟล์ได้รับการคอมไพล์เฉพาะพร้อมกับสัญลักษณ์สำหรับแก้ไขข้อบกพร่อง สัญลักษณ์อาจถูกตัดออกขณะลิงก์ ซึ่งป้องกันได้โดยการตั้งค่า --strip=never

ไวยากรณ์: [+-]regex[,[+-]regex]...@option[,option]... โดย regex หมายถึงนิพจน์ทั่วไปที่มีคำนำหน้าด้วย + เพื่อระบุรูปแบบการรวม และใช้ - เพื่อระบุรูปแบบการยกเว้น option ย่อมาจากตัวเลือกที่กำหนดเองที่ส่งไปยัง คอมไพเลอร์ C++ หากตัวเลือกมี , จะต้องใส่เครื่องหมายอัญประกาศดังนี้ \, ตัวเลือกยังอาจมี @ ได้ด้วย เนื่องจากจะใช้เฉพาะ @ รายการแรกเพื่อแยกนิพจน์ทั่วไปออกจากตัวเลือก

ตัวอย่าง: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs เพิ่มตัวเลือก -O0 และ -fprofile-arcs ในบรรทัดคำสั่งของคอมไพเลอร์ C++ สำหรับไฟล์ .cc ทั้งหมดใน //foo/ ยกเว้น file.cc

--dynamic_mode=mode

กำหนดว่าจะลิงก์ไบนารีของ C++ แบบไดนามิกหรือไม่ โดยโต้ตอบกับแอตทริบิวต์ Linkstatic ในกฎบิลด์

โหมด:

• auto: แปลงเป็นโหมดที่ขึ้นอยู่กับแพลตฟอร์ม default สำหรับ Linux และ off สำหรับ cygwin
• default: อนุญาตให้ Bazel เลือกว่าจะลิงก์แบบไดนามิกหรือไม่ ดูข้อมูลเพิ่มเติมได้ที่ linkstatic
• fully: ลิงก์เป้าหมายทั้งหมดแบบไดนามิก ซึ่งจะช่วยเร่งเวลาในการลิงก์ และลดขนาดของไบนารีที่ได้
• off: ลิงก์เป้าหมายทั้งหมด ในโหมดส่วนใหญ่คงที่ หากมีการตั้งค่า -static ใน Linkopts เป้าหมายจะเปลี่ยนเป็นแบบคงที่ทั้งหมด

--fission (yes|no|[dbg][,opt][,fastbuild])

เปิดใช้ Fission ซึ่งจะเขียนข้อมูลการแก้ไขข้อบกพร่อง C++ ไปยังไฟล์ .dwo โดยเฉพาะแทนไฟล์ .o ซึ่งจะใช้ในการดำเนินการ การดำเนินการนี้จะลดขนาดอินพุตของลิงก์ลงอย่างมากและลดเวลาในการลิงก์

เมื่อตั้งค่าเป็น [dbg][,opt][,fastbuild] (เช่น --fission=dbg,fastbuild) ระบบจะเปิดใช้ Fission เฉพาะกับชุดโหมดการคอมไพล์ที่ระบุ วิธีนี้มีประโยชน์สำหรับการตั้งค่า bazelrc เมื่อตั้งค่าเป็น yes ระบบจะเปิดใช้ Fission ในทุกที่ เมื่อตั้งค่าเป็น no ระบบจะปิดใช้ฟิชชันทั่วโลก ค่าเริ่มต้นคือ no

--force_ignore_dash_static

หากตั้งค่าแฟล็กนี้ ระบบจะไม่พิจารณาตัวเลือก -static ใดๆ ใน linkopt ของ cc_* ไฟล์ BUILD วิธีนี้เป็นการแก้ปัญหาสำหรับบิลด์ที่เสริมความแข็งแกร่งของ C++ เท่านั้น

--[no]force_pic

หากเปิดใช้ การคอมไพล์ C++ ทั้งหมดจะสร้างโค้ดที่ไม่ขึ้นอยู่กับตำแหน่ง ("-fPIC") ลิงก์จะใช้ไลบรารีที่สร้างไว้ล่วงหน้าของ PIC มากกว่าไลบรารีที่ไม่ใช่ PIC และลิงก์จะสร้างไฟล์ปฏิบัติการที่ไม่ขึ้นอยู่กับตำแหน่ง ("-พาย") ค่าเริ่มต้นคือปิดใช้

หมายเหตุ: ไบนารีที่ลิงก์แบบไดนามิก (เช่น --dynamic_mode fully) จะสร้างโค้ด PIC โดยไม่คำนึงถึงการตั้งค่าของแฟล็กนี้ ดังนั้น ธงทำเครื่องหมายนี้ใช้ในกรณีที่ผู้ใช้ต้องการให้มีการสร้างโค้ด PIC อย่างชัดเจนสำหรับลิงก์แบบคงที่

--android_resource_shrinking

เลือกว่าจะลดขนาดทรัพยากรสำหรับกฎ android_binary หรือไม่ ตั้งค่าเริ่มต้นสำหรับแอตทริบิวต์ shrink_resources ในกฎ android_binary โปรดดูรายละเอียดเพิ่มเติมในเอกสารประกอบของกฎนั้น ค่าเริ่มต้นคือปิด

--custom_malloc=malloc-library-target

เมื่อระบุ ให้ใช้การติดตั้งใช้งาน Malloc ที่กำหนดเสมอ โดยลบล้างแอตทริบิวต์ malloc="target" ทั้งหมด ซึ่งรวมถึงในเป้าหมายที่ใช้ค่าเริ่มต้น (โดยการไม่ได้ระบุ malloc)

--crosstool_top=label

ตัวเลือกนี้จะระบุตำแหน่งของชุดคอมไพเลอร์ Crosstool ที่จะใช้สำหรับการคอมไพล์ C++ ทั้งหมดระหว่างบิลด์ Bazel จะค้นหาไฟล์ CROSSTOOL ในตำแหน่งนั้น แล้วใช้ไฟล์นั้นเพื่อกำหนดการตั้งค่าสำหรับ --compiler โดยอัตโนมัติ

--host_crosstool_top=label

หากไม่ได้ระบุไว้ Bazel จะใช้ค่า --crosstool_top เพื่อคอมไพล์โค้ดในการกำหนดค่าการดำเนินการ เช่น เครื่องมือที่ทำงานระหว่างบิลด์ จุดประสงค์หลักของ Flag นี้คือการเปิดใช้การคอมไพล์แบบข้ามแพลตฟอร์ม

--apple_crosstool_top=label

เครื่องมือข้ามที่ใช้สำหรับคอมไพล์กฎ C/C++ ในกฎ deps ทางอ้อมของ objc*, ios*, และ apple* สำหรับเป้าหมายเหล่านั้น แฟล็กนี้จะแทนที่ --crosstool_top

--android_crosstool_top=label

คำเตือน: --android_crosstool_top เลิกใช้งานแล้ว คุณไม่จำเป็นต้องตั้งค่านี้

เครื่องมือข้ามที่ใช้สำหรับคอมไพล์กฎ C/C++ ในกฎ deps จาก android_binary แบบทางอ้อม วิธีนี้มีประโยชน์หากเป้าหมายอื่นๆ ใน บิลด์ต้องใช้ Crosstool ที่แตกต่างกัน ค่าเริ่มต้นคือใช้เครื่องมือข้ามเครื่องมือที่สร้างโดยกฎ android_ndk_repository ในไฟล์ WORKSPACE ดู --android_platforms เพิ่มเติม

--compiler=version

ตัวเลือกนี้จะระบุเวอร์ชันคอมไพเลอร์ C/C++ (เช่น gcc-4.1.0) ที่จะใช้สำหรับการคอมไพล์ไบนารีระหว่างบิลด์ หากต้องการสร้างด้วย Crosstool ที่กำหนดเอง คุณควรใช้ไฟล์ CROSSTOOL แทนการระบุแฟล็กนี้

หมายเหตุ: อนุญาตให้ใช้การผสมผสานระหว่างเวอร์ชัน Crosstool เวอร์ชันของคอมไพเลอร์ และ CPU เป้าหมายร่วมกันเท่านั้น

--android_sdk=label

เลิกใช้งานแล้ว ซึ่งไม่ควรระบุโดยตรง

ตัวเลือกนี้จะระบุ Toolchain ของแพลตฟอร์ม/Android SDK และไลบรารีรันไทม์ของ Android ที่จะใช้ในการสร้างกฎใดๆ ที่เกี่ยวข้องกับ Android

ระบบจะเลือก Android SDK โดยอัตโนมัติหากมีการกำหนดกฎ android_sdk_repository ในไฟล์ WORKSPACE

--java_toolchain=label

ตัวเลือกนี้จะระบุป้ายกำกับของ java_toolchain ที่ใช้เพื่อคอมไพล์ไฟล์แหล่งที่มาของ Java

--host_java_toolchain=label

หากไม่ระบุ Bazel จะใช้ค่า --java_toolchain เพื่อคอมไพล์โค้ดในการกำหนดค่า exec เช่น สำหรับเครื่องมือที่ทำงานระหว่างบิลด์ จุดประสงค์หลักของ Flag นี้คือการเปิดใช้การคอมไพล์แบบข้ามแพลตฟอร์ม

--javabase=(label)

ตัวเลือกนี้จะกำหนดป้ายกำกับของการติดตั้ง Java พื้นฐานที่จะใช้สำหรับการเรียกใช้ Bazel, การทดสอบ Bazel และสำหรับไบนารีของ Java ที่สร้างโดยกฎ java_binary และ java_test ตัวแปร JAVABASE และ JAVA "สร้าง" มาจากตัวเลือกนี้

--host_javabase=label

ตัวเลือกนี้จะกำหนดป้ายกำกับของการติดตั้ง Java พื้นฐานเพื่อใช้ในการกำหนดค่า exec เช่น สำหรับเครื่องมือสร้างโฮสต์ที่ประกอบด้วย JavaBuilder และ Singlejar

โดยไม่เลือกคอมไพเลอร์ Java ที่ใช้ในการคอมไพล์ไฟล์ซอร์สของ Java คุณเลือกคอมไพเลอร์ได้โดยการตั้งค่าตัวเลือก --java_toolchain

กลยุทธ์การดำเนินการ

ตัวเลือกเหล่านี้มีผลต่อวิธีที่ Bazel จะดำเนินการบิลด์ ซึ่งไม่ควรส่งผลอย่างมีนัยสำคัญใดๆ ต่อไฟล์เอาต์พุตที่บิลด์สร้างขึ้น ปกติแล้วผลกระทบหลักจะอยู่ที่ ความเร็วในการสร้าง

--spawn_strategy=strategy

ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีดำเนินการตามคำสั่ง

• standalone ทำให้เรียกใช้คำสั่งเป็นกระบวนการย่อยในเครื่อง ค่านี้เลิกใช้งานแล้ว โปรดใช้ local แทน
• sandboxed ทำให้มีการเรียกใช้คำสั่งภายในแซนด์บ็อกซ์ในเครื่องภายใน โดยกำหนดให้ไฟล์อินพุต ทรัพยากร Dependency และเครื่องมือทั้งหมดต้องแสดงการขึ้นต่อกันโดยตรงในแอตทริบิวต์ srcs, data และ tools Bazel เปิดใช้แซนด์บ็อกซ์ในเครื่องโดยค่าเริ่มต้นในระบบที่รองรับการดำเนินการแบบแซนด์บ็อกซ์
• local ทำให้เรียกใช้คำสั่งเป็นกระบวนการย่อยในเครื่อง
• worker ทำให้มีการเรียกใช้คำสั่งโดยใช้ผู้ปฏิบัติงานถาวร หากมี
• docker ทำให้มีการเรียกใช้คำสั่งภายในแซนด์บ็อกซ์ของ Docker ในเครื่อง จำเป็นต้องติดตั้ง Docker
• remote ทำให้มีการเรียกใช้คำสั่งจากระยะไกล ซึ่งจะใช้ได้ต่อเมื่อกำหนดค่าผู้ดำเนินการระยะไกลไว้ต่างหากเท่านั้น

--strategy mnemonic=strategy

ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีดำเนินการตามคำสั่ง โดยลบล้าง --spawn_strategy (และ --genrule_strategy ด้วย mnemonic Genrule) ตามความสามารถในการจำ ดู --spawn_strategy สำหรับกลยุทธ์ที่รองรับและผลกระทบ

--strategy_regexp=<filter,filter,...>=<strategy>

ตัวเลือกนี้จะระบุว่าควรใช้กลยุทธ์ใดเพื่อเรียกใช้คำสั่งที่มีรายละเอียดตรงกับ regex_filter บางรายการ ดูรายละเอียดเกี่ยวกับการจับคู่นิพจน์ทั่วไปได้ที่ --per_file_copt ดู --spawn_strategy สำหรับกลยุทธ์ที่รองรับและผลกระทบ

ระบบจะใช้ regex_filter สุดท้ายที่ตรงกับคำอธิบาย ตัวเลือกนี้จะลบล้างแฟล็กอื่นๆ สำหรับการระบุกลยุทธ์

• เช่น --strategy_regexp=//foo.*\\.cc,-//foo/bar=local หมายถึงการดำเนินการโดยใช้กลยุทธ์ local หากคำอธิบายตรงกับ //foo.*.cc แต่ไม่ใช่ //foo/bar
• ตัวอย่างเช่น --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed เรียกใช้ "คอมไพล์ //foo/bar/baz" ด้วยกลยุทธ์ sandboxed แต่กลับลำดับเรียกใช้คำสั่งด้วย local
• ตัวอย่างเช่น --strategy_regexp='Compiling.*/bar=local,sandboxed' เรียกใช้ "คอมไพล์ //foo/bar/baz" ด้วยกลยุทธ์ local และกลับไปใช้ sandboxed หากล้มเหลว

--genrule_strategy=strategy

นี่คือเนื้อหาแบบสั้นที่เลิกใช้งานแล้วสำหรับ --strategy=Genrule=strategy

--jobs=n (- จ)

ตัวเลือกนี้ซึ่งใช้อาร์กิวเมนต์จำนวนเต็มจะระบุขีดจำกัดสำหรับจำนวนงานที่ควรทำพร้อมกันในระหว่างระยะการดำเนินการของบิลด์

หมายเหตุ: จำนวนงานที่เกิดขึ้นพร้อมกันที่ Bazel จะเรียกใช้จะขึ้นอยู่กับการตั้งค่า --jobs เท่านั้น แต่ยังกำหนดโดยเครื่องจัดตารางเวลาของ Bazel ด้วย ซึ่งจะพยายามหลีกเลี่ยงการทำงานที่เกิดขึ้นพร้อมกันซึ่งจะใช้ทรัพยากร (RAM หรือ CPU) มากกว่าที่มีอยู่ โดยอิงจากค่าประมาณการใช้ทรัพยากรของแต่ละงาน (ไม่มากก็น้อย) คุณควบคุมการทำงานของเครื่องจัดตารางเวลาได้ด้วยตัวเลือก --local_ram_resources

--progress_report_interval=n

Bazel พิมพ์รายงานความคืบหน้าเป็นระยะสำหรับงานที่ยังไม่เสร็จ (เช่น การทดสอบที่ใช้เวลานาน) ตัวเลือกนี้จะกำหนดความถี่ในการรายงาน โดยจะมีการพิมพ์ความคืบหน้าทุก n วินาที

ค่าเริ่มต้นคือ 0 ซึ่งหมายความว่าจะมีอัลกอริทึมที่เพิ่มขึ้น รายงานแรกจะพิมพ์ออกมาหลังจากผ่านไป 10 วินาที จากนั้นจะพิมพ์ออกมา 30 วินาที และหลังจากนั้นจะมีการรายงานความคืบหน้า 1 ครั้งในทุกๆ นาที

เมื่อ bazel ใช้การควบคุมเคอร์เซอร์ ตามที่ --curses ระบุ ระบบจะรายงานความคืบหน้าทุกวินาที

--local_{ram,cpu}_resources resources or resource expression

ตัวเลือกเหล่านี้จะระบุจำนวนทรัพยากรในเครื่อง (RAM เป็น MB และจำนวนแกนเชิงตรรกะของ CPU) ที่ Bazel นำไปพิจารณาเมื่อกำหนดเวลากิจกรรมการสร้างและทดสอบให้ทำงานภายในเครื่อง โดยจะเลือกจำนวนเต็มหรือคีย์เวิร์ด (HOST_RAM หรือ HOST_CPUS) ตามด้วย [-|*Flo] (เช่น --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1) การตั้งค่าสถานะเป็นอิสระ อาจมีการตั้งค่า 1 หรือทั้ง 2 อย่างก็ได้ โดยค่าเริ่มต้น Bazel จะประมาณจำนวน RAM และจำนวนแกน CPU จากการกำหนดค่าของระบบภายในโดยตรง

--[no]build_runfile_links

ตัวเลือกนี้จะเปิดใช้โดยค่าเริ่มต้น ระบุว่าควรสร้างลิงก์สัญลักษณ์ของ Runfiles สำหรับการทดสอบและไบนารีในไดเรกทอรีเอาต์พุตหรือไม่ การใช้ --nobuild_runfile_links อาจมีประโยชน์ในการตรวจสอบว่าเป้าหมายทั้งหมดคอมไพล์เป้าหมายหรือไม่มีค่าใช้จ่ายในการสร้างต้นไม้การเรียกใช้ไฟล์

เมื่อดำเนินการทดสอบ (หรือแอปพลิเคชัน) ระบบจะรวบรวมข้อมูลการขึ้นต่อกันของข้อมูลรันไทม์มาไว้ในที่เดียว ภายในโครงสร้างเอาต์พุตของ Bazel ต้นไม้ "runfiles" นี้มักได้รับการรูทเป็นพี่น้องของไบนารีหรือการทดสอบที่เกี่ยวข้อง ระหว่างการดำเนินการทดสอบ ระบบอาจเข้าถึงไฟล์ Runfile โดยใช้เส้นทางของแบบฟอร์ม $TEST_SRCDIR/workspace/packagename/filename โครงสร้าง Runfile จะดูแลให้การทดสอบมีสิทธิ์เข้าถึงไฟล์ทั้งหมด ณ เวลาที่ไฟล์มีการขึ้นต่อกันที่ประกาศไว้ จึงไม่ต้องดำเนินการใดๆ เพิ่มเติม โดยค่าเริ่มต้น โครงสร้างไฟล์รันไฟล์จะดำเนินการโดยการสร้างชุดลิงก์สัญลักษณ์ไปยังไฟล์ที่กำหนด เมื่อชุดลิงก์เติบโตขึ้น ค่าใช้จ่ายในการดำเนินการนี้ก็เพิ่มขึ้นด้วย รวมถึงอาจส่งผลอย่างมากต่อเวลาบิลด์โดยรวมสำหรับบิลด์ขนาดใหญ่ โดยเฉพาะอย่างยิ่งเนื่องจากการทดสอบแต่ละครั้ง (หรือแอปพลิเคชัน) ต้องใช้ผังการเรียกใช้ไฟล์ของตัวเอง

--[no]build_runfile_manifests

ตัวเลือกนี้เปิดใช้อยู่โดยค่าเริ่มต้นจะระบุว่าควรเขียนไฟล์ Manifest ของ Runfile ลงในแผนผังเอาต์พุตหรือไม่ การปิดใช้หมายถึง --nobuild_runfile_links

สามารถปิดใช้ได้ขณะดำเนินการทดสอบจากระยะไกล เนื่องจากโครงสร้าง Runfile จะสร้างขึ้นจากระยะไกลจากไฟล์ Manifest ในหน่วยความจำ

--[no]discard_analysis_cache

เมื่อเปิดใช้ตัวเลือกนี้ Bazel จะทิ้งแคชการวิเคราะห์ก่อนที่การดำเนินการจะเริ่มขึ้นทันที ซึ่งจะช่วยเพิ่มหน่วยความจำเพิ่มเติม (ประมาณ 10%) สำหรับระยะการดำเนินการ ข้อเสียก็คือ บิลด์ที่เพิ่มขึ้นเรื่อยๆ จะช้าลง ดูข้อมูลเพิ่มเติมได้ในโหมดประหยัดหน่วยความจำ

--[no]keep_going (-กิโลไบต์)

เช่นเดียวกับใน GNU Make ระยะการดำเนินการกับบิลด์จะหยุดเมื่อพบข้อผิดพลาดแรก บางครั้งการพยายามสร้างให้มากที่สุดเท่าที่จะเป็นไปได้ แม้จะพบกับข้อผิดพลาดก็ตาม ตัวเลือกนี้จะทำให้มีลักษณะการทำงานดังกล่าว และเมื่อระบุไว้ บิลด์จะพยายามสร้างเป้าหมายทุกรายการที่ข้อกำหนดเบื้องต้นสร้างสำเร็จแล้ว แต่จะไม่ประมวลผลข้อผิดพลาด

แม้ว่าตัวเลือกนี้มักจะเชื่อมโยงกับระยะการดำเนินการของบิลด์ แต่จะยังส่งผลต่อขั้นตอนการวิเคราะห์ด้วย กล่าวคือหากระบุเป้าหมายหลายรายการในคำสั่งบิลด์ แต่วิเคราะห์เป้าหมายบางรายการได้สำเร็จ บิลด์จะหยุดทำงานโดยมีข้อผิดพลาดเว้นแต่จะมีการระบุ --keep_going ซึ่งในกรณีนี้ บิลด์จะดำเนินการต่อในขั้นตอนการดำเนินการ แต่เฉพาะกับเป้าหมายที่วิเคราะห์สำเร็จแล้วเท่านั้น

--[no]use_ijars

ตัวเลือกนี้จะเปลี่ยนวิธีรวบรวมเป้าหมาย java_library โดย Bazel แทนที่จะใช้เอาต์พุตของ java_library สำหรับการคอมไพล์เป้าหมาย java_library ที่ไม่เชื่อมโยงกัน Bazel จะสร้าง Jars ของอินเทอร์เฟซที่มีเฉพาะลายเซ็นของสมาชิกที่ไม่ใช่สมาชิกส่วนตัว (วิธีการและฟิลด์เข้าถึงแบบสาธารณะ ที่มีการป้องกัน และเริ่มต้น (แพ็กเกจ) และใช้ Jar ของอินเทอร์เฟซเพื่อรวบรวมเป้าหมายที่เกี่ยวข้อง ซึ่งทำให้หลีกเลี่ยงการคอมไพล์ซ้ำได้เมื่อมีการเปลี่ยนแปลงเฉพาะเนื้อหาวิธีการหรือสมาชิกส่วนตัวของชั้นเรียน

หมายเหตุ: การใช้ --use_ijars อาจแสดงข้อความแสดงข้อผิดพลาดที่ต่างออกไปเมื่อคุณอ้างอิงถึงสมาชิกที่มองไม่เห็นในชั้นเรียนอื่นโดยไม่ตั้งใจ โดยคุณจะได้รับข้อผิดพลาดว่าไม่มีสมาชิกดังกล่าว แต่จะไม่ได้รับข้อผิดพลาดที่ระบุว่าไม่เห็นสมาชิกรายนั้น การเปลี่ยนการตั้งค่า --use_ijars จะบังคับให้คอมไพล์ชั้นเรียนที่ได้รับผลกระทบทั้งหมดอีกครั้ง

--[no]interface_shared_objects

ตัวเลือกนี้จะเปิดใช้ออบเจ็กต์ที่แชร์ของอินเทอร์เฟซ ซึ่งทำให้ไบนารีและไลบรารีที่ใช้ร่วมกันอื่นๆ ขึ้นอยู่กับอินเทอร์เฟซของออบเจ็กต์ที่แชร์มากกว่าการใช้งาน เมื่อเฉพาะการเปลี่ยนแปลงการใช้งาน Bazel สามารถหลีกเลี่ยงการสร้างเป้าหมายใหม่ที่อิงตามไลบรารีที่ใช้ร่วมกันที่มีการเปลี่ยนแปลงโดยไม่จำเป็นได้

การเลือกเอาต์พุต

ตัวเลือกเหล่านี้จะกำหนดสิ่งที่ควรสร้างหรือทดสอบ

--[no]build

ตัวเลือกนี้จะทำให้เฟสการดำเนินการของบิลด์เกิดขึ้น โดยจะเปิดไว้โดยค่าเริ่มต้น เมื่อปิดไว้ ระบบจะข้ามระยะการดำเนินการไป และจะมีเพียง 2 เฟสแรกซึ่งก็คือการโหลดและการวิเคราะห์เท่านั้นเกิดขึ้น

ตัวเลือกนี้มีประโยชน์ในการตรวจสอบความถูกต้องของไฟล์ BUILD และตรวจหาข้อผิดพลาดในการป้อนข้อมูล โดยไม่ต้องสร้างอะไรเลย

--[no]build_tests_only

หากระบุ Bazel จะสร้างเฉพาะสิ่งที่จำเป็นต่อการเรียกใช้กฎ *_test และ test_suite ที่ไม่ได้กรองออกเนื่องจากขนาด ระยะหมดเวลา แท็ก หรือภาษา หากระบุไว้ Bazel จะไม่สนใจเป้าหมายอื่นๆ ที่ระบุในบรรทัดคำสั่ง โดยค่าเริ่มต้น ตัวเลือกนี้จะปิดใช้และ Bazel จะสร้างทุกอย่างที่ขอ รวมถึงกฎ *_test และ test_suite ที่กรองออกจากการทดสอบ วิธีนี้มีประโยชน์เนื่องจากการเรียกใช้ bazel test --build_tests_only foo/... อาจตรวจไม่พบการหยุดทำงานของบิลด์ทั้งหมดในแผนผัง foo

--[no]check_up_to_date

ตัวเลือกนี้จะทำให้ Bazel ไม่สร้างบิลด์ แต่ทำได้เพียงตรวจสอบว่าเป้าหมายที่ระบุทั้งหมดเป็นข้อมูลล่าสุดหรือไม่ หากเป็นเช่นนั้น บิลด์ ก็เสร็จสมบูรณ์ตามปกติ แต่หากไฟล์เก่าเกินไป ระบบจะรายงานข้อผิดพลาดและบิลด์ล้มเหลวแทนที่จะสร้างไฟล์ขึ้นมา ตัวเลือกนี้อาจเป็นประโยชน์ในการระบุว่าบิลด์ได้รับการดำเนินการเมื่อเร็วๆ นี้มากกว่าการแก้ไขแหล่งที่มาหรือไม่ (เช่น สำหรับการตรวจสอบที่ส่งล่วงหน้า) โดยไม่ทำให้ค่าใช้จ่ายของบิลด์

ดู --check_tests_up_to_date เพิ่มเติม

--[no]compile_one_dependency

คอมไพล์ทรัพยากร Dependency เดียวของไฟล์อาร์กิวเมนต์ ซึ่งมีประโยชน์สำหรับการตรวจสอบไวยากรณ์ไฟล์ต้นฉบับใน IDE เช่น การสร้างเป้าหมายเดียวขึ้นมาใหม่ที่ขึ้นอยู่กับไฟล์แหล่งที่มา เพื่อตรวจหาข้อผิดพลาดให้เร็วที่สุดเท่าที่จะทำได้ในรอบการแก้ไข/สร้าง/ทดสอบ อาร์กิวเมนต์นี้ส่งผลต่อวิธีตีความอาร์กิวเมนต์ที่ไม่แจ้งทั้งหมด อาร์กิวเมนต์แต่ละรายการต้องเป็นป้ายกำกับเป้าหมายไฟล์หรือชื่อไฟล์ธรรมดาที่สัมพันธ์กับไดเรกทอรีที่ใช้งานอยู่ปัจจุบัน และมีกฎ 1 ข้อที่ขึ้นอยู่กับชื่อไฟล์ต้นทางแต่ละรายการที่สร้าง สำหรับแหล่งที่มาของ C++ และ Java ระบบจะเลือกใช้กฎในพื้นที่ภาษาเดียวกัน สำหรับกฎหลายข้อที่มีค่ากำหนดเหมือนกัน ระบบจะเลือกกฎที่ปรากฏก่อนในไฟล์ "สร้าง" รูปแบบเป้าหมายที่มีชื่อชัดเจนซึ่งไม่ได้อ้างอิงไฟล์แหล่งที่มาจะทำให้เกิดข้อผิดพลาด

--save_temps

ตัวเลือก --save_temps จะทำให้ระบบบันทึกเอาต์พุตชั่วคราวจากคอมไพเลอร์ ซึ่งรวมถึงไฟล์ .s (โค้ด Ascyclr), .i (C ที่ประมวลผลล่วงหน้า) และ .ii (C++ ที่ประมวลผลล่วงหน้า) เอาต์พุตเหล่านี้มักมีประโยชน์ในการแก้ไขข้อบกพร่อง ระบบจะสร้างชั่วคราวสำหรับชุดของเป้าหมายที่ระบุในบรรทัดคำสั่งเท่านั้น

หมายเหตุ: การใช้งาน --save_temps ไม่ได้ใช้แฟล็ก -save-temps ของคอมไพเลอร์ แต่มีบัตร 2 ใบ โดยใบแรกมี -S และอีกใบมี -E ผลที่ตามมาคือหากการสร้างของคุณล้มเหลว Bazel อาจยังไม่ได้สร้างไฟล์ ".i" หรือ ".ii" และ ".s" หากพยายามใช้ --save_temps เพื่อแก้ไขข้อบกพร่องการคอมไพล์ที่ล้มเหลว คุณอาจต้องใช้ --keep_going ด้วยเพื่อให้ Bazel ยังคงพยายามสร้างไฟล์ที่ประมวลผลล่วงหน้าหลังจากที่คอมไพล์ไม่สำเร็จ

ขณะนี้แฟล็ก --save_temps ใช้ได้กับกฎ cc_* เท่านั้น

หากต้องการตรวจสอบว่า Bazel พิมพ์ตำแหน่งของไฟล์เอาต์พุตเพิ่มเติม ให้ตรวจสอบว่าการตั้งค่า --show_result n ของคุณสูงพอ

--build_tag_filters=tag[,tag]*

หากระบุ Bazel จะสร้างเฉพาะเป้าหมายที่มีแท็กที่จำเป็นอย่างน้อย 1 แท็ก (หากระบุไว้) และไม่มีแท็กที่ยกเว้น ตัวกรองแท็กบิลด์จะระบุเป็นรายการคีย์เวิร์ดของแท็กที่คั่นด้วยคอมมา ซึ่งอาจนำหน้าด้วยเครื่องหมาย "-" ซึ่งใช้เพื่อระบุแท็กที่ยกเว้น แท็กที่ต้องใช้อาจมีเครื่องหมาย "+" นำหน้าด้วย

เมื่อทำการทดสอบ Bazel จะไม่สนใจ --build_tag_filters สำหรับเป้าหมายการทดสอบ ซึ่งสร้างและเรียกใช้แม้ว่าจะไม่ตรงกับตัวกรองนี้ก็ตาม หากต้องการหลีกเลี่ยงการสร้างเป้าหมาย ให้กรองเป้าหมายทดสอบโดยใช้ --test_tag_filters หรือโดยการยกเว้นเป้าหมายเหล่านั้นอย่างชัดแจ้ง

--test_size_filters=size[,size]*

หากระบุ Bazel จะทดสอบ (หรือสร้างบิลด์หากระบุ --build_tests_only ด้วย) เฉพาะเป้าหมายที่มีขนาดตามที่กำหนดเท่านั้น ตัวกรองขนาดทดสอบถูกระบุเป็นรายการขนาดทดสอบที่อนุญาต (เล็ก กลาง ใหญ่ หรือใหญ่) ที่คั่นด้วยคอมมา (เล็ก กลาง ใหญ่ หรือใหญ่) (อาจจะมีเครื่องหมาย '-') นำหน้าหรือใช้เพื่อแสดงถึงขนาดทดสอบที่ยกเว้น ตัวอย่างเช่น

  % bazel test --test_size_filters=small,medium //foo:all

และ

  % bazel test --test_size_filters=-large,-enormous //foo:all

จะทดสอบเฉพาะการทดสอบขนาดเล็กและขนาดกลางภายใน //foo

โดยค่าเริ่มต้น ระบบจะไม่ใช้การกรองขนาดทดสอบ

--test_timeout_filters=timeout[,timeout]*

หากระบุ Bazel จะทดสอบ (หรือสร้างหากมีการระบุ --build_tests_only ด้วย) ทดสอบเฉพาะเป้าหมายที่มีระยะหมดเวลาที่กำหนดไว้เท่านั้น ตัวกรองระยะหมดเวลาทดสอบ ถูกระบุเป็นรายการที่คั่นด้วยเครื่องหมายจุลภาคของค่าระยะหมดเวลาทดสอบที่อนุญาต (สั้น ปานกลาง ยาว หรือถาวร) (ไม่บังคับ) นำหน้าด้วยเครื่องหมาย "-" ที่ใช้แสดงถึงการหมดเวลาทดสอบที่ยกเว้น ดู --test_size_filters ตัวอย่างไวยากรณ์

โดยค่าเริ่มต้น ระบบจะไม่ใช้การกรองระยะหมดเวลาทดสอบ

--test_tag_filters=tag[,tag]*

หากระบุไว้ Bazel จะทดสอบ (หรือสร้างหากระบุ --build_tests_only ด้วย) เฉพาะเป้าหมายที่มีแท็กที่จำเป็นอย่างน้อย 1 แท็ก (หากระบุแท็กใดแท็กหนึ่งไว้) และไม่มีแท็กที่ยกเว้น ตัวกรองแท็กทดสอบถูกระบุเป็นรายการคีย์เวิร์ดของแท็กที่คั่นด้วยคอมมา ซึ่งอาจนำหน้าด้วยเครื่องหมาย "-" ซึ่งใช้เพื่อระบุแท็กที่ยกเว้น แท็กที่ต้องใช้อาจมีเครื่องหมาย "+" นำหน้าด้วย

ตัวอย่างเช่น

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

จะทดสอบเป้าหมายที่ติดแท็กด้วยแท็ก performance หรือ stress แต่ไม่ได้ติดแท็ก flaky

โดยค่าเริ่มต้น ระบบจะไม่ใช้การกรองแท็กทดสอบ โปรดทราบว่าคุณยังกรองแท็ก size และ local ของการทดสอบด้วยวิธีนี้ได้ด้วย

--test_lang_filters=string[,string]*

ระบุรายการสตริงที่คั่นด้วยคอมมาซึ่งอ้างอิงถึงชื่อคลาสกฎการทดสอบ หากต้องการอ้างอิงคลาสกฎ foo_test ให้ใช้สตริง "foo" Bazel จะทดสอบ (หรือสร้างหากระบุ --build_tests_only ด้วย) เฉพาะเป้าหมายของคลาสกฎที่อ้างอิงเท่านั้น หากต้องการยกเว้นเป้าหมายเหล่านั้นแทน ให้ใช้สตริง "-foo" ตัวอย่างเช่น

  % bazel test --test_lang_filters=foo,bar //baz/...

จะทดสอบเฉพาะเป้าหมายที่เป็นอินสแตนซ์ของ foo_test หรือ bar_test ใน //baz/... ในขณะที่

  % bazel test --test_lang_filters=-foo,-bar //baz/...

จะทดสอบเป้าหมายทั้งหมดใน //baz/... ยกเว้นอินสแตนซ์ foo_test และ bar_test

เคล็ดลับ: คุณใช้ bazel query --output=label_kind "//p:t" เพื่อดูชื่อคลาสของกฎ //p:t เป้าหมายได้ และคุณยังดูคู่สแต็กการสร้างอินสแตนซ์ในเอาต์พุตของ bazel query --output=build "//p:t" ได้ เพื่อดูว่าเหตุใดเป้าหมายนั้นจึงเป็นอินสแตนซ์ของคลาสกฎนั้น

คำเตือน: ชื่อตัวเลือก "--test_lang_filter" เป็นการสืบสวน ดังนั้นจึงทำให้เกิดความเข้าใจผิด ขออภัย อย่าตั้งสมมติฐานเกี่ยวกับอรรถศาสตร์ตามชื่อ

--test_filter=filter-expression

ระบุตัวกรองที่ตัวดำเนินการทดสอบอาจใช้เพื่อเลือกชุดย่อยของการทดสอบที่จะเรียกใช้ เป้าหมายทั้งหมดที่ระบุในการเรียกใช้จะสร้างขึ้น แต่ขึ้นอยู่กับนิพจน์ที่จะมีการดำเนินการเฉพาะบางรายการเท่านั้น ในบางกรณี อาจมีการเรียกใช้วิธีทดสอบเพียงบางวิธีเท่านั้น

การตีความที่เฉพาะเจาะจงของ filter-expression จะขึ้นอยู่กับเฟรมเวิร์กการทดสอบที่รับผิดชอบในการทำการทดสอบ ซึ่งอาจเป็น glob, สตริงย่อย หรือ regexp --test_filter ช่วยให้ส่งอาร์กิวเมนต์ตัวกรอง --test_arg ที่ต่างกันได้ แต่ไม่มีบางเฟรมเวิร์กที่รองรับ

การพูดรายละเอียด

ตัวเลือกเหล่านี้จะควบคุมการพูดรายละเอียดเอาต์พุตของ Bazel ไม่ว่าจะเป็นเทอร์มินัลหรือไฟล์บันทึกเพิ่มเติม

--explain=logfile

ตัวเลือกนี้ซึ่งต้องใช้อาร์กิวเมนต์ชื่อไฟล์จะทำให้เครื่องมือตรวจสอบการขึ้นต่อกันในระยะการดำเนินการของ bazel build อธิบายแต่ละขั้นตอนของบิลด์ว่าทำไมจึงดำเนินการหรือเป็นเวอร์ชันล่าสุด ระบบจะเขียนคำอธิบายลงใน logfile

หากคุณพบการสร้างใหม่ที่ไม่คาดคิด ตัวเลือกนี้ช่วยให้คุณเข้าใจสาเหตุได้ เพิ่มลงใน .bazelrc เพื่อให้การบันทึกเกิดขึ้นสำหรับบิลด์ที่ตามมาทั้งหมด จากนั้นตรวจสอบบันทึกเมื่อเห็นขั้นตอนการดำเนินการดำเนินการโดยไม่คาดคิด ตัวเลือกนี้อาจมีบทลงโทษด้านประสิทธิภาพเล็กน้อย คุณจึงอาจต้องนำออกเมื่อไม่จำเป็นต้องใช้อีกต่อไป

--verbose_explanations

ตัวเลือกนี้จะเพิ่มความละเอียดของคำอธิบายที่สร้างขึ้นเมื่อเปิดใช้ตัวเลือก --explain

กล่าวอย่างเจาะจงคือ หากเปิดใช้คำอธิบายแบบละเอียด และระบบสร้างไฟล์เอาต์พุตขึ้นมาใหม่เนื่องจากคำสั่งที่ใช้สร้างมีการเปลี่ยนแปลง เอาต์พุตในไฟล์คำอธิบายจะมีรายละเอียดทั้งหมดของคำสั่งใหม่ (อย่างน้อยสำหรับคำสั่งส่วนใหญ่)

การใช้ตัวเลือกนี้อาจเพิ่มความยาวของไฟล์คำอธิบายที่สร้างขึ้นและบทลงโทษด้านประสิทธิภาพจากการใช้ --explain อย่างมาก

หากไม่ได้เปิดใช้ --explain ไว้ --verbose_explanations จะไม่มีผล

--profile=file

ตัวเลือกนี้ซึ่งใช้อาร์กิวเมนต์ชื่อไฟล์ จะทำให้ Bazel เขียนข้อมูลการทำโปรไฟล์ลงในไฟล์ จากนั้นจะวิเคราะห์หรือแยกวิเคราะห์ข้อมูลได้โดยใช้คำสั่ง bazel analyze-profile โปรไฟล์บิลด์มีประโยชน์ในการทำความเข้าใจว่าคำสั่ง build ของ Bazel ใช้เวลาที่ใด

--[no]show_loading_progress

ตัวเลือกนี้ทำให้ Bazel แสดงข้อความแจ้งความคืบหน้าในการโหลดแพ็กเกจ หากปิดใช้ ข้อความจะไม่แสดง

--[no]show_progress

ตัวเลือกนี้จะทำให้ข้อความแสดงความคืบหน้าปรากฏขึ้น โดยจะเปิดโดยค่าเริ่มต้น เมื่อปิดใช้ ระบบจะระงับข้อความแสดงความคืบหน้า

--show_progress_rate_limit=n

ตัวเลือกนี้จะทำให้ bazel แสดงข้อความความคืบหน้าสูงสุด 1 ข้อความต่อ n วินาที โดยที่ n คือจำนวนจริง ค่าเริ่มต้นของตัวเลือกนี้คือ 0.02 ซึ่งหมายความว่า Bazel จะจำกัดข้อความความคืบหน้าไว้ที่ 1 ข้อความต่อ 0.02 วินาที

--show_result=n

ตัวเลือกนี้จะควบคุมการพิมพ์ข้อมูลผลการค้นหาในตอนท้ายของคำสั่ง bazel build โดยค่าเริ่มต้น หากระบุเป้าหมายบิลด์เดียว Bazel จะพิมพ์ข้อความว่าอัปเดตเป้าหมายสำเร็จหรือไม่ และหากระบุ ให้แสดงรายการไฟล์เอาต์พุตที่เป้าหมายสร้างขึ้น หากระบุหลายเป้าหมาย ข้อมูลผลลัพธ์จะไม่แสดง

แม้ว่าข้อมูลผลลัพธ์อาจเป็นประโยชน์สำหรับบิลด์ของเป้าหมายเดียวหรือไม่กี่เป้าหมาย แต่สำหรับบิลด์ขนาดใหญ่ (เช่น โครงสร้างโปรเจ็กต์ระดับบนสุดทั้งหมด) ข้อมูลนี้อาจมากเกินไปและทำให้เสียสมาธิ ตัวเลือกนี้ทำให้คุณสามารถควบคุมได้ --show_result จะใช้อาร์กิวเมนต์จำนวนเต็ม ซึ่งเป็นจำนวนเป้าหมายสูงสุดสำหรับพิมพ์ข้อมูลผลลัพธ์แบบเต็ม ค่าเริ่มต้นคือ 1 เหนือเกณฑ์นี้ ระบบจะไม่แสดงข้อมูลผลลัพธ์ของแต่ละเป้าหมาย ดังนั้น ค่า 0 จะทำให้ระบบไม่แสดงข้อมูลผลลัพธ์เสมอ และค่าที่สูงมากจะทำให้ระบบพิมพ์ผลลัพธ์เสมอ

ผู้ใช้อาจต้องการเลือกค่าระหว่างการสร้างเป้าหมายกลุ่มเล็กๆ สลับไปมาเป็นประจำ (เช่น ระหว่างรอบการทดสอบการแก้ไข-คอมไพล์) และเป้าหมายกลุ่มใหญ่ (เช่น เมื่อสร้างพื้นที่ทำงานใหม่หรือเรียกใช้การทดสอบการถดถอย) ในกรณีแรก ข้อมูลผลการค้นหามีประโยชน์มาก แต่ในกรณีหลัง ข้อมูลจะไม่มีประโยชน์นัก เช่นเดียวกับตัวเลือกทั้งหมด การระบุนี้โดยปริยายผ่านไฟล์ .bazelrc

ระบบจะพิมพ์ไฟล์เพื่อให้คัดลอกและวางชื่อไฟล์ลงใน Shell เพื่อเรียกใช้ไฟล์ปฏิบัติการที่สร้างขึ้นได้ง่ายๆ ข้อความที่ "อัปเดตแล้ว" หรือ "ล้มเหลว" ของแต่ละเป้าหมายสามารถแยกวิเคราะห์ได้อย่างง่ายดายด้วยสคริปต์ที่ขับเคลื่อนบิลด์

--sandbox_debug

ตัวเลือกนี้ทำให้ Bazel พิมพ์ข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติมเมื่อใช้แซนด์บ็อกซ์สำหรับการดำเนินการ ตัวเลือกนี้จะเก็บรักษาไดเรกทอรีแซนด์บ็อกซ์ไว้เพื่อให้ตรวจสอบไฟล์ที่แสดงระหว่างการดำเนินการได้

--subcommands (-s)

ตัวเลือกนี้จะทำให้ระยะการดำเนินการของ Bazel พิมพ์บรรทัดคำสั่งแบบเต็มสำหรับแต่ละคำสั่งก่อนดำเนินการ

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

หากเป็นไปได้ ระบบจะพิมพ์คำสั่งในไวยากรณ์ที่เข้ากันได้กับ Bourne Shell เพื่อให้คัดลอกและวางลงในพรอมต์คำสั่งของ Shell ได้อย่างง่ายดาย (ระบบจะใส่วงเล็บไว้รอบๆ ไว้เพื่อปกป้องเชลล์ของคุณจากการเรียก cd และ exec โปรดอย่าลืมคัดลอกวงเล็บเหล่านั้น) อย่างไรก็ตาม คำสั่งบางอย่างมีการใช้งานภายใน Bazel เช่น การสร้างต้นไม้ Symlink ไม่มีบรรทัดคำสั่งที่จะแสดงสำหรับรายการเหล่านี้

ระบบอาจส่งผ่าน --subcommands=pretty_print เพื่อพิมพ์อาร์กิวเมนต์ของคำสั่งเป็นรายการ แทนที่จะเป็นบรรทัดเดียว วิธีนี้อาจช่วยให้บรรทัดคำสั่งยาวๆ อ่านได้ง่ายขึ้น

ดู --verbose_failures ด้านล่าง

สำหรับการบันทึกคำสั่งย่อยลงในไฟล์ในรูปแบบที่เหมาะกับเครื่องมือ โปรดดู --execution_log_json_file และ --execution_log_binary_file

--verbose_failures

ตัวเลือกนี้จะทำให้ระยะการดำเนินการของ Bazel พิมพ์บรรทัดคำสั่งแบบเต็มสำหรับคำสั่งที่ล้มเหลว การดำเนินการเช่นนี้มีประโยชน์อย่างมากในการแก้ไขข้อบกพร่องของบิลด์ที่ล้มเหลว

ระบบจะพิมพ์คำสั่งที่ไม่สำเร็จด้วยไวยากรณ์ที่เข้ากันได้ร่วมกับเชลล์ของ Bourne เหมาะสำหรับการคัดลอกและวางลงในพรอมต์ของ Shell

สถานะพื้นที่ทำงาน

ใช้ตัวเลือกเหล่านี้เพื่อ "ประทับตรา" ไบนารีที่สร้างด้วย Bazel: เพื่อฝังข้อมูลเพิ่มเติมลงในไบนารี เช่น การแก้ไขการควบคุมต้นทางหรือข้อมูลอื่นๆ ที่เกี่ยวข้องกับพื้นที่ทำงาน คุณใช้กลไกนี้กับกฎที่รองรับแอตทริบิวต์ stamp ได้ เช่น genrule, cc_binary และอื่นๆ

--workspace_status_command=program

แฟล็กนี้ช่วยให้คุณระบุไบนารีที่ Bazel เรียกใช้ก่อนบิลด์แต่ละรายการได้ โปรแกรมสามารถรายงานข้อมูลเกี่ยวกับสถานะของพื้นที่ทำงาน เช่น การแก้ไขการควบคุมแหล่งที่มาปัจจุบัน

ค่าของแฟล็กต้องเป็นเส้นทางไปยังโปรแกรมเนทีฟ ใน Linux/macOS ไฟล์นี้อาจเป็นไฟล์สั่งการได้ ใน Windows ไฟล์นี้ต้องเป็นไบนารีดั้งเดิม ซึ่งมักจะเป็นไฟล์ ".exe", ".bat" หรือ ".cmd"

โปรแกรมควรพิมพ์คู่คีย์/ค่าเป็น 0 คู่ขึ้นไปในเอาต์พุตมาตรฐาน แล้ว 1 รายการในแต่ละบรรทัด แล้วออกด้วยค่า 0 (ไม่เช่นนั้นบิลด์จะล้มเหลว) ชื่อคีย์จะเป็นอะไรก็ได้ แต่อาจใช้ อักษรตัวพิมพ์ใหญ่และขีดล่างเท่านั้น เว้นวรรคแรกหลังชื่อคีย์จะแยกชื่อคีย์ออกจากค่า ค่านี้คือส่วนที่เหลือของบรรทัด (รวมถึงช่องว่างเพิ่มเติม) ทั้งคีย์และค่าต้องไม่ครอบคลุมหลายบรรทัด คีย์ต้องไม่ซ้ำกัน

Bazel แบ่งคีย์ออกเป็น 2 ที่เก็บข้อมูล ได้แก่ "เสถียร" และ "ผันผวน" (ชื่อที่ "เสถียร" และ "ผันผวน" จะฟังดูขัดกันเล็กน้อย ดังนั้นอย่าคิดมาก)

จากนั้น Bazel เขียนคู่คีย์-ค่าลงในไฟล์ 2 ไฟล์ดังนี้

• bazel-out/stable-status.txt มีคีย์และค่าทั้งหมดที่ชื่อคีย์ขึ้นต้นด้วย STABLE_
• bazel-out/volatile-status.txt มีคีย์และค่าที่เหลือของคีย์ทั้งหมด

สัญญาคือ

• ค่าของคีย์ที่ "เสถียร" ควรเปลี่ยนแปลงไปน้อย หากทำได้ หากเนื้อหาของ bazel-out/stable-status.txt เปลี่ยนไป Bazel จะยกเลิกการดำเนินการที่เกี่ยวข้อง กล่าวคือ หากค่าของคีย์แบบคงที่เปลี่ยนแปลง Bazel จะเรียกใช้การดำเนินการที่มีการประทับตราอีกครั้ง ดังนั้น สถานะที่เสถียรไม่ควรมีสิ่งต่างๆ เช่น การประทับเวลา เนื่องจากมีการเปลี่ยนแปลงอยู่ตลอดเวลา และจะทำให้ Bazel เรียกใช้การดำเนินการที่มีการประทับตราอีกครั้งกับแต่ละบิลด์

  Bazel จะส่งออกคีย์แบบคงที่ต่อไปนี้เสมอ

  • BUILD_EMBED_LABEL: ค่าของ --embed_label
  • BUILD_HOST: ชื่อเครื่องโฮสต์ที่ Bazel ทำงานอยู่
  • BUILD_USER: ชื่อของผู้ใช้ที่ Bazel ใช้งานอยู่

• ค่าของคีย์ที่ "ผันผวน" อาจเปลี่ยนแปลงบ่อยครั้ง Bazel คาดหวังว่าจะมีการเปลี่ยนแปลงทุกครั้งเหมือนกับการประทับเวลา และควรอัปเดตไฟล์ bazel-out/volatile-status.txt อย่างถูกต้อง แต่เพื่อหลีกเลี่ยงการเรียกใช้การดำเนินการที่ประทับตราซ้ำตลอดเวลา Bazel จะแอบอ้างว่าไฟล์ที่มีความผันผวนไม่มีการเปลี่ยนแปลง กล่าวคือ หากไฟล์สถานะที่มีความผันผวนเป็นไฟล์เดียวที่มีการเปลี่ยนแปลงเนื้อหา Bazel จะไม่ทำให้การทำงานที่ต้องใช้ไฟล์ดังกล่าวเป็นโมฆะ หากอินพุตอื่นๆ ของการดำเนินการมีการเปลี่ยนแปลง Bazel จะเรียกใช้การดำเนินการนั้นอีกครั้ง และการดําเนินการจะเห็นสถานะที่มีความผันผวนที่อัปเดตแล้ว แต่การเปลี่ยนแปลงสถานะผันผวนเพียงอย่างเดียวจะไม่ทำให้การดำเนินการเป็นโมฆะ

  Bazel จะแสดงคีย์ที่ผันผวนต่อไปนี้เสมอ

  • BUILD_TIMESTAMP: เวลาของบิลด์ในหน่วยวินาทีนับตั้งแต่ Unix Epoch (ค่า System.currentTimeMillis() หารด้วย 1)
  • FORMATTED_DATE: เวลาของบิลด์ที่จัดรูปแบบเป็น yyyy MMM d HH mm ss EEE(เช่น 2023 มิถุนายน 2 01 44 29 ศุกร์) ใน UTC

ใน Linux/macOS คุณสามารถส่ง --workspace_status_command=/bin/true เพื่อปิดใช้การดึงสถานะพื้นที่ทำงานได้เนื่องจาก true ทำอะไรไม่ได้เลย (ออกจากศูนย์) และพิมพ์ไม่มีเอาต์พุต ใน Windows คุณสามารถส่งเส้นทางของ true.exe ของ MSYS เพื่อให้ได้ผลลัพธ์เดียวกันได้

หากคำสั่งสถานะพื้นที่ทำงานไม่สำเร็จ (ออกจากค่าที่ไม่ใช่ 0) ไม่ว่าด้วยเหตุผลใดก็ตาม บิลด์จะล้มเหลว

ตัวอย่างโปรแกรมบน Linux ที่ใช้ Git

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

ส่งเส้นทางของโปรแกรมนี้ด้วย --workspace_status_command และไฟล์สถานะที่มีความเสถียรจะรวมบรรทัด STABLE และไฟล์สถานะที่มีความผันผวนจะมีบรรทัดที่เหลือรวมอยู่ด้วย

--[no]stamp

ตัวเลือกนี้เมื่อใช้ร่วมกับแอตทริบิวต์กฎ stamp จะควบคุมว่าจะฝังข้อมูลบิลด์ไว้ในไบนารีหรือไม่

คุณจะเปิดหรือปิดใช้การประทับตราอย่างชัดแจ้งในกฎแต่ละข้อได้โดยใช้แอตทริบิวต์ stamp โปรดดูรายละเอียดจาก Build Encyclopedia เมื่อกฎตั้งค่า stamp = -1 (ค่าเริ่มต้นสำหรับกฎ *_binary) ตัวเลือกนี้จะกำหนดว่าเปิดใช้การประทับตราหรือไม่

Bazel จะไม่ประทับตราไบนารีที่สร้างสำหรับการกำหนดค่าการดำเนินการ ไม่ว่าตัวเลือกนี้หรือแอตทริบิวต์ stamp ก็ตาม สำหรับกฎที่ตั้งค่าไว้เป็น stamp = 0 (ค่าเริ่มต้นสำหรับกฎ *_test) ระบบจะปิดใช้การประทับตราโดยไม่คำนึงถึง --[no]stamp การระบุ --stamp จะไม่บังคับให้สร้างเป้าหมายใหม่หากทรัพยากร Dependency ไม่เปลี่ยนแปลง

โดยทั่วไปแล้วผู้ใช้ต้องการการตั้งค่า --nostamp เพื่อเพิ่มประสิทธิภาพบิลด์ เนื่องจากจะช่วยลดความผันผวนของอินพุตและเพิ่มการแคชบิลด์สูงสุด

แพลตฟอร์ม

ใช้ตัวเลือกเหล่านี้เพื่อควบคุมแพลตฟอร์มโฮสต์และเป้าหมายที่กำหนดค่าวิธีการทำงานของบิลด์ รวมถึงควบคุมแพลตฟอร์มการดำเนินการและ Toolchain ที่มีให้ใช้งานในกฎของ Bazel

โปรดดูข้อมูลเบื้องต้นเกี่ยวกับแพลตฟอร์มและ Toolchains

--platforms=labels

ป้ายกำกับของกฎแพลตฟอร์มที่อธิบายแพลตฟอร์มเป้าหมายสำหรับคำสั่งปัจจุบัน

--host_platform=label

ป้ายกำกับของกฎแพลตฟอร์มที่อธิบายระบบโฮสต์

--extra_execution_platforms=labels

แพลตฟอร์มที่มีให้ใช้งานเป็นแพลตฟอร์มการดำเนินการเพื่อเรียกใช้การดำเนินการ สามารถระบุแพลตฟอร์มโดยเป้าหมายที่แน่นอนหรือเป็นรูปแบบเป้าหมาย เราจะพิจารณาแพลตฟอร์มเหล่านี้ก่อนประกาศในไฟล์ WORKSPACE โดย register_execution_platforms() โดยตัวเลือกนี้จะยอมรับรายการแพลตฟอร์มที่คั่นด้วยคอมมาตามลำดับความสำคัญ หากมีการแฟล็กหลายครั้ง การลบล้างล่าสุด

--extra_toolchains=labels

กฎ Toolchain ที่จะต้องพิจารณาระหว่างการแก้ไข Toolchain สามารถระบุ Toolchains ตามเป้าหมายที่แน่นอนหรือเป็นรูปแบบเป้าหมายได้ ระบบจะพิจารณา Toolchain เหล่านี้ก่อนการประกาศในไฟล์ WORKSPACE โดย register_toolchains()

--toolchain_resolution_debug=regex

พิมพ์ข้อมูลการแก้ไขข้อบกพร่องขณะค้นหา Toolchain หากประเภท Toolchain ตรงกับนิพจน์ทั่วไป คุณสามารถคั่นนิพจน์ทั่วไปหลายรายการได้ด้วยคอมมา คุณลบล้างนิพจน์ทั่วไปได้โดยใช้ - ที่ตอนต้น ซึ่งอาจช่วยให้นักพัฒนาซอฟต์แวร์ของกฎ Bazel หรือ Starlark แก้ไขข้อบกพร่องไม่สำเร็จเนื่องจากไม่มีเครื่องมือเชน

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

แฟล็กตามสะดวกที่ใช้เพื่อเชื่อมโยงการตั้งค่าบิลด์ของ Starlark ที่ยาวขึ้นกับชื่อที่สั้นลง ดูรายละเอียดเพิ่มเติมได้ที่การกำหนดค่า Starlark

--symlink_prefix=string

เปลี่ยนคำนำหน้าของลิงก์สัญลักษณ์แบบอำนวยความสะดวกที่สร้างขึ้น ค่าเริ่มต้นสำหรับคำนำหน้าลิงก์สัญลักษณ์คือ bazel- ซึ่งจะสร้างลิงก์สัญลักษณ์ bazel-bin, bazel-testlogs และ bazel-genfiles

หากสร้างลิงก์สัญลักษณ์ไม่ได้ไม่ว่าด้วยเหตุผลใดก็ตาม เราจะออกคำเตือนแต่ยังถือว่าสำเร็จอยู่ โดยเฉพาะอย่างยิ่ง วิธีนี้ช่วยให้คุณสร้างไดเรกทอรีแบบอ่านอย่างเดียวหรือไดเรกทอรีที่คุณไม่มีสิทธิ์เขียนลงไปได้ เส้นทางใดๆ ที่พิมพ์ในข้อความที่ให้ข้อมูลไว้ที่สิ้นสุดของบิลด์จะใช้เฉพาะรูปแบบแบบสั้นที่สัมพันธ์กับสัญลักษณ์ลิงก์เท่านั้น หากลิงก์สัญลักษณ์ชี้ไปยังตำแหน่งที่คาดไว้ กล่าวคือ คุณสามารถพึ่งพาความถูกต้องของเส้นทางเหล่านั้นได้ แม้ว่าจะอาศัยสัญลักษณ์ลิงก์สัญลักษณ์ที่สร้างขึ้นเองไม่ได้ก็ตาม

ค่าทั่วไปบางค่าของตัวเลือกนี้มีดังนี้

• ระงับการสร้างลิงก์สัญลักษณ์: --symlink_prefix=/ จะทำให้ Bazel ไม่สร้างหรืออัปเดตลิงก์สัญลักษณ์ใดๆ รวมถึงลิงก์สัญลักษณ์ bazel-out และ bazel-<workspace> ใช้ตัวเลือกนี้เพื่อระงับการสร้างลิงก์สัญลักษณ์ทั้งหมด

• ลดความยุ่งเหยิง: --symlink_prefix=.bazel/ จะทำให้ Bazel สร้าง ลิงก์สัญลักษณ์ที่เรียกว่า bin (ฯลฯ) ภายในไดเรกทอรีที่ซ่อนอยู่ .bazel

--platform_suffix=string

เพิ่มคำต่อท้ายของการกำหนดค่าย่อ ซึ่งใช้เพื่อกำหนดไดเรกทอรีเอาต์พุต การตั้งค่าตัวเลือกนี้เป็นค่าที่ต่างกันจะใส่ไฟล์ลงในไดเรกทอรีที่ต่างกัน เช่น เพื่อปรับปรุงอัตราการค้นพบแคชสำหรับบิลด์ที่เปลี่ยนแปลงไฟล์เอาต์พุตซึ่งกันและกัน หรือเก็บไฟล์เอาต์พุตไว้เพื่อการเปรียบเทียบ

--default_visibility=(private|public)

แฟล็กชั่วคราวสำหรับการทดสอบการเปลี่ยนแปลงระดับการเข้าถึงเริ่มต้นของ bazel ไม่ได้มีไว้เพื่อการใช้งานทั่วไป แต่มีการบันทึกเพื่อความครบถ้วนสมบูรณ์

--starlark_cpu_profile=_file_

แฟล็กนี้ซึ่งมีค่าของชื่อไฟล์ทำให้ Bazel รวบรวมสถิติเกี่ยวกับการใช้งาน CPU ของเทรด Starlark ทั้งหมดและเขียนโปรไฟล์ลงในไฟล์ที่มีชื่อในรูปแบบ pprof

ใช้ตัวเลือกนี้เพื่อช่วยระบุฟังก์ชัน Starlark ที่ทำให้การโหลดและการวิเคราะห์ช้าเนื่องจากมีการคำนวณมากเกินไป เช่น

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

หากต้องการดูข้อมูลเดียวกันในมุมมองต่างๆ ลองใช้คำสั่ง pprof svg, web และ list

การใช้ Bazel สำหรับรุ่นต่างๆ

Bazel มีการใช้งานทั้งโดยวิศวกรซอฟต์แวร์ในระหว่างรอบการพัฒนา และโดยวิศวกรที่เปิดตัวขณะเตรียมไบนารีสำหรับการติดตั้งใช้งานจริง ส่วนนี้จะแสดงรายการเคล็ดลับ สำหรับวิศวกรการเผยแพร่โดยใช้ Bazel

ตัวเลือกสำคัญ

เมื่อใช้ Bazel สำหรับบิลด์ที่เผยแพร่ จะเกิดปัญหาเดียวกันกับสคริปต์อื่นๆ ที่ดำเนินการบิลด์ โปรดดูรายละเอียดเพิ่มเติมที่หัวข้อโทรหา Bazel จากสคริปต์ โดยเฉพาะอย่างยิ่ง เราขอแนะนำ เป็นอย่างยิ่งว่าตัวเลือกดังต่อไปนี้

• --bazelrc=/dev/null
• --nokeep_state_after_build

ตัวเลือกเหล่านี้มีความสำคัญเช่นกัน:

• --package_path
• --symlink_prefix: สำหรับการจัดการบิลด์สำหรับการกำหนดค่าหลายรายการ การแยกความแตกต่างของแต่ละบิลด์ด้วยตัวระบุที่แตกต่างกัน เช่น "64 บิต" กับ "32 บิต" อาจสะดวก ตัวเลือกนี้ทำให้ลิงก์สัญลักษณ์ bazel-bin (ฯลฯ) แตกต่างกัน

กำลังทดสอบ

หากต้องการสร้างและทำการทดสอบด้วย Bazel ให้พิมพ์ bazel test ตามด้วยชื่อของเป้าหมายทดสอบ

โดยค่าเริ่มต้น คำสั่งนี้จะดำเนินการกับการสร้างและทดสอบพร้อมกัน โดยสร้างเป้าหมายที่ระบุทั้งหมด (รวมทั้งเป้าหมายที่ไม่ใช่การทดสอบที่ระบุในบรรทัดคำสั่ง) และทดสอบเป้าหมาย *_test และ test_suite ทันทีที่ข้อกำหนดเบื้องต้นสร้างขึ้น ซึ่งหมายความว่าการดำเนินการทดสอบจะแทรกสลับกับการสร้าง การทำเช่นนั้นมักจะทำให้ เพิ่มความเร็วได้อย่างมาก

ตัวเลือกสำหรับ bazel test

--cache_test_results=(yes|no|auto) (-t)

หากตั้งค่านโยบายนี้เป็น "อัตโนมัติ" (ค่าเริ่มต้น) Bazel จะทำการทดสอบอีกครั้งก็ต่อเมื่อเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

• Bazel ตรวจพบการเปลี่ยนแปลงในการทดสอบหรือทรัพยากร Dependency
• การทดสอบมีการทำเครื่องหมายเป็น external
• มีการขอทำการทดสอบหลายครั้งด้วย --runs_per_test
• การทดสอบล้มเหลว

หาก "ไม่" การทดสอบทั้งหมดจะดำเนินการอย่างไม่มีเงื่อนไข

หาก "ใช่" ลักษณะการแคชจะเหมือนกับ "อัตโนมัติ" เว้นแต่ว่าระบบอาจแคชการทดสอบที่ไม่สำเร็จและการเรียกใช้การทดสอบด้วย --runs_per_test

หมายเหตุ: ระบบจะบันทึกผลการทดสอบเสมอในผังเอาต์พุตของ Bazel โดยไม่คำนึงถึงว่ามีการเปิดใช้ตัวเลือกนี้หรือไม่ คุณจึงไม่จำเป็นต้องใช้ --cache_test_results ในการเรียกใช้ bazel test ก่อนหน้านี้เพื่อรับ Hit ของแคช ตัวเลือกนี้จะมีผลเฉพาะว่า Bazel จะใช้ผลลัพธ์ที่บันทึกไว้ก่อนหน้านี้หรือไม่ โดยไม่รวมถึงการบันทึกผลลัพธ์ของการเรียกใช้ปัจจุบัน

ผู้ใช้ที่เปิดใช้ตัวเลือกนี้โดยค่าเริ่มต้นในไฟล์ .bazelrc อาจเห็นอักษรย่อ -t (เปิด) หรือ -t- (ปิด) เพื่อความสะดวกในการลบล้างค่าเริ่มต้นในการเรียกใช้แต่ละครั้ง

--check_tests_up_to_date

ตัวเลือกนี้จะบอก Bazel ว่าไม่ต้องทำการทดสอบ แต่ให้ตรวจสอบและรายงานผลการทดสอบที่แคชไว้เท่านั้น หากมีการทดสอบที่ยังไม่ได้สร้างและเรียกใช้ก่อนหน้านี้ หรือผลการทดสอบล้าสมัย (เช่น เนื่องจากซอร์สโค้ดหรือตัวเลือกบิลด์มีการเปลี่ยนแปลง) Bazel จะรายงานข้อความแสดงข้อผิดพลาด ("ผลการทดสอบไม่เป็นปัจจุบัน") จะบันทึกสถานะของการทดสอบเป็น "ไม่มีสถานะ" (เป็นสีแดง หากมีการเปิดใช้เอาต์พุตสี) และจะแสดงผลโค้ดที่ไม่ใช่ 0

ตัวเลือกนี้กล่าวเป็นนัยถึงลักษณะการทำงานของ [--check_up_to_date](#check-up-to-date) ด้วย

ตัวเลือกนี้อาจมีประโยชน์สำหรับเช็คที่ส่งล่วงหน้า

--test_verbose_timeout_warnings

ตัวเลือกนี้จะบอกให้ Bazel เตือนผู้ใช้อย่างชัดแจ้งหากระยะหมดเวลาของการทดสอบนานกว่าเวลาดำเนินการจริงของการทดสอบเป็นอย่างมาก แม้ว่าจะมีการตั้งระยะหมดเวลาของการทดสอบไม่ให้ทำงานไม่สม่ำเสมอ แต่การทดสอบที่มีการหมดเวลามากเกินไปอาจซ่อนปัญหาจริงที่เกิดขึ้นโดยไม่คาดคิดได้

ตัวอย่างเช่น การทดสอบที่ปกติจะใช้เวลา 1-2 นาทีไม่ควรหมดเวลาเป็น ETERNAL หรือ Llong เนื่องจากเป็นการทดสอบที่มากเกินไป

ตัวเลือกนี้จะมีประโยชน์ในการช่วยให้ผู้ใช้ตัดสินใจเลือกค่าระยะหมดเวลาที่เหมาะสมหรือตรวจสอบค่าการหมดเวลาที่มีอยู่ได้อย่างถูกต้อง

หมายเหตุ: ชาร์ดทดสอบแต่ละรายการจะได้รับการจัดสรรระยะหมดเวลาของเป้าหมาย XX_test ทั้งหมด การใช้ตัวเลือกนี้จะไม่ส่งผลต่อค่าระยะหมดเวลาของการทดสอบ เพียงเตือนหาก Bazel คิดว่าอาจจำกัดระยะหมดเวลาเพิ่มเติม

--[no]test_keep_going

โดยค่าเริ่มต้น การทดสอบทั้งหมดจะดำเนินการจนเสร็จสิ้น อย่างไรก็ตาม หากปิดใช้แฟล็กนี้ ระบบจะล้มเลิกบิลด์ในการทดสอบที่ไม่ผ่าน ขั้นตอนบิลด์ที่ตามมาและการเรียกใช้การทดสอบจะไม่ทำงาน และการเรียกใช้ที่อยู่ระหว่างดำเนินการจะถูกยกเลิก อย่าระบุทั้ง --notest_keep_going และ --keep_going

--flaky_test_attempts=attempts

ตัวเลือกนี้จะระบุจำนวนครั้งสูงสุดที่ควรพยายามทำการทดสอบหากไม่สำเร็จไม่ว่าด้วยเหตุผลใดก็ตาม การทดสอบที่ล้มเหลวในตอนแรกแต่ประสบความสำเร็จในที่สุดจะรายงานเป็น FLAKY ในสรุปการทดสอบ แต่จะถือว่ามีการส่งผ่านเมื่อต้องระบุรหัสการออกของ Bazel หรือจำนวนการทดสอบที่ผ่านทั้งหมด การทดสอบที่ล้มเหลวทั้งหมดจะถือว่า ไม่ผ่าน

โดยค่าเริ่มต้น (เมื่อไม่ได้ระบุตัวเลือกนี้หรือเมื่อตั้งเป็นค่าเริ่มต้น) จะอนุญาตเฉพาะการทดสอบปกติเพียงครั้งเดียว และ 3 ครั้งสำหรับกฎการทดสอบที่มีชุดแอตทริบิวต์ flaky คุณระบุค่าจำนวนเต็มเพื่อลบล้างขีดจำกัดสูงสุดของความพยายามทดสอบได้ Bazel อนุญาตให้ ทดสอบได้ไม่เกิน 10 ครั้งเพื่อป้องกันการละเมิดระบบ

--runs_per_test=[regex@]number

ตัวเลือกนี้จะระบุจำนวนครั้งที่ควรทำการทดสอบแต่ละครั้ง การดำเนินการทดสอบทั้งหมดจะถือว่าเป็นการทดสอบแยกกัน (ฟังก์ชันสำรองจะมีผลกับแต่ละรายการแยกกัน)

สถานะของเป้าหมายที่การเรียกใช้ล้มเหลวขึ้นอยู่กับค่าของ Flag --runs_per_test_detects_flakes ดังนี้

• หากไม่ระบุ การเรียกใช้ที่ล้มเหลวจะทำให้การทดสอบทั้งหมดไม่สำเร็จ
• หากมีการเรียกใช้และการรัน 2 ครั้งจาก PASS และ FAIL เดียวกัน การทดสอบจะได้รับสถานะเป็น ไม่สม่ำเสมอ (เว้นแต่การเรียกใช้ที่ล้มเหลวอื่นๆ จะทำให้การทำงานล้มเหลว)

หากระบุตัวเลขเดียวไว้ การทดสอบทั้งหมดจะทำงานหลายครั้ง หรือจะระบุนิพจน์ทั่วไปโดยใช้ไวยากรณ์ Regex@number ก็ได้ ซึ่งจะจำกัดผลกระทบของ --runs_per_test ต่อเป้าหมายที่ตรงกับนิพจน์ทั่วไป (--runs_per_test=^//pizza:.*@4 เรียกใช้การทดสอบทั้งหมดที่ต่ำกว่า //pizza/ 4 ครั้ง) ระบบอาจระบุแบบฟอร์ม --runs_per_test นี้มากกว่า 1 ครั้ง

--[no]runs_per_test_detects_flakes

หากระบุตัวเลือกนี้ไว้ (โดยค่าเริ่มต้นจะไม่ได้ระบุ) Bazel จะตรวจหาชาร์ดทดสอบที่ไม่สม่ำเสมอผ่าน --runs_per_test ถ้าการเรียกใช้ชาร์ดเดียวล้มเหลวอย่างน้อย 1 ครั้งและการเรียกใช้ชาร์ดพาสเดียวกันอย่างน้อย 1 ครั้ง จะถือว่าเป้าหมายเป็น "ไม่สม่ำเสมอ" ด้วยแฟล็ก หากไม่ระบุ เป้าหมายจะรายงานสถานะ "ไม่ผ่าน"

--test_summary=output_style

ระบุว่าควรแสดงข้อมูลสรุปผลการทดสอบอย่างไร

• short จะพิมพ์ผลการทดสอบแต่ละครั้ง พร้อมกับชื่อไฟล์ที่มีเอาต์พุตทดสอบหากการทดสอบไม่สำเร็จ นี่คือค่าเริ่มต้น
• terse เช่น short แต่มีขนาดสั้นกว่า: พิมพ์เฉพาะข้อมูล เกี่ยวกับการทดสอบที่ไม่ผ่านเท่านั้น
• detailed จะพิมพ์กรอบการทดสอบแต่ละรายการที่ไม่สำเร็จ ไม่ได้พิมพ์เฉพาะการทดสอบแต่ละครั้ง และละเว้นชื่อไฟล์เอาต์พุตทดสอบ
• none ไม่พิมพ์ข้อมูลสรุปการทดสอบ

--test_output=output_style

ระบุวิธีแสดงเอาต์พุตทดสอบ

• summary จะแสดงข้อมูลสรุปว่าการทดสอบแต่ละครั้งผ่านหรือล้มเหลว และแสดงชื่อไฟล์บันทึกเอาต์พุตสำหรับการทดสอบที่ล้มเหลว ข้อมูลสรุปจะพิมพ์เมื่อสิ้นสุดบิลด์ (ระหว่างบิลด์ จะเห็นเพียงข้อความแสดงความคืบหน้าง่ายๆ เมื่อการทดสอบเริ่มต้น ผ่าน หรือไม่ผ่าน) นี่คือลักษณะการทำงานเริ่มต้น
• errors จะส่งเอาต์พุต stdout/stderr ที่รวมไว้จากการทดสอบที่ล้มเหลวไปยัง stdout ทันทีหลังจากการทดสอบเสร็จสิ้นเท่านั้น เพื่อให้มั่นใจว่าเอาต์พุตการทดสอบจากการทดสอบในเวลาเดียวกันไม่มีการแทรกสลับกัน พิมพ์ข้อมูลสรุปที่บิลด์ตามเอาต์พุตสรุปด้านบน
• all คล้ายกับ errors แต่จะพิมพ์ผลลัพธ์สำหรับการทดสอบทั้งหมด รวมถึงการทดสอบที่ผ่าน
• streamed สตรีมเอาต์พุต stdout/stderr จากการทดสอบแต่ละครั้งแบบเรียลไทม์

--java_debug

ตัวเลือกนี้จะทำให้เครื่องเสมือนของ Java ของการทดสอบ Java ต้องรอการเชื่อมต่อจากโปรแกรมแก้ไขข้อบกพร่องที่สอดคล้องกับ JDWP ก่อนเริ่มการทดสอบ ตัวเลือกนี้หมายถึง --test_output=streamed

--[no]verbose_test_summary

ระบบจะเปิดใช้ตัวเลือกนี้โดยค่าเริ่มต้น ซึ่งจะทําให้เวลาทดสอบและข้อมูลเพิ่มเติมอื่นๆ (เช่น ความพยายามในการทดสอบ) พิมพ์ไปยังสรุปการทดสอบ หากระบุ --noverbose_test_summary สรุปการทดสอบจะรวมเฉพาะชื่อการทดสอบ สถานะการทดสอบ และตัวบ่งชี้การทดสอบที่แคชไว้ และจะจัดรูปแบบให้มีอักขระไม่เกิน 80 ตัวเมื่อเป็นไปได้

--test_tmpdir=path

ระบุไดเรกทอรีชั่วคราวสำหรับการทดสอบที่ดำเนินการในเครื่อง การทดสอบแต่ละรายการจะดำเนินการในไดเรกทอรีย่อยที่แยกต่างหากภายในไดเรกทอรีนี้ ระบบจะล้างไดเรกทอรีในช่วงต้นของคำสั่ง bazel test แต่ละรายการ โดยค่าเริ่มต้น bazel จะวางไดเรกทอรีนี้ภายใต้ไดเรกทอรีฐานเอาต์พุต Bazel

หมายเหตุ: นี่คือไดเรกทอรีสำหรับการเรียกใช้การทดสอบ ไม่ใช่การจัดเก็บผลการทดสอบ (ระบบจะเก็บข้อมูลเหล่านี้ไว้ในไดเรกทอรี bazel-out เสมอ)

--test_timeout=seconds หรือ --test_timeout=seconds,seconds,seconds,seconds

ลบล้างค่าระยะหมดเวลาสำหรับการทดสอบทั้งหมดโดยใช้จำนวนวินาทีที่ระบุเป็นค่าการหมดเวลาใหม่ หากระบุเพียงค่าเดียว ระบบจะใช้ค่านั้นกับหมวดหมู่ระยะหมดเวลาทดสอบทั้งหมด

หรือคุณอาจระบุค่าที่คั่นด้วยเครื่องหมายจุลภาค 4 ค่า ซึ่งระบุระยะหมดเวลาแต่ละรายการสำหรับการทดสอบสั้น ปานกลาง ยาว และถาวร (ตามลำดับ) ไม่ว่าจะเป็นรูปแบบใด ค่า 0 หรือค่าลบของขนาดทดสอบใดก็ตามจะถูกแทนที่โดยค่าระยะหมดเวลาเริ่มต้นสำหรับหมวดหมู่การหมดเวลาที่ระบุโดยหน้าการเขียนการทดสอบ โดยค่าเริ่มต้น Bazel จะใช้การหมดเวลาเหล่านี้สำหรับการทดสอบทั้งหมดโดยอนุมานขีดจำกัดการหมดเวลาจากขนาดของการทดสอบว่ากำหนดขนาดไว้อย่างชัดแจ้งหรืออย่างชัดแจ้ง

การทดสอบที่ระบุหมวดหมู่ระยะหมดเวลาไว้อย่างชัดแจ้งว่าแตกต่างจากขนาดจะได้รับค่าเดียวกันกับในกรณีที่แท็กขนาดมีการตั้งค่าการหมดเวลานั้นโดยปริยาย ดังนั้น การทดสอบขนาด "เล็ก" ซึ่งแจ้งว่าระยะหมดเวลา "นาน" จะมีระยะหมดเวลาที่มีประสิทธิภาพเท่ากับที่การทดสอบ "ขนาดใหญ่" ไม่มีระยะหมดเวลาที่ชัดเจน

--test_arg=arg

ส่งตัวเลือก/แฟล็ก/อาร์กิวเมนต์บรรทัดคำสั่งไปยังกระบวนการทดสอบแต่ละรายการ คุณใช้ตัวเลือกนี้ได้หลายครั้งเพื่อส่งผ่านอาร์กิวเมนต์หลายตัว ตัวอย่างเช่น --test_arg=--logtostderr --test_arg=--v=3

--test_env=variable=_value_ หรือ --test_env=variable

ระบุตัวแปรเพิ่มเติมที่ต้องแทรกลงในสภาพแวดล้อมการทดสอบสำหรับการทดสอบแต่ละครั้ง หากไม่ได้ระบุ value จะรับค่าจากสภาพแวดล้อม Shell ที่ใช้ในการเริ่มต้นคำสั่ง bazel test

คุณสามารถเข้าถึงสภาพแวดล้อมนี้ได้จากภายในการทดสอบโดยใช้ System.getenv("var") (Java), getenv("var") (C หรือ C++)

--run_under=command-prefix

การดำเนินการนี้จะระบุคำนำหน้าที่ตัวดำเนินการทดสอบจะแทรกไว้ด้านหน้าคำสั่งทดสอบก่อนเรียกใช้ ระบบจะแยก command-prefix ออกเป็นคำโดยใช้กฎโทเค็นเชลล์ของ Bourne จากนั้นจะมีการเติมรายการคำไว้หน้าคำสั่งที่จะดำเนินการ

หากคำแรกเป็นป้ายกำกับที่มีคุณสมบัติครบถ้วน (ขึ้นต้นด้วย //) ระบบจะสร้างป้ายกำกับขึ้น จากนั้นป้ายกำกับจะแทนที่ด้วยตำแหน่งปฏิบัติการที่เกี่ยวข้องซึ่งใส่ไว้ด้านหน้าคำสั่งที่จะดำเนินการพร้อมกับคำอื่นๆ

มีข้อควรระวังบางประการดังนี้

• PATH ที่ใช้สำหรับการทดสอบอาจแตกต่างจาก PATH ในสภาพแวดล้อมของคุณ คุณจึงอาจต้องใช้ เส้นทางสัมบูรณ์ สำหรับคำสั่ง --run_under (คำแรกใน command-prefix)
• stdin ไม่ได้เชื่อมต่อ จึงใช้ --run_under สำหรับคำสั่งแบบอินเทอร์แอกทีฟไม่ได้

ตัวอย่าง

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

การเลือกการทดสอบ

ตามที่ระบุไว้ในตัวเลือกการเลือกเอาต์พุต คุณจะกรองการทดสอบตามขนาด ระยะหมดเวลา แท็ก หรือภาษาได้ ตัวกรองชื่อทั่วไปเพื่อความสะดวกสามารถส่งต่ออาร์กิวเมนต์ตัวกรองเฉพาะไปยังตัวดำเนินการทดสอบได้

ตัวเลือกอื่นๆ สำหรับ bazel test

ไวยากรณ์และตัวเลือกที่เหลือจะเหมือนกับ bazel build ทุกประการ

กำลังเรียกใช้ไฟล์ปฏิบัติการ

คำสั่ง bazel run คล้ายกับ bazel build แต่จะใช้เพื่อสร้างและเรียกใช้เป้าหมายเดียว เซสชันทั่วไปมีดังนี้

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

หมายเหตุ: จำเป็นต้องมี -- เพื่อให้ Bazel ไม่ตีความ --arg1 และ --arg2 เป็น ตัวเลือก Bazel แต่ให้เป็นส่วนหนึ่งของบรรทัดคำสั่งในการเรียกใช้ไบนารี (โปรแกรมที่เรียกใช้อยู่เพียงแค่กล่าวสวัสดีและพิมพ์คำถามออกมา)

bazel run มีความคล้ายคลึงแต่ก็ไม่เหมือนกัน กล่าวคือการเรียกใช้ไบนารีที่ Bazel สร้างขึ้นโดยตรงและลักษณะการทำงานจะแตกต่างกันไป โดยขึ้นอยู่กับว่าไบนารีที่จะเรียกใช้เป็นการทดสอบหรือไม่

เมื่อไบนารีไม่ใช่การทดสอบ ไดเรกทอรีที่ใช้งานอยู่ปัจจุบันจะเป็นแผนผัง Runfiles ของไบนารี

เมื่อไบนารีเป็นการทดสอบ ไดเรกทอรีที่ใช้งานอยู่ในปัจจุบันจะเป็นรูทการดำเนินการและพยายามโดยสุจริตเพื่อจำลองการทดสอบสภาพแวดล้อม อย่างไรก็ตาม การจำลองนี้ไม่สมบูรณ์แบบ และการทดสอบที่มีชาร์ดหลายรายการจะทำงานด้วยวิธีนี้ไม่ได้ (ใช้ตัวเลือกบรรทัดคำสั่ง --test_sharding_strategy=disabled เพื่อแก้ปัญหานี้ได้)

ไบนารีนั้นยังมีตัวแปรสภาพแวดล้อมเพิ่มเติมต่อไปนี้อีกด้วย

• BUILD_WORKSPACE_DIRECTORY: รูทของพื้นที่ทำงานที่มีการเรียกใช้บิลด์
• BUILD_WORKING_DIRECTORY: ไดเรกทอรีการทำงานปัจจุบันที่เรียกใช้ Bazel

ตัวอย่างเช่น เครื่องมือเหล่านี้สามารถใช้เพื่อตีความชื่อไฟล์ในบรรทัดคำสั่งในลักษณะที่ใช้งานง่าย

ตัวเลือกสำหรับ bazel run

--run_under=command-prefix

ซึ่งจะมีผลเหมือนกับตัวเลือก --run_under สำหรับ bazel test (ดูด้านบน) เว้นแต่จะมีผลกับคำสั่งที่เรียกใช้โดย bazel run แทนที่จะเป็นการทดสอบที่เรียกใช้โดย bazel test และไม่สามารถเรียกใช้ภายใต้ป้ายกำกับ

การกรองเอาต์พุตของการบันทึกจาก Bazel

เมื่อเรียกใช้ไบนารีด้วย bazel run Bazel จะพิมพ์เอาต์พุตการบันทึกจาก Bazel เองและไบนารีที่อยู่ภายใต้การเรียกใช้ หากต้องการลดเสียงรบกวนของบันทึก คุณสามารถระงับเอาต์พุตจาก Bazel ได้โดยใช้แฟล็ก --ui_event_filters และ --noshow_progress

ตัวอย่างเช่น bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

การดำเนินการทดสอบ

bazel run ยังดำเนินการกับไบนารีการทดสอบได้ด้วย ซึ่งจะส่งผลจากการทดสอบในที่ใกล้เคียงกับสภาพแวดล้อมตามที่อธิบายไว้ในการเขียนการทดสอบ โปรดทราบว่าไม่มีอาร์กิวเมนต์ --test_* ที่มีผลกระทบเมื่อเรียกใช้การทดสอบในลักษณะนี้ ยกเว้น --test_arg

กำลังทำความสะอาดเอาต์พุตของบิลด์

คำสั่ง clean

Bazel มีคำสั่ง clean ซึ่งคล้ายกับคำสั่งของ Make โดยจะลบไดเรกทอรีเอาต์พุตสำหรับการกำหนดค่าบิลด์ทั้งหมดที่ดำเนินการโดยอินสแตนซ์ Bazel นี้ หรือโครงสร้างการทำงานทั้งหมดที่สร้างขึ้นโดยอินสแตนซ์ Bazel นี้และรีเซ็ตแคชภายใน หากดำเนินการโดยไม่มีตัวเลือกบรรทัดคำสั่ง ระบบจะล้างไดเรกทอรีเอาต์พุตสำหรับการกำหนดค่าทั้งหมด

โปรดจำว่าอินสแตนซ์ Bazel แต่ละรายการเชื่อมโยงกับพื้นที่ทำงานเดียว ดังนั้นคำสั่ง clean จะลบเอาต์พุตทั้งหมดออกจากบิลด์ทั้งหมดที่คุณทำกับอินสแตนซ์ Bazel ดังกล่าวในพื้นที่ทำงานนั้น

หากต้องการนำโครงสร้างการทำงานทั้งหมดที่สร้างโดยอินสแตนซ์ Bazel ออก ให้ระบุตัวเลือก --expunge เมื่อเรียกใช้ด้วย --expunge คำสั่ง "ล้าง" จะนำออก Base Tree ของเอาต์พุตทั้งหมดออก ซึ่งนอกจากเอาต์พุตของบิลด์แล้ว ยังมีไฟล์อุณหภูมิทั้งหมดที่สร้างโดย Bazel ด้วย นอกจากนี้ ยังหยุดเซิร์ฟเวอร์ Bazel หลังล้างไฟล์ ซึ่งเทียบเท่ากับคำสั่ง shutdown เช่น หากต้องการล้างดิสก์และการติดตามหน่วยความจำทั้งหมดของอินสแตนซ์ Bazel คุณอาจระบุสิ่งต่อไปนี้

  % bazel clean --expunge

หรือคุณจะล้างข้อมูลในเบื้องหลังโดยใช้ --expunge_async ก็ได้ คุณสามารถเรียกใช้คำสั่ง Bazel ในไคลเอ็นต์เดียวกันขณะที่การล้างข้อมูลแบบอะซิงโครนัสยังคงทำงานต่อไป

หมายเหตุ: การทำเช่นนี้อาจทำให้เกิดการช่วงชิง IO

คำสั่ง clean มีไว้เพื่อใช้ในการเรียกคืนพื้นที่ในดิสก์สำหรับพื้นที่ทำงานที่ไม่จำเป็นต้องใช้อีกต่อไปเป็นหลัก การสร้างใหม่ที่เพิ่มขึ้นของ Bazel อาจไม่สมบูรณ์แบบ ดังนั้นสามารถใช้ clean เพื่อกู้คืนสถานะที่สอดคล้องกันเมื่อเกิดปัญหาได้

การออกแบบของ Bazel นั้นทำให้ปัญหาเหล่านี้แก้ไขได้และข้อบกพร่องเหล่านี้มีความสำคัญอย่างยิ่งที่ต้องแก้ไข หากพบบิลด์ที่เพิ่มขึ้นที่ไม่ถูกต้อง ให้ส่งรายงานข้อบกพร่องและรายงานข้อบกพร่องในเครื่องมือแทนการใช้ clean

การค้นหากราฟทรัพยากร Dependency

Bazel ใช้ภาษาคำค้นหาสำหรับถามคำถามเกี่ยวกับกราฟการขึ้นต่อกันที่ใช้ระหว่างบิลด์ ภาษาในการค้นหาจะใช้โดย คำสั่ง 2 คำสั่ง คือ ข้อความค้นหา และ cquery ความแตกต่างที่สำคัญระหว่างคำสั่งทั้ง 2 อย่างคือ คำสั่งจะทำงานหลังจากเฟสการโหลด และคำสั่ง cquery จะทำงานหลังจากระยะการวิเคราะห์ เครื่องมือเหล่านี้มีประโยชน์อย่างยิ่งต่องานด้านวิศวกรรมซอฟต์แวร์มากมาย

ภาษาที่ใช้ค้นหานี้อาศัยแนวคิด เกี่ยวกับการดำเนินการพีชคณิตผ่านกราฟ โดยอธิบายไว้อย่างละเอียดใน

ข้อมูลอ้างอิงคำค้นหาของบาเซล โปรดดูเอกสารดังกล่าวเพื่อเป็นตัวอย่างและสำหรับตัวเลือกบรรทัดคำสั่งเฉพาะคำค้นหา

เครื่องมือ Query ยอมรับตัวเลือกบรรทัดคำสั่งหลายรายการ --output เลือกรูปแบบเอาต์พุต --[no]keep_going (ปิดใช้โดยค่าเริ่มต้น) จะทำให้เครื่องมือค้นหาทำงานต่อเมื่อเกิดข้อผิดพลาด ระบบอาจปิดใช้ลักษณะการทำงานนี้หากผลลัพธ์ไม่สมบูรณ์ในกรณีที่เกิดข้อผิดพลาด

ตัวเลือก --[no]tool_deps ที่เปิดใช้โดยค่าเริ่มต้นจะทำให้ทรัพยากร Dependency ในการกำหนดค่าที่ไม่ใช่เป้าหมายรวมอยู่ในกราฟทรัพยากร Dependency ที่การค้นหาทำงาน

ตัวเลือก --[no]implicit_deps ที่เปิดใช้โดยค่าเริ่มต้นจะทำให้การรวมทรัพยากร Dependency แบบโดยนัยไว้ในกราฟทรัพยากร Dependency ที่การค้นหาทำงาน Dependency โดยนัยคือทรัพยากรที่ไม่ได้ระบุไว้อย่างชัดเจนในไฟล์ "BUILD" แต่เพิ่มโดย Bazel

ตัวอย่างเช่น "แสดงตำแหน่งของคำจำกัดความ (ในไฟล์ BUILD) ของกฎ Gen ทั้งหมดที่จำเป็นในการสร้างการทดสอบทั้งหมดในทรี PEBL"

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

การค้นหากราฟการดำเนินการ

ข้อควรระวัง: คำสั่ง aquery ยังอยู่ระหว่างการทดสอบและ API จะมีการเปลี่ยนแปลง

คำสั่ง aquery ช่วยให้คุณค้นหาการดำเนินการในกราฟบิลด์ได้ โดยจะดำเนินการกับกราฟเป้าหมายที่กำหนดค่าหลังการวิเคราะห์ และแสดงข้อมูลการกระทำ อาร์ติแฟกต์ และความสัมพันธ์ของวัตถุเหล่านั้น

เครื่องมือยอมรับตัวเลือกบรรทัดคำสั่งหลายรายการ --output เลือกรูปแบบเอาต์พุต รูปแบบเอาต์พุตเริ่มต้น (text) ที่มนุษย์อ่านได้ ให้ใช้ proto หรือ textproto สำหรับรูปแบบที่เครื่องอ่านได้ สิ่งที่ควรทราบคือคำสั่ง aquery จะทำงานที่ด้านบนของบิลด์ Bazel ปกติและรับค่าชุดตัวเลือกที่มีให้ระหว่างบิลด์

โดยรองรับฟังก์ชันชุดเดียวกันกับที่มีให้ใน query ดั้งเดิม แต่รองรับ siblings, buildfiles และ tests

ดูรายละเอียดเพิ่มเติมได้ที่ข้อความค้นหากราฟการดำเนินการ

คำสั่งและตัวเลือกเบ็ดเตล็ด

help

คําสั่ง help จะให้ความช่วยเหลือทางออนไลน์ โดยค่าเริ่มต้น ข้อมูลนี้จะแสดงสรุปคำสั่งและหัวข้อความช่วยเหลือที่ใช้ได้ ดังที่แสดงในการสร้างด้วย Bazel การระบุอาร์กิวเมนต์จะแสดงความช่วยเหลือโดยละเอียดสำหรับหัวข้อหนึ่งๆ หัวข้อส่วนใหญ่เป็นคำสั่งของ Bazel เช่น build หรือ query แต่มีหัวข้อความช่วยเหลือเพิ่มเติมบางอย่างที่ไม่ตรงกับคำสั่ง

--[no]long (-l)

โดยค่าเริ่มต้น bazel help [topic] จะพิมพ์เฉพาะสรุปตัวเลือกที่เกี่ยวข้องสำหรับหัวข้อหนึ่งๆ หากระบุตัวเลือก --long ระบบจะพิมพ์ประเภท ค่าเริ่มต้น และคำอธิบายแบบเต็มของแต่ละตัวเลือกด้วย

shutdown

กระบวนการของเซิร์ฟเวอร์ Bazel อาจหยุดได้โดยใช้คำสั่ง shutdown คำสั่งนี้จะทำให้เซิร์ฟเวอร์ Bazel ออกทันทีที่ไม่มีการใช้งาน (ตัวอย่างเช่น หลังจากบิลด์หรือคำสั่งอื่นๆ ที่กำลังดำเนินการเสร็จสมบูรณ์แล้ว) ดูรายละเอียดเพิ่มเติมได้ที่การใช้งานไคลเอ็นต์/เซิร์ฟเวอร์

เซิร์ฟเวอร์ Bazel จะหยุดตัวเองหลังจากหมดเวลาเนื่องจากไม่มีการใช้งาน จึงแทบไม่จำเป็นต้องใช้คำสั่งนี้ อย่างไรก็ตาม คำสั่งนี้จะมีประโยชน์ในสคริปต์เมื่อทราบว่าจะไม่มีบิลด์เพิ่มเติมเกิดขึ้นในพื้นที่ทำงานที่ระบุ

shutdown ยอมรับตัวเลือก --iff_heap_size_greater_than _n_ 1 รายการ ซึ่งต้องใช้อาร์กิวเมนต์จำนวนเต็ม (เป็น MB) หากระบุ จะเป็นการปิดเงื่อนไข ตามจำนวนหน่วยความจำที่ใช้ไปแล้ว วิธีนี้เป็นประโยชน์สำหรับสคริปต์ที่เริ่มต้นบิลด์จำนวนมาก เนื่องจากหน่วยความจำที่รั่วไหลในเซิร์ฟเวอร์ Bazel อาจทำให้เซิร์ฟเวอร์ขัดข้องในบางครั้ง การรีสตาร์ทแบบมีเงื่อนไขจะป้องกันเงื่อนไขนี้

info

คำสั่ง info จะพิมพ์ค่าต่างๆ ที่เชื่อมโยงกับอินสแตนซ์เซิร์ฟเวอร์ Bazel หรือการกำหนดค่าบิลด์ที่เฉพาะเจาะจง (อาจใช้โดยสคริปต์ที่ขับเคลื่อนบิลด์)

คำสั่ง info ยังใช้อาร์กิวเมนต์ (ไม่บังคับ) เพียงรายการเดียว ซึ่งเป็นชื่อของคีย์ใดคีย์หนึ่งในรายการด้านล่าง ในกรณีนี้ bazel info key จะพิมพ์เฉพาะค่าของคีย์ดังกล่าว (ซึ่งสะดวกอย่างยิ่งเมื่อเขียนสคริปต์ Bazel เนื่องจากจะทำให้ไม่จำเป็นต้องเชื่อมต่อผลลัพธ์ผ่าน sed -ne /key:/s/key://p:

ข้อมูลที่ขึ้นอยู่กับการกําหนดค่า

• release: ป้ายกำกับรุ่นสำหรับอินสแตนซ์ Bazel นี้ หรือ "เวอร์ชันพัฒนา" หากไม่ใช่ไบนารีที่ปล่อยแล้ว
• workspaceเส้นทางสัมบูรณ์ไปยังไดเรกทอรีพื้นที่ทำงานฐาน

• install_base: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีการติดตั้งที่อินสแตนซ์ Bazel นี้ใช้สำหรับผู้ใช้ปัจจุบัน Bazel ติดตั้งไฟล์ปฏิบัติการที่จำเป็นภายในใต้ไดเรกทอรีนี้

• output_base: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีเอาต์พุตฐานที่อินสแตนซ์ Bazel นี้ใช้สำหรับชุดค่าผสมของผู้ใช้และพื้นที่ทำงานปัจจุบัน Bazel วาง Scratch และเอาต์พุตบิลด์ทั้งหมดไว้ใต้ไดเรกทอรีนี้

• execution_root: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีรูทของการดำเนินการภายใต้ exit_base ไดเรกทอรีนี้เป็นรูทของไฟล์ทั้งหมดที่เข้าถึงได้คำสั่งที่ดำเนินการระหว่างบิลด์ และเป็นไดเรกทอรีการทำงานสำหรับคำสั่งเหล่านั้น หากไดเรกทอรีพื้นที่ทำงานเขียนได้ ระบบจะวางลิงก์สัญลักษณ์ชื่อ bazel-<workspace> ในไดเรกทอรีนี้

• output_path: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีเอาต์พุตภายใต้รูทการดำเนินการที่ใช้สำหรับไฟล์ทั้งหมดที่สร้างขึ้นจริงซึ่งเป็นผลมาจากคำสั่งบิลด์ หากไดเรกทอรีพื้นที่ทำงานเขียนได้ ระบบจะวางลิงก์สัญลักษณ์ชื่อ bazel-out ในไดเรกทอรีนี้

• server_pid: รหัสกระบวนการของเซิร์ฟเวอร์ Bazel

• server_log: เส้นทางสัมบูรณ์ไปยังไฟล์บันทึกการแก้ไขข้อบกพร่องของเซิร์ฟเวอร์ Bazel ไฟล์นี้มีข้อมูลการแก้ไขข้อบกพร่องของคำสั่งทั้งหมดตลอดอายุการใช้งานของเซิร์ฟเวอร์ Bazel ซึ่งมีไว้สำหรับการใช้งานของมนุษย์โดยนักพัฒนาและผู้ใช้ขั้นสูงของ Bazel

• command_log: เส้นทางสัมบูรณ์ไปยังไฟล์บันทึกคำสั่ง ซึ่งมีสตรีม Stderr และ Stdout ที่มีการแทรกสลับของคำสั่ง Bazel ล่าสุด โปรดทราบว่าการเรียกใช้ bazel info จะเขียนทับเนื้อหาของไฟล์นี้ ซึ่งจะกลายเป็นคำสั่ง Bazel ล่าสุด แต่ตำแหน่งของไฟล์บันทึกคำสั่งจะไม่เปลี่ยนแปลง เว้นแต่ว่าคุณจะเปลี่ยนการตั้งค่าของตัวเลือก --output_base หรือ --output_user_root

• used-heap-size, committed-heap-size, max-heap-size: รายงานพารามิเตอร์ขนาดฮีป JVM ต่างๆ ให้สอดคล้องกัน: หน่วยความจำที่ใช้อยู่ในปัจจุบัน หน่วยความจำที่ปัจจุบันได้รับการรับประกันว่าพร้อมใช้งานสำหรับ JVM จากระบบ และการจัดสรรที่เป็นไปได้สูงสุด

• gc-count, gc-time: จำนวนสะสมของคอลเล็กชันขยะนับตั้งแต่เริ่มต้นของเซิร์ฟเวอร์ Bazel นี้และเวลาที่ใช้ในการดำเนินการ โปรดทราบว่าระบบจะไม่รีเซ็ตค่าเหล่านี้เมื่อเริ่มต้นทุกบิลด์

• package_path: รายการเส้นทางที่คั่นด้วยโคลอน ซึ่งจะมีการค้นหาแพ็กเกจโดยใช้ bazel มีรูปแบบเดียวกับอาร์กิวเมนต์บรรทัดคำสั่งของบิลด์ --package_path

ตัวอย่าง: รหัสกระบวนการของเซิร์ฟเวอร์ Bazel

% bazel info server_pid
1285

ข้อมูลเฉพาะสำหรับการกำหนดค่า

ข้อมูลเหล่านี้อาจได้รับผลกระทบจากตัวเลือกการกำหนดค่าที่ส่งผ่านไปยัง bazel info เช่น --cpu, --compilation_mode เป็นต้น คำสั่ง info จะยอมรับตัวเลือกทั้งหมดที่ควบคุมการวิเคราะห์ทรัพยากร Dependency เนื่องจากตัวเลือกเหล่านี้จะกำหนดตำแหน่งของไดเรกทอรีเอาต์พุตของบิลด์ ทางเลือกของคอมไพเลอร์ ฯลฯ

• bazel-bin, bazel-testlogs, bazel-genfiles: รายงานเส้นทางสัมบูรณ์ไปยังไดเรกทอรี bazel-* ซึ่งมีโปรแกรมที่บิลด์สร้างขึ้น ซึ่งโดยปกติแล้วมักจะไม่เหมือนกับลิงก์สัญลักษณ์ bazel-* ที่สร้างขึ้นในไดเรกทอรีพื้นที่ทํางานพื้นฐานหลังจากบิลด์ที่สําเร็จ อย่างไรก็ตาม หากไดเรกทอรีพื้นที่ทำงานเป็นแบบอ่านอย่างเดียว คุณจะสร้างลิงก์สัญลักษณ์ bazel-* ไม่ได้ สคริปต์ที่ใช้ค่าที่ bazel info รายงานแทนที่จะสันนิษฐานว่ามีลิงก์สัญลักษณ์อยู่จะมีประสิทธิภาพมากขึ้น
• สภาพแวดล้อม"ผู้ผลิต" ที่สมบูรณ์ หากระบุแฟล็ก --show_make_env ตัวแปรทั้งหมดในสภาพแวดล้อม "Make" ของการกำหนดค่าปัจจุบันจะแสดงด้วย (เช่น CC, GLIBC_VERSION ฯลฯ) ตัวแปรเหล่านี้เป็นตัวแปรที่เข้าถึงโดยใช้ไวยากรณ์ $(CC) หรือ varref("CC") ภายในไฟล์ BUILD

ตัวอย่าง: คอมไพเลอร์ C++ สำหรับการกำหนดค่าปัจจุบัน นี่เป็นตัวแปร $(CC) ในสภาพแวดล้อม "Make" จึงจำเป็นต้องมีแฟล็ก --show_make_env

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

เช่น ไดเรกทอรีเอาต์พุต bazel-bin สำหรับการกำหนดค่าปัจจุบัน วิธีนี้รับประกันว่าถูกต้อง แม้ในกรณีที่สร้างลิงก์สัญลักษณ์ bazel-bin ไม่ได้ด้วยเหตุผลบางอย่าง (เช่น หากคุณสร้างจากไดเรกทอรีแบบอ่านอย่างเดียว)

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

versionและ--version

คำสั่งเวอร์ชันจะพิมพ์รายละเอียดเวอร์ชันเกี่ยวกับไบนารี Bazel ที่สร้างขึ้น รวมถึงรายการการเปลี่ยนแปลงที่ใช้สร้างเวอร์ชันและวันที่ ข้อมูลเหล่านี้มีประโยชน์มากในการพิจารณาว่าคุณใช้ Bazel ล่าสุดไหมหรือกำลังรายงานข้อบกพร่อง ตัวอย่างค่าที่น่าสนใจมีดังนี้

• changelist: รายการเปลี่ยนแปลงที่มีการเผยแพร่ Bazel เวอร์ชันนี้
• label: ป้ายกำกับรุ่นสำหรับอินสแตนซ์ Bazel นี้ หรือ "เวอร์ชันพัฒนา" หากไม่ใช่ไบนารีที่ปล่อยแล้ว มีประโยชน์มากเมื่อรายงานข้อบกพร่อง

bazel --version โดยไม่มีอาร์กิวเมนต์อื่นๆ จะส่งเอาต์พุตเหมือนกับ bazel version --gnu_format เว้นแต่จะได้รับผลข้างเคียงจากการเปิดเซิร์ฟเวอร์ Bazel หรือคลายการแพคข้อมูลที่เก็บถาวรของเซิร์ฟเวอร์ เรียกใช้ bazel --version ได้จากทุกที่และไม่ต้องใช้ไดเรกทอรีพื้นที่ทำงาน

mobile-install

คำสั่ง mobile-install จะติดตั้งแอปลงในอุปกรณ์เคลื่อนที่ ปัจจุบันรองรับเฉพาะอุปกรณ์ Android ที่ใช้ ART

โปรดดูข้อมูลเพิ่มเติมที่การติดตั้ง Bazel สำหรับอุปกรณ์เคลื่อนที่

หมายเหตุ: คำสั่งนี้จะไม่ติดตั้งสิ่งเดียวกับที่ bazel build สร้างขึ้น โดย Bazel จะปรับแต่งแอปเพื่อให้สร้าง ติดตั้ง และติดตั้งอีกครั้งได้อย่างรวดเร็ว อย่างไรก็ตาม ส่วนนี้ควรโปร่งใส กับแอปเป็นส่วนใหญ่

ระบบรองรับตัวเลือกต่อไปนี้

--incremental

หากตั้งค่า Bazel จะพยายามติดตั้งแอปทีละส่วน กล่าวคือ เฉพาะส่วนที่มีการเปลี่ยนแปลงนับจากบิลด์ล่าสุดเท่านั้น การดำเนินการนี้ไม่สามารถอัปเดตทรัพยากรที่อ้างอิงจาก AndroidManifest.xml โค้ดแบบเนทีฟ หรือทรัพยากรของ Java (เช่น ทรัพยากรที่อ้างอิงโดย Class.getResource()) หากสิ่งเหล่านี้มีการเปลี่ยนแปลง คุณต้องละเว้นตัวเลือกนี้ ตรงข้ามกับเจตนารมณ์ของ Bazel และเพราะข้อจำกัดด้านแพลตฟอร์ม Android คุณต้องความรับผิดชอบของผู้ใช้ที่จะทราบว่าคำสั่งนี้ดีพอเมื่อใดและเมื่อใดที่จำเป็นต้องติดตั้งอย่างสมบูรณ์

หากคุณใช้อุปกรณ์ที่มี Marshmallow ขึ้นไป ให้พิจารณา Flag --split_apks

--split_apks

ต้องการใช้ APK แยกเพื่อติดตั้งและอัปเดตแอปพลิเคชันในอุปกรณ์หรือไม่ ใช้งานได้กับอุปกรณ์ที่ใช้ Marshmallow ขึ้นไปเท่านั้น โปรดทราบว่าไม่จําเป็นต้องแฟล็ก --incremental เมื่อใช้ --split_apks

--start_app

เริ่มต้นแอปในสถานะปกติหลังจากการติดตั้ง เทียบเท่ากับ --start=COLD

--debug_app

รอให้แนบโปรแกรมแก้ไขข้อบกพร่องก่อนเริ่มต้นแอปในสถานะปกติหลังการติดตั้ง เทียบเท่ากับ --start=DEBUG

--start=_start_type_

แอปควรเริ่มต้นใช้งานอย่างไรหลังจากติดตั้ง _start_type_s ที่รองรับมีดังนี้

• NO ไม่เริ่มแอป นี่คือค่าเริ่มต้น
• COLD เริ่มแอปจากสถานะปกติหลังจากติดตั้ง
• WARM เก็บรักษาและคืนค่าสถานะของแอปพลิเคชันในการติดตั้งที่เพิ่มขึ้น
• DEBUG รอโปรแกรมแก้ไขข้อบกพร่องก่อนเริ่มแอปในสถานะปกติหลังการติดตั้ง

หมายเหตุ: หากตั้งค่า --start=_start_type_, --start_app หรือ --debug_app มากกว่า 1 ชุด ระบบจะใช้ค่าสุดท้าย

--adb=path

ระบุไบนารี adb ที่จะใช้

ค่าเริ่มต้นคือใช้ adb ใน Android SDK ที่ระบุโดย --android_sdk

--adb_arg=serial

มีอาร์กิวเมนต์เพิ่มเติมสำหรับ adb คำสั่งเหล่านี้อยู่ก่อนคำสั่งย่อยในบรรทัดคำสั่งและมักใช้เพื่อระบุอุปกรณ์ที่จะติดตั้ง เช่น หากต้องการเลือกอุปกรณ์ Android หรือโปรแกรมจำลองที่จะใช้

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

เรียกใช้ adb เป็น

adb -s deadbeef install ...

--incremental_install_verbosity=number

การพูดรายละเอียดสำหรับการติดตั้งทีละน้อย ตั้งค่าเป็น 1 สำหรับการบันทึกการแก้ไขข้อบกพร่องเพื่อพิมพ์ไปยังคอนโซล

dump

คำสั่ง dump จะพิมพ์ไปยังไฟล์ย่อยของสถานะภายในของเซิร์ฟเวอร์ Bazel คำสั่งนี้มีจุดประสงค์หลักเพื่อให้นักพัฒนาซอฟต์แวร์ Bazel ใช้งาน จึงไม่ได้ระบุเอาต์พุตของคำสั่งนี้และอาจมีการเปลี่ยนแปลง

โดยค่าเริ่มต้น คำสั่งจะพิมพ์เพียงข้อความช่วยเหลือที่ระบุตัวเลือกที่เป็นไปได้เพื่อถ่ายโอนพื้นที่ที่เฉพาะเจาะจงของรัฐ Bazel คุณต้องระบุตัวเลือกอย่างน้อย 1 ตัวเลือกเพื่อถ่ายโอนสถานะภายใน

ระบบรองรับตัวเลือกต่อไปนี้

• --action_cache ดัมพ์เนื้อหาแคชการดำเนินการ
• --packages ดัมพ์เนื้อหาแคชของแพ็กเกจ
• --skyframe ถ่ายโอนสถานะกราฟการขึ้นต่อกันของ Bazel ภายใน
• --rules ดัมพ์ "สรุปกฎ" ของกฎและคลาสแต่ละรายการ รวมทั้งจำนวนและการดำเนินการ ซึ่งรวมทั้งกฎเนทีฟและกฎ Starlark หากเปิดใช้การติดตามหน่วยความจำ ระบบจะพิมพ์การใช้หน่วยความจำของกฎด้วย
• --skylark_memory จะถ่ายโอนไฟล์ .gz ที่เข้ากันได้ pprof ไปยังเส้นทางที่ระบุ คุณต้องเปิดใช้การติดตามหน่วยความจำเพื่อให้ดำเนินการได้

การติดตามหน่วยความจำ

คำสั่ง dump บางคำสั่งต้องมีการติดตามหน่วยความจำ ในการเปิดใช้ฟีเจอร์นี้ คุณต้องส่งสถานะเริ่มต้น ไปยัง Bazel ดังนี้

• --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
• --host_jvm_args=-DRULE_MEMORY_TRACKER=1

Java-agent นี้มีการตรวจสอบใน Bazel ที่ third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar ดังนั้นโปรดตรวจสอบว่าคุณได้ปรับ $BAZEL สำหรับตำแหน่งที่คุณเก็บที่เก็บ Bazel ไว้

อย่าลืมส่งตัวเลือกเหล่านี้ไปยัง Bazel ทุกครั้งที่คำสั่ง ไม่เช่นนั้นเซิร์ฟเวอร์จะรีสตาร์ท

เช่น

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

คำสั่ง analyze-profile จะวิเคราะห์โปรไฟล์การติดตาม JSON ที่รวบรวมก่อนหน้านี้ระหว่างการเรียกใช้ Bazel

canonicalize-flags

คำสั่ง canonicalize-flags ซึ่งจะแสดงรายการตัวเลือกสำหรับคำสั่ง Bazel และแสดงผลรายการตัวเลือกที่มีผลเหมือนกัน รายการตัวเลือกใหม่คือหน้า Canonical เช่น ระบบจะกำหนด 2 รายการตัวเลือกซึ่งมีผลกระทบเหมือนกันเป็นรายการ Canonical ไปยังรายการใหม่รายการเดียวกัน

ใช้ตัวเลือก --for_command เพื่อเลือกระหว่างคำสั่งต่างๆ ได้ ปัจจุบันระบบรองรับเฉพาะ build และ test ข้อผิดพลาดที่คำสั่งที่ระบุไม่รองรับจะทำให้ระบบแสดงข้อผิดพลาด

หมายเหตุ: มีตัวเลือกบางรายการที่สั่งซื้อใหม่ไม่ได้ เนื่องจาก Bazel ยืนยันไม่ได้ว่าเอฟเฟกต์จะเหมือนกันหรือไม่ และโปรดทราบว่าคำสั่งนี้ไม่ขยายแฟล็กจาก --config

ตัวอย่างเช่น

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

ตัวเลือกเริ่มต้น

ตัวเลือกที่อธิบายในส่วนนี้จะมีผลต่อการเริ่มต้นใช้งาน Java Virtual Machine ที่ใช้โดยกระบวนการของเซิร์ฟเวอร์ Bazel และจะใช้กับคำสั่งหลังจากนั้นทั้งหมดที่จัดการโดยเซิร์ฟเวอร์ดังกล่าว หากมีเซิร์ฟเวอร์ Bazel ที่ทำงานอยู่แล้ว และตัวเลือกการเริ่มต้นไม่ตรงกัน ระบบจะรีสตาร์ทเซิร์ฟเวอร์

คุณต้องระบุตัวเลือกทั้งหมดที่อธิบายในส่วนนี้โดยใช้ไวยากรณ์ --key=value หรือ --key value นอกจากนี้ ตัวเลือกเหล่านี้ต้องปรากฏก่อนชื่อคำสั่ง Bazel ใช้ startup --key=value เพื่อแสดงรายการเหล่านี้ในไฟล์ .bazelrc

--output_base=dir

ตัวเลือกนี้ต้องมีอาร์กิวเมนต์เส้นทางซึ่งต้องระบุไดเรกทอรีที่เขียนได้ Bazel จะใช้ตำแหน่งนี้เพื่อเขียนเอาต์พุตทั้งหมด ฐานเอาต์พุตยังเป็นคีย์ที่ไคลเอ็นต์ใช้ค้นหาเซิร์ฟเวอร์ Bazel ด้วย การเปลี่ยนฐานเอาต์พุตจะเป็นการเปลี่ยนเซิร์ฟเวอร์ที่จะจัดการคำสั่ง

โดยค่าเริ่มต้น ฐานเอาต์พุตจะได้มาจากชื่อการเข้าสู่ระบบของผู้ใช้และชื่อของไดเรกทอรีพื้นที่ทำงาน (อันที่จริงคือไดเจสต์ MD5) ดังนั้นค่าทั่วไปจึงมีลักษณะดังนี้ /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e

หมายเหตุ: ไคลเอ็นต์ใช้ฐานเอาต์พุตเพื่อค้นหาอินสแตนซ์ของเซิร์ฟเวอร์ Bazel ดังนั้นหากคุณระบุฐานเอาต์พุตอื่นในคำสั่ง Bazel ระบบจะพบเซิร์ฟเวอร์อื่น (หรือเริ่มต้น) เพื่อจัดการคำขอ คุณจะสร้างบิลด์พร้อมกัน 2 บิลด์ในไดเรกทอรีพื้นที่ทำงานเดียวกันได้โดยสร้างฐานเอาต์พุตที่หลากหลาย

เช่น

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

ในคำสั่งนี้ คำสั่ง Bazel 2 คำสั่งจะทำงานพร้อมกัน (เนื่องจากโอเปอเรเตอร์ Shell &) แต่ละคำสั่งใช้อินสแตนซ์เซิร์ฟเวอร์ Bazel ที่ต่างกัน (เนื่องจากมีฐานเอาต์พุตต่างกัน) ในทางตรงกันข้าม หากใช้ฐานเอาต์พุตเริ่มต้นในคำสั่งทั้ง 2 คำสั่ง คำขอทั้ง 2 รายการจะส่งไปยังเซิร์ฟเวอร์เดียวกัน ซึ่งจะจัดการตามลำดับ: สร้าง //foo ก่อน ตามด้วยบิลด์ที่เพิ่มขึ้นของ //bar

หมายเหตุ: ขอแนะนำว่าอย่าใช้ NFS หรือระบบไฟล์ในเครือข่ายที่คล้ายกันสำหรับไดเรกทอรีราก เนื่องจากเวลาในการตอบสนองของการเข้าถึงที่สูงจะทำให้บิลด์ช้าลงอย่างเห็นได้ชัด

--output_user_root=dir

ชี้ไปที่ไดเรกทอรีรากที่สร้างเอาต์พุตและฐานผู้ใช้งาน ไดเรกทอรีต้องไม่มีอยู่หรือเป็นของผู้ใช้ที่โทรออก ในอดีต ระบบอนุญาตให้ชี้ไปที่ไดเรกทอรีที่แชร์กันระหว่างผู้ใช้ต่างๆ แต่ไม่ได้รับอนุญาตแล้ว ซึ่งอาจได้รับอนุญาตเมื่อมีการแก้ไขปัญหา #11100 แล้ว

หากระบุตัวเลือก --output_base ไว้ ระบบจะลบล้างโดยใช้ --output_user_root เพื่อคำนวณฐานเอาต์พุต

ตำแหน่งฐานผู้ใช้งานจะคำนวณตาม --output_user_root รวมถึงข้อมูลระบุตัวตน MD5 ของไบนารีแบบฝังของ Bazel

คุณใช้ตัวเลือก --output_user_root เพื่อเลือกตำแหน่งฐานอื่นสำหรับเอาต์พุตทั้งหมดของ Bazel (ฐานการติดตั้งและฐานเอาต์พุต) ได้หากมีตำแหน่งที่ดีกว่าในเลย์เอาต์ของระบบไฟล์

หมายเหตุ: ขอแนะนำว่าอย่าใช้ NFS หรือระบบไฟล์ในเครือข่ายที่คล้ายกันสำหรับไดเรกทอรีราก เนื่องจากเวลาในการตอบสนองของการเข้าถึงที่สูงจะทำให้บิลด์ช้าลงอย่างเห็นได้ชัด

--server_javabase=dir

ระบุเครื่องเสมือน Java ที่ Bazel เองทำงาน ค่าต้องเป็นเส้นทางไปยังไดเรกทอรีที่มี JDK หรือ JRE ซึ่งไม่ควรเป็นป้ายกำกับ ตัวเลือกนี้ควรปรากฏก่อนคำสั่ง Bazel ใดๆ เช่น

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

แฟล็กนี้ไม่ส่งผลต่อ JVM ที่ใช้โดยกระบวนการย่อยของ Bazel เช่น แอปพลิเคชัน การทดสอบ เครื่องมือ และอื่นๆ ใช้ตัวเลือกบิลด์ --javabase หรือ --host_javabase แทน

ก่อนหน้านี้แฟล็กนี้มีชื่อว่า --host_javabase (บางครั้งเรียกว่า --host_javabase ทางด้านซ้าย) แต่ได้เปลี่ยนชื่อเพื่อหลีกเลี่ยงความสับสนกับแฟล็กการสร้าง --host_javabase (บางครั้งเรียกว่า --host_javabase "ทางขวา")

--host_jvm_args=string

ระบุตัวเลือกการเริ่มต้นระบบที่จะส่งไปยังเครื่องเสมือน Java ที่ Bazel เองทำงาน การตั้งค่านี้ใช้เพื่อกำหนดขนาดของสแต็กได้ เช่น

  % bazel --host_jvm_args="-Xss256K" build //foo

ตัวเลือกนี้ใช้ได้หลายครั้งกับอาร์กิวเมนต์แต่ละรายการ โปรดทราบว่า คุณไม่จำเป็นต้องตั้งค่าแฟล็กนี้ นอกจากนี้ คุณยังสามารถส่งรายการสตริงที่คั่นด้วยช่องว่างได้ ซึ่งแต่ละรายการจะถูกตีความเป็นอาร์กิวเมนต์ JVM แยกกัน แต่ฟีเจอร์นี้จะถูกเลิกใช้งานในเร็วๆ นี้

การดำเนินการนี้ไม่ส่งผลต่อ JVM ใดๆ ที่ใช้โดยกระบวนการย่อยของ Bazel เช่น แอปพลิเคชัน การทดสอบ เครื่องมือ และอื่นๆ หากต้องการส่งตัวเลือก JVM ไปยังโปรแกรม Java ที่ดำเนินการได้ ไม่ว่าจะเรียกใช้โดย bazel run หรือบนบรรทัดคำสั่ง คุณควรใช้อาร์กิวเมนต์ --jvm_flags ซึ่งโปรแกรม java_binary และ java_test ทั้งหมดรองรับ หรือสำหรับการทดสอบ ให้ใช้ bazel test --test_arg=--jvm_flags=foo ...

--host_jvm_debug

ตัวเลือกนี้จะทำให้เครื่องเสมือนของ Java รอการเชื่อมต่อจากโปรแกรมแก้ไขข้อบกพร่องที่สอดคล้องกับ JDWP ก่อนที่จะเรียกใช้เมธอดหลักของ Bazel เอง ส่วนนี้มีวัตถุประสงค์หลัก เพื่อใช้งานโดยนักพัฒนาของ Bazel

หมายเหตุ: ข้อกำหนดนี้ไม่ส่งผลต่อ JVM ที่ใช้โดยกระบวนการย่อยของ Bazel เช่น แอปพลิเคชัน การทดสอบ เครื่องมือ ฯลฯ

--autodetect_server_javabase

ตัวเลือกนี้จะทำให้ Bazel ค้นหา JDK ที่ติดตั้งไว้โดยอัตโนมัติเมื่อเริ่มต้นใช้งาน และกลับไปใช้ JRE ที่ติดตั้งไว้หาก JRE ที่ฝังไว้ไม่พร้อมใช้งาน คุณสามารถใช้ --explicit_server_javabase เพื่อเลือก JRE ที่ชัดเจน ซึ่งใช้ Bazel ด้วย

--batch

โหมดแบบกลุ่มทำให้ Bazel ไม่ใช้โหมดไคลเอ็นต์/เซิร์ฟเวอร์มาตรฐาน แต่เรียกใช้กระบวนการ Java แบบ Bazel แทนสำหรับคำสั่งเดียว ซึ่งใช้สำหรับความหมายที่คาดการณ์ได้มากขึ้นในด้านการจัดการสัญญาณ การควบคุมงาน และการสืบทอดตัวแปรสภาพแวดล้อม และจำเป็นสำหรับการเรียกใช้ Bazel ในคุก chroot

โหมดแบตช์จะเก็บความหมายของคิวที่เหมาะสมไว้ภายใน out_base เดียวกัน กล่าวคือ ระบบจะประมวลผลการเรียกใช้พร้อมกันตามลำดับโดยไม่ทับซ้อนกัน หากเรียกใช้ Bazel ในโหมดกลุ่มบนไคลเอ็นต์ที่มีเซิร์ฟเวอร์ทำงานอยู่ ระบบจะฆ่าเซิร์ฟเวอร์ก่อนประมวลผลคำสั่ง

Bazel จะทำงานช้าลงในโหมดแบบกลุ่ม หรือใช้ทางเลือกอื่นที่อธิบายไว้ข้างต้น ทั้งนี้เป็นเพราะแคชของไฟล์บิลด์เป็นส่วนที่อยู่ในหน่วยความจำ จึงไม่มีการเก็บรักษาไว้ระหว่างการเรียกใช้แบบกลุ่มตามลำดับ ดังนั้น การใช้โหมดแบบกลุ่มจึงมักจะเหมาะสมกว่าในกรณีที่ประสิทธิภาพไม่สำคัญนัก เช่น การสร้างอย่างต่อเนื่อง

คำเตือน: --batch ช้ากว่าโหมดไคลเอ็นต์/เซิร์ฟเวอร์มาตรฐานพอสมควร นอกจากนี้ ยังอาจไม่รองรับฟีเจอร์และการเพิ่มประสิทธิภาพทั้งหมดที่เป็นไปได้ในเซิร์ฟเวอร์ Bazel ถาวร หากใช้ --batch เพื่อจุดประสงค์ในการแยกบิลด์ คุณควรใช้ตัวเลือกคำสั่ง --nokeep_state_after_build ซึ่งรับประกันว่าจะไม่มีการเก็บสถานะในหน่วยความจำที่เพิ่มขึ้นระหว่างบิลด์ต่างๆ หากต้องการรีสตาร์ทเซิร์ฟเวอร์ Bazel และ JVM หลังจากบิลด์แล้ว โปรดดำเนินการอย่างชัดแจ้งโดยใช้คำสั่ง "shutdown"

--max_idle_secs=n

ตัวเลือกนี้จะระบุระยะเวลาเป็นวินาทีที่กระบวนการของเซิร์ฟเวอร์ Bazel ควรรอหลังจากคำขอของไคลเอ็นต์สุดท้ายก่อนที่จะออก ค่าเริ่มต้นคือ 10800 (3 ชั่วโมง) --max_idle_secs=0 จะทำให้กระบวนการของเซิร์ฟเวอร์ Bazel คงอยู่ต่อไปโดยไม่มีกำหนด

หมายเหตุ: ระบบจะอ่านแฟล็กนี้เฉพาะในกรณีที่ Bazel ต้องเริ่มเซิร์ฟเวอร์ใหม่ การเปลี่ยนตัวเลือกนี้จะไม่ทำให้เซิร์ฟเวอร์รีสตาร์ท

สคริปต์ที่เรียกใช้ Bazel อาจใช้ตัวเลือกนี้เพื่อให้แน่ใจว่าไม่มีการปล่อยกระบวนการของเซิร์ฟเวอร์ Bazel ไว้ในเครื่องของผู้ใช้เมื่อไม่ได้ทำงานอยู่ ตัวอย่างเช่น สคริปต์ที่ส่งล่วงหน้าอาจต้องการเรียกใช้ bazel query เพื่อให้แน่ใจว่าการเปลี่ยนแปลงที่รอดำเนินการของผู้ใช้จะไม่แสดงทรัพยากร Dependency ที่ไม่ต้องการ อย่างไรก็ตาม หากผู้ใช้ยังไม่ได้สร้างบิลด์ล่าสุดในพื้นที่ทำงานดังกล่าว สคริปต์การส่งล่วงหน้าก็จะเริ่มต้นเซิร์ฟเวอร์ Bazel นั้นไม่น่าจะทำงานต่อไปเรื่อยๆ ตลอดทั้งวัน การระบุค่า --max_idle_secs เพียงเล็กน้อยในคำขอคำค้นหาจะทำให้สคริปต์มั่นใจได้ว่า if ทำให้เซิร์ฟเวอร์ใหม่เริ่มทำงาน เซิร์ฟเวอร์นั้นจะออกจากเซิร์ฟเวอร์ทันที แต่ถ้ายังมีเซิร์ฟเวอร์ทำงานอยู่แล้ว เซิร์ฟเวอร์นั้นจะยังคงทำงานต่อไปจนกว่าจะไม่มีความเคลื่อนไหวเป็นเวลาปกติ แน่นอนว่าระบบจะรีเซ็ตตัวจับเวลา ที่ไม่มีการใช้งานของเซิร์ฟเวอร์ที่มีอยู่

--[no]shutdown_on_low_sys_mem

หากเปิดใช้และตั้ง --max_idle_secs ให้มีระยะเวลาเป็นบวก หลังจากเซิร์ฟเวอร์บิลด์ไม่มีการใช้งานเป็นระยะเวลาหนึ่ง ให้ปิดเซิร์ฟเวอร์เมื่อระบบมีหน่วยความจำเหลือน้อย Linux เท่านั้น

นอกจากการเรียกใช้การตรวจสอบการไม่มีการใช้งานที่สอดคล้องกับ max_idle_secs แล้ว เซิร์ฟเวอร์บิลด์จะเริ่มตรวจสอบหน่วยความจำของระบบที่ใช้ได้หลังจากที่เซิร์ฟเวอร์ไม่มีการใช้งานมาเป็นระยะเวลาหนึ่งแล้ว หากหน่วยความจำของระบบที่ใช้ได้เหลือน้อยลงมาก เซิร์ฟเวอร์จะออกจากการทำงาน

--[no]block_for_lock

หากเปิดใช้ Bazel จะรอให้คำสั่ง Bazel อื่นๆ ที่ล็อกเซิร์ฟเวอร์ไว้ให้เสร็จก่อนที่จะดำเนินการต่อ หากปิดใช้ Bazel จะออกด้วยความผิดพลาดหากไม่สามารถรับล็อกได้ทันทีและดำเนินการต่อไป

นักพัฒนาซอฟต์แวร์อาจใช้วิธีนี้ในการตรวจสอบการส่งล่วงหน้าเพื่อหลีกเลี่ยงการรอนานซึ่งเกิดจากคำสั่ง Bazel อื่นในไคลเอ็นต์เดียวกัน

--io_nice_level=n

ตั้งระดับตั้งแต่ 0-7 เพื่อให้กำหนดเวลา IO อย่างเต็มประสิทธิภาพ 0 คือลำดับความสำคัญสูงสุด 7 คือต่ำสุด เครื่องจัดตารางเวลาที่คาดไว้จะใช้ได้ไม่เกิน 4 ลำดับความสำคัญ ระบบจะไม่สนใจค่าเชิงลบ

--batch_cpu_scheduling

ใช้การกำหนดเวลา CPU ของ batch สำหรับ Bazel นโยบายนี้มีประโยชน์สำหรับภาระงานที่ไม่ใช่แบบอินเทอร์แอกทีฟ แต่ไม่ต้องการลดคุณค่าที่แท้จริง ดู "man 2 sched_setscheduler" นโยบายนี้อาจให้การโต้ตอบของระบบที่ดียิ่งขึ้น ซึ่งลดอัตราการส่งข้อมูลของ Bazel

ตัวเลือกเบ็ดเตล็ด

--[no]announce_rc

ควบคุมว่าจะให้ Bazel ประกาศตัวเลือกคำสั่งที่อ่านจากไฟล์ bazelrc เมื่อเริ่มต้นระบบหรือไม่ (มีการประกาศตัวเลือกสตาร์ทอัพโดยไม่มีเงื่อนไข)

--color (yes|no|auto)

ตัวเลือกนี้จะกำหนดว่า Bazel จะใช้สีเพื่อไฮไลต์ผลลัพธ์บนหน้าจอไหม

หากตั้งค่าตัวเลือกนี้เป็น yes ระบบจะเปิดใช้เอาต์พุตสี หากตั้งค่านโยบายนี้เป็น auto Bazel จะใช้เอาต์พุตสีก็ต่อเมื่อกำลังส่งเอาต์พุตไปยังเทอร์มินัลและได้ตั้งค่าตัวแปรสภาพแวดล้อม TERM เป็นค่าอื่นที่ไม่ใช่ dumb, emacs หรือ xterm-mono หากตั้งค่าตัวเลือกนี้เป็น no ระบบจะปิดใช้เอาต์พุตสี ไม่ว่าเอาต์พุตจะไปยังเทอร์มินัลหรือไม่ และไม่ว่าการตั้งค่าตัวแปรสภาพแวดล้อม TERM จะเป็นอย่างไรก็ตาม

--config=name

เลือกส่วนการกำหนดค่าเพิ่มเติมจากไฟล์ rc สำหรับ command ปัจจุบัน ระบบจะดึงตัวเลือกจาก command:name ด้วย หากมีส่วนดังกล่าวอยู่ สามารถระบุได้หลายครั้งเพื่อเพิ่มแฟล็กจากส่วนการกำหนดค่าหลายๆ ส่วน ส่วนขยายอาจหมายถึงคำจำกัดความอื่นๆ (เช่น การขยายสายได้)

--curses (yes|no|auto)

ตัวเลือกนี้จะกำหนดว่า Bazel จะใช้การควบคุมเคอร์เซอร์ ในเอาต์พุตหน้าจอหรือไม่ ซึ่งส่งผลให้ข้อมูลที่เลื่อนได้น้อยลงและมีเอาต์พุตที่กะทัดรัดและอ่านง่ายจาก Bazel มากขึ้น ใช้ได้ดีกับ --color

หากเลือกตัวเลือกนี้เป็น yes ระบบจะเปิดใช้การควบคุมเคอร์เซอร์ หากเลือกตัวเลือกนี้เป็น no ระบบจะปิดใช้การควบคุมเคอร์เซอร์ หากเลือกตัวเลือกนี้เป็น auto ระบบจะเปิดใช้การควบคุมเคอร์เซอร์ภายใต้เงื่อนไขเดียวกันกับ --color=auto

--[no]show_timestamps

หากระบุ ระบบจะเพิ่มการประทับเวลาลงในแต่ละข้อความที่สร้างโดย Bazel ซึ่งระบุเวลาที่แสดงข้อความ