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

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

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

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

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

--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++ หรือโค้ด Assembler เนื่องจากระบบจะไม่ส่งข้อมูลนี้เมื่อทำการลิงก์

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

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

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

--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 ได้

--cxxopt=cc-option

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

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

เช่น

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

--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

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

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

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

--stripopt=strip-option

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

--fdo_instrument=profile-output-dir

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

--[no]output_symbol_counts

หากเปิดใช้ ลิงก์ที่มีการเรียกด้วยทองคำแต่ละลิงก์ของไบนารีที่ดำเนินการได้ของ C++ จะแสดงผลไฟล์จำนวนสัญลักษณ์ (ผ่านตัวเลือก --print-symbol-counts โกลด์) สำหรับอินพุต Linker แต่ละรายการ ไฟล์จะบันทึกจำนวนสัญลักษณ์ที่กำหนดและจำนวนสัญลักษณ์ที่ใช้ในไบนารี ข้อมูลนี้สามารถใช้เพื่อติดตามการอ้างอิงลิงก์ที่ไม่จำเป็นได้ ระบบจะเขียนไฟล์จำนวนสัญลักษณ์ลงในเส้นทางเอาต์พุตของไบนารีโดยใช้ชื่อ [targetname].sc

ตัวเลือกนี้จะปิดใช้โดยค่าเริ่มต้น

--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 และอาจขยายได้โดยการลงทะเบียนเชนเครื่องมือ 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 โดยใช้

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

--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 Binaries ทั้งหมดและตั้งค่าขนาดฮีปการเริ่มต้นสำหรับ VM เป็น 256 MB

--javacopt=javac-option

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

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

จะสร้าง java_binary ใหม่ที่มีข้อมูลการแก้ไขข้อบกพร่องเริ่มต้น Javac (แทนค่าเริ่มต้นแบบเบเซล)

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

--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

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

--experimental_extra_action_filter=regex

ตัวเลือก 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 ที่ควรจะใช้ในการสร้างเครื่องมือโฮสต์

--fat_apk_cpu=cpu[,cpu]*

CPU ที่จะสร้างไลบรารี C/C++ สำหรับกฎ deps จาก android_binary ข้อทางอ้อม ส่วนกฎ C/C++ อื่นๆ จะไม่ได้รับผลกระทบ ตัวอย่างเช่น หาก cc_library ปรากฏใน deps แบบสับเปลี่ยนของกฎ android_binary และกฎ cc_binary ระบบจะสร้าง cc_library อย่างน้อย 2 ครั้ง กล่าวคือ 1 ครั้งสำหรับ CPU แต่ละรายการที่ระบุด้วย --fat_apk_cpu สำหรับกฎ android_binary และ 1 ครั้งสำหรับ CPU ที่ระบุด้วย --cpu สำหรับกฎ cc_binary

โดยมีค่าเริ่มต้นเป็น armeabi-v7a

ระบบจะสร้างไฟล์ .so 1 ไฟล์และจัดทำแพ็กเกจใน APK สำหรับ CPU แต่ละเครื่องที่ระบุด้วย --fat_apk_cpu ชื่อไฟล์ .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 ระบบจะปิดใช้ Fission ทั้งหมด ค่าเริ่มต้นคือ no

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

ตัวเลือกนี้ระบุตำแหน่งของชุดคอมไพเลอร์ Crosstool ที่จะใช้สำหรับการคอมไพล์ C++ ทั้งหมดระหว่างบิลด์ แบเซิลจะค้นหาไฟล์ 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

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

--compiler=version

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

--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 เพื่อคอมไพล์โค้ดในการกำหนดค่าโฮสต์ เช่น สำหรับเครื่องมือที่เรียกใช้ระหว่างบิลด์ จุดประสงค์หลักของ Flag นี้คือ เปิดใช้การคอมไพล์ข้ามกัน

--javabase=(label)

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

--host_javabase=label

