หน้านี้ครอบคลุมตัวเลือกที่ใช้ได้กับคำสั่งต่างๆ ของ 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 รูปแบบ ดังนี้
- หากอักขระตัวแรกคือ
/
เส้นทางจะเป็นสัมบูรณ์ - หากเส้นทางขึ้นต้นด้วย
%workspace%
ระบบจะนำเส้นทางนั้นไปสัมพันธ์กับไดเรกทอรีที่ล้อมกรอบซึ่งอยู่ใกล้ที่สุด ตัวอย่างเช่น หากไดเรกทอรีที่ใช้งานอยู่คือ/home/bob/clients/bob_client/bazel/foo
สตริง%workspace%
ในเส้นทางแพ็กเกจจะขยายเป็น/home/bob/clients/bob_client/bazel
- ส่วนข้อมูลอื่นๆ จะเกี่ยวข้องกับไดเรกทอรีที่ใช้งานอยู่
ซึ่งมักไม่ใช่สิ่งที่คุณตั้งใจจะทำ และอาจทำงานโดยไม่คาดคิดหากคุณใช้ 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
โดยไม่มีตารางการแก้ไขข้อบกพร่อง ซึ่งจะสร้างโค้ดที่ไม่ขึ้นอยู่กับตำแหน่ง
--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
ของ 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 แต่ละไฟล์
เมื่อสร้างโครงสร้างข้อมูลโปรไฟล์แล้ว แผนผังโปรไฟล์ควรจะถูกบีบอัดและระบุไปยังตัวเลือก 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 ก็ได้
สำหรับคอมไพเลอร์ 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ด้วย
--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 เป้าหมายที่จะใช้สำหรับการคอมไพล์ไบนารีระหว่างบิลด์
--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 ที่ควรใช้ในการสร้างเครื่องมือโฮสต์
--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
สำหรับ cygwindefault
: อนุญาตให้ Bazel เลือกว่าจะลิงก์แบบไดนามิกหรือไม่ ดูข้อมูลเพิ่มเติมได้ที่ linkstaticfully
: ลิงก์เป้าหมายทั้งหมดแบบไดนามิก ซึ่งจะช่วยเร่งเวลาในการลิงก์ และลดขนาดของไบนารีที่ได้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 และลิงก์จะสร้างไฟล์ปฏิบัติการที่ไม่ขึ้นอยู่กับตำแหน่ง ("-พาย") ค่าเริ่มต้นคือปิดใช้
--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
เครื่องมือข้ามที่ใช้สำหรับคอมไพล์กฎ C/C++ ในกฎ deps
จาก android_binary
แบบทางอ้อม วิธีนี้มีประโยชน์หากเป้าหมายอื่นๆ ใน
บิลด์ต้องใช้ Crosstool ที่แตกต่างกัน ค่าเริ่มต้นคือใช้เครื่องมือข้ามเครื่องมือที่สร้างโดยกฎ android_ndk_repository
ในไฟล์ WORKSPACE
ดู --android_platforms
เพิ่มเติม
--compiler=version
ตัวเลือกนี้จะระบุเวอร์ชันคอมไพเลอร์ C/C++ (เช่น gcc-4.1.0
) ที่จะใช้สำหรับการคอมไพล์ไบนารีระหว่างบิลด์ หากต้องการสร้างด้วย Crosstool ที่กำหนดเอง คุณควรใช้ไฟล์ 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
เพื่อคอมไพล์โค้ดในการกำหนดค่า 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 ในเครื่อง จำเป็นต้องติดตั้ง Dockerremote
ทำให้มีการเรียกใช้คำสั่งจากระยะไกล ซึ่งจะใช้ได้ต่อเมื่อกำหนดค่าผู้ดำเนินการระยะไกลไว้ต่างหากเท่านั้น
--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
(- จ)
ตัวเลือกนี้ซึ่งใช้อาร์กิวเมนต์จำนวนเต็มจะระบุขีดจำกัดสำหรับจำนวนงานที่ควรทำพร้อมกันในระหว่างระยะการดำเนินการของบิลด์
--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 ของอินเทอร์เฟซเพื่อรวบรวมเป้าหมายที่เกี่ยวข้อง ซึ่งทำให้หลีกเลี่ยงการคอมไพล์ซ้ำได้เมื่อมีการเปลี่ยนแปลงเฉพาะเนื้อหาวิธีการหรือสมาชิกส่วนตัวของชั้นเรียน
--[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
ใช้ได้กับกฎ 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
--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 จากสคริปต์ โดยเฉพาะอย่างยิ่ง เราขอแนะนำ เป็นอย่างยิ่งว่าตัวเลือกดังต่อไปนี้
ตัวเลือกเหล่านี้มีความสำคัญเช่นกัน:
--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
ผู้ใช้ที่เปิดใช้ตัวเลือกนี้โดยค่าเริ่มต้นในไฟล์ .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 เนื่องจากเป็นการทดสอบที่มากเกินไป
ตัวเลือกนี้จะมีประโยชน์ในการช่วยให้ผู้ใช้ตัดสินใจเลือกค่าระยะหมดเวลาที่เหมาะสมหรือตรวจสอบค่าการหมดเวลาที่มีอยู่ได้อย่างถูกต้อง
--[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
--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 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 ในไคลเอ็นต์เดียวกันขณะที่การล้างข้อมูลแบบอะซิงโครนัสยังคงทำงานต่อไป
คำสั่ง 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
ช่วยให้คุณค้นหาการดำเนินการในกราฟบิลด์ได้
โดยจะดำเนินการกับกราฟเป้าหมายที่กำหนดค่าหลังการวิเคราะห์ และแสดงข้อมูลการกระทำ อาร์ติแฟกต์ และความสัมพันธ์ของวัตถุเหล่านั้น
เครื่องมือยอมรับตัวเลือกบรรทัดคำสั่งหลายรายการ
--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
: รหัสกระบวนการของเซิร์ฟเวอร์ Bazelserver_log
: เส้นทางสัมบูรณ์ไปยังไฟล์บันทึกการแก้ไขข้อบกพร่องของเซิร์ฟเวอร์ Bazel ไฟล์นี้มีข้อมูลการแก้ไขข้อบกพร่องของคำสั่งทั้งหมดตลอดอายุการใช้งานของเซิร์ฟเวอร์ Bazel ซึ่งมีไว้สำหรับการใช้งานของมนุษย์โดยนักพัฒนาและผู้ใช้ขั้นสูงของ Bazelcommand_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 สำหรับอุปกรณ์เคลื่อนที่
ระบบรองรับตัวเลือกต่อไปนี้
--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
รอโปรแกรมแก้ไขข้อบกพร่องก่อนเริ่มแอปในสถานะปกติหลังการติดตั้ง
--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 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
เช่น
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
--output_user_root=dir
ชี้ไปที่ไดเรกทอรีรากที่สร้างเอาต์พุตและฐานผู้ใช้งาน ไดเรกทอรีต้องไม่มีอยู่หรือเป็นของผู้ใช้ที่โทรออก ในอดีต ระบบอนุญาตให้ชี้ไปที่ไดเรกทอรีที่แชร์กันระหว่างผู้ใช้ต่างๆ แต่ไม่ได้รับอนุญาตแล้ว ซึ่งอาจได้รับอนุญาตเมื่อมีการแก้ไขปัญหา #11100 แล้ว
หากระบุตัวเลือก --output_base
ไว้ ระบบจะลบล้างโดยใช้ --output_user_root
เพื่อคำนวณฐานเอาต์พุต
ตำแหน่งฐานผู้ใช้งานจะคำนวณตาม --output_user_root
รวมถึงข้อมูลระบุตัวตน MD5 ของไบนารีแบบฝังของ Bazel
คุณใช้ตัวเลือก --output_user_root
เพื่อเลือกตำแหน่งฐานอื่นสำหรับเอาต์พุตทั้งหมดของ Bazel (ฐานการติดตั้งและฐานเอาต์พุต) ได้หากมีตำแหน่งที่ดีกว่าในเลย์เอาต์ของระบบไฟล์
--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
--autodetect_server_javabase
ตัวเลือกนี้จะทำให้ Bazel ค้นหา JDK ที่ติดตั้งไว้โดยอัตโนมัติเมื่อเริ่มต้นใช้งาน และกลับไปใช้ JRE ที่ติดตั้งไว้หาก JRE ที่ฝังไว้ไม่พร้อมใช้งาน
คุณสามารถใช้ --explicit_server_javabase
เพื่อเลือก JRE ที่ชัดเจน
ซึ่งใช้ Bazel ด้วย
--batch
โหมดแบบกลุ่มทำให้ Bazel ไม่ใช้โหมดไคลเอ็นต์/เซิร์ฟเวอร์มาตรฐาน แต่เรียกใช้กระบวนการ Java แบบ Bazel แทนสำหรับคำสั่งเดียว ซึ่งใช้สำหรับความหมายที่คาดการณ์ได้มากขึ้นในด้านการจัดการสัญญาณ การควบคุมงาน และการสืบทอดตัวแปรสภาพแวดล้อม และจำเป็นสำหรับการเรียกใช้ Bazel ในคุก chroot
โหมดแบตช์จะเก็บความหมายของคิวที่เหมาะสมไว้ภายใน out_base เดียวกัน กล่าวคือ ระบบจะประมวลผลการเรียกใช้พร้อมกันตามลำดับโดยไม่ทับซ้อนกัน หากเรียกใช้ Bazel ในโหมดกลุ่มบนไคลเอ็นต์ที่มีเซิร์ฟเวอร์ทำงานอยู่ ระบบจะฆ่าเซิร์ฟเวอร์ก่อนประมวลผลคำสั่ง
Bazel จะทำงานช้าลงในโหมดแบบกลุ่ม หรือใช้ทางเลือกอื่นที่อธิบายไว้ข้างต้น ทั้งนี้เป็นเพราะแคชของไฟล์บิลด์เป็นส่วนที่อยู่ในหน่วยความจำ จึงไม่มีการเก็บรักษาไว้ระหว่างการเรียกใช้แบบกลุ่มตามลำดับ ดังนั้น การใช้โหมดแบบกลุ่มจึงมักจะเหมาะสมกว่าในกรณีที่ประสิทธิภาพไม่สำคัญนัก เช่น การสร้างอย่างต่อเนื่อง
--max_idle_secs=n
ตัวเลือกนี้จะระบุระยะเวลาเป็นวินาทีที่กระบวนการของเซิร์ฟเวอร์ Bazel ควรรอหลังจากคำขอของไคลเอ็นต์สุดท้ายก่อนที่จะออก ค่าเริ่มต้นคือ 10800 (3 ชั่วโมง) --max_idle_secs=0
จะทำให้กระบวนการของเซิร์ฟเวอร์ 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 ซึ่งระบุเวลาที่แสดงข้อความ