ตัวเลือกนี้จะตั้งค่าป้ายกำกับของการติดตั้ง Java พื้นฐานเพื่อใช้ในการกำหนดค่าโฮสต์ เช่น สำหรับเครื่องมือสร้างโฮสต์ซึ่งรวมถึง 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 ที่มีกฎการช่วยจำ) แบบรายบุคคล ดูกลยุทธ์ที่รองรับและผลกระทบได้ที่ --spawn_strategy

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

ตัวเลือกนี้จะระบุว่าควรใช้กลยุทธ์ใดเพื่อเรียกใช้คำสั่งที่มีคำอธิบายที่ตรงกับ regex_filter ที่กำหนด ดูรายละเอียดเกี่ยวกับการจับคู่ 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 (-j)

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

--progress_report_interval=n

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

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

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-K)

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

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

--[no]use_ijars

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

--[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 รายการที่อาศัยไฟล์ต้นทางเพื่อตรวจหาข้อผิดพลาดโดยเร็วที่สุดเท่าที่จะทำได้ในรอบการแก้ไข/สร้าง/ทดสอบ อาร์กิวเมนต์นี้ส่งผลต่อวิธีการตีความอาร์กิวเมนต์ทั้งหมดที่ไม่ใช่ Flag กล่าวคือ แต่ละอาร์กิวเมนต์ต้องเป็นป้ายกำกับเป้าหมายไฟล์หรือชื่อไฟล์ธรรมดาที่สัมพันธ์กับไดเรกทอรีที่ใช้งานอยู่ในปัจจุบัน และมีกฎ 1 ข้อที่อ้างอิงชื่อไฟล์ต้นฉบับแต่ละชื่อ สำหรับ

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

--save_temps

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

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

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

--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=lang[,lang]*

ระบุรายการภาษาทดสอบที่คั่นด้วยคอมมาสำหรับภาษาที่มีกฎ *_test อย่างเป็นทางการ (ดูรายการภาษาทั้งหมดได้ที่สร้างสารานุกรม) แต่ละภาษาสามารถขึ้นต้นด้วย "-" หรือไม่ก็ได้ เพื่อระบุภาษาที่ยกเว้น ชื่อที่ใช้สำหรับแต่ละภาษาควรเหมือนกับคำนำหน้าภาษาในกฎ *_test เช่น cc, java หรือ sh

หากระบุไว้ Bazel จะทดสอบ (หรือสร้างหากระบุ --build_tests_only ด้วย) ทดสอบเฉพาะเป้าหมายของภาษาที่ระบุ

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

  % bazel test --test_lang_filters=cc,java foo/...

จะทดสอบเฉพาะการทดสอบ C/C++ และ Java (กำหนดโดยใช้กฎ cc_test และ java_test ตามลำดับ) ใน foo/... ขณะที่

  % bazel test --test_lang_filters=-sh,-java foo/...

จะเรียกใช้การทดสอบทั้งหมดใน foo/... ยกเว้นการทดสอบ sh_test และ java_test

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

--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

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

--show_result=n

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

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

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

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

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

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

--workspace_status_command=program

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

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

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

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,000)

ใน Linux/macOS คุณสามารถส่ง --workspace_status_command=/bin/true เพื่อปิดใช้การดึงข้อมูลสถานะพื้นที่ทำงาน เนื่องจาก true ไม่ดำเนินการใดๆ สำเร็จ (การออกโดยไม่มีค่า 0) และไม่พิมพ์เอาต์พุต ส่วนใน 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 โปรดดูรายละเอียดที่สารานุกรมบิลด์ เมื่อกฎตั้งค่า stamp = -1 (ค่าเริ่มต้นสำหรับกฎ *_binary) ตัวเลือกนี้จะกำหนดว่าเปิดใช้การประทับหรือไม่

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

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--[no]use_action_cache

ตัวเลือกนี้จะเปิดใช้โดยค่าเริ่มต้น หากปิดใช้ 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 ตรวจพบการเปลี่ยนแปลงในการทดสอบหรือการอ้างอิง
• การทดสอบจะทําเครื่องหมายเป็น external
• มีการขอการทดสอบหลายรายการกับ --runs_per_test
• การทดสอบล้มเหลว

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

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

ผู้ใช้ที่เปิดใช้ตัวเลือกนี้โดยค่าเริ่มต้นในไฟล์ .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 หรือ LONG เนื่องจากกว้างเกินไป

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

สถานะของเป้าหมายที่มีการเรียกใช้ที่ล้มเหลวจะขึ้นอยู่กับค่าของแฟล็ก --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

--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 ในสภาพแวดล้อมของคุณ ดังนั้น คุณจึงอาจต้องใช้เส้นทางสัมบูรณ์สำหรับคำสั่ง --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 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 ดังกล่าวในพื้นที่ทำงานดังกล่าว

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

  % bazel clean --expunge

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

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

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

การค้นหากราฟการอ้างอิง

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

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

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

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

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

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

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

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

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

คำสั่ง 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 ยอมรับ 1 ตัวเลือก ซึ่งก็คือ --iff_heap_size_greater_than _n_ ซึ่งต้องการอาร์กิวเมนต์ที่เป็นจำนวนเต็ม (เป็น 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 นำจุดเริ่มต้นและเอาต์พุต บิลด์ทั้งหมดมาไว้ใต้ไดเรกทอรีนี้

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

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

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

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

• command_log: เส้นทางสัมบูรณ์ไปยังไฟล์บันทึกคำสั่ง ซึ่งมีสตรีม Stdout และ stderr แบบแทรกสลับของคำสั่ง 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: รายการเส้นทางที่คั่นด้วยโคลอนซึ่งจะใช้ค้นหาแพ็กเกจด้วยเบเซล มีรูปแบบเดียวกันกับอาร์กิวเมนต์บรรทัดคำสั่ง --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 แทนที่จะถือว่ามี symlink จะมีประสิทธิภาพมากกว่า
• สภาพแวดล้อม"สร้าง" ที่สมบูรณ์ หากมีการระบุแฟล็ก --show_make_env ตัวแปรทั้งหมดในสภาพแวดล้อม "สร้าง" ของการกำหนดค่าปัจจุบันก็จะแสดงด้วย (เช่น 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

ดูข้อมูลเพิ่มเติมที่การติดตั้งบนอุปกรณ์เคลื่อนที่แบบเบเซล

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

--incremental

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

หากคุณใช้อุปกรณ์ที่มี Marshmallow ขึ้นไป โปรดพิจารณาธง --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 รอให้โปรแกรมแก้ไขข้อบกพร่องก่อนเริ่มแอปให้อยู่ในสถานะปกติหลังการติดตั้ง

--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 จะวิเคราะห์ข้อมูลที่รวบรวมไว้ก่อนหน้านี้ระหว่างบิลด์โดยใช้ตัวเลือก --profile โดยมีตัวเลือกมากมายสำหรับการวิเคราะห์การดำเนินการบิลด์หรือส่งออกข้อมูลในรูปแบบที่ระบุ

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

• --dump จะแสดงข้อมูลทั้งหมดที่รวบรวมไว้ในรูปแบบที่มนุษย์อ่านได้ อย่างไรก็ตาม วิธีนี้ยังไม่รองรับรูปแบบอื่นๆ

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

canonicalize-flags

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

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

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

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

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

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

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

--output_base=dir

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

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

เช่น

 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 คำสั่ง ระบบจะส่งคำขอทั้งสองไปยังเซิร์ฟเวอร์เดียวกันซึ่งจะจัดการตามลําดับ นั่นคือ การสร้าง //foo ก่อนแล้วตามด้วยบิลด์ที่เพิ่มขึ้นของ //bar

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

  % 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 เป็นหลัก

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

สคริปต์ที่เรียกใช้ 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 โดยระบุเวลาที่ข้อความจะแสดง