หน้านี้ครอบคลุมตัวเลือกที่ใช้ได้กับคำสั่ง 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%
ระบบจะนำเส้นทางไปโดยสัมพัทธ์กับไดเรกทอรี Bazel ที่ล้อมรอบอยู่ที่ใกล้ที่สุด เช่น หากไดเรกทอรีการทำงานคือ/home/bob/clients/bob_client/bazel/foo
สตริง%workspace%
ในเส้นทางแพ็กเกจจะขยายเป็น/home/bob/clients/bob_client/bazel
- ระบบจะดำเนินการอื่นๆ กับไดเรกทอรีการทำงาน
ซึ่งโดยปกติจะไม่ใช่สิ่งที่คุณต้องการ และยังอาจแสดงผิดปกติหากคุณใช้ 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
ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งผ่านไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับที่คอมไพล์ในการกำหนดค่า exec ตัวเลือกนี้คล้ายคลึงกับตัวเลือก --copt
แต่จะใช้เฉพาะกับการกำหนดค่าการดำเนินการเท่านั้น
--host_conlyopt=cc-option
ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับ C ที่คอมไพล์ในการกำหนดค่า exec ตัวเลือกนี้คล้ายคลึงกับตัวเลือก --conlyopt
แต่จะใช้เฉพาะกับการกำหนดค่าการดำเนินการเท่านั้น
--host_cxxopt=cc-option
ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์สำหรับไฟล์ต้นฉบับ C++ ที่คอมไพล์ในการกำหนดค่า exec ตัวเลือกนี้คล้ายคลึงกับตัวเลือก --cxxopt
แต่จะใช้เฉพาะกับการกำหนดค่าการดำเนินการเท่านั้น
--host_linkopt=linker-option
ตัวเลือกนี้ใช้อาร์กิวเมนต์ที่จะส่งไปยังตัวลิงก์สำหรับไฟล์ต้นฉบับที่คอมไพล์ในการกำหนดค่า exec ตัวเลือกนี้คล้ายคลึงกับตัวเลือก --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
พร้อมกันไม่ได้
--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 โดยใช้
ค่าเริ่มต้นคือ 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 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 ที่ควรจะใช้ในการสร้างเครื่องมือโฮสต์
--android_platforms=platform[,platform]*
แพลตฟอร์มสำหรับสร้างกฎ deps
จาก android_binary
แบบสกรรม (โดยเฉพาะสำหรับทรัพยากร Dependency แบบเนทีฟ เช่น C++) ตัวอย่างเช่น หาก cc_library
ปรากฏในdeps
แบบสับเปลี่ยนของกฎ android_binary
จะมีการสร้าง 1 ครั้งสำหรับแต่ละแพลตฟอร์มที่ระบุด้วย
--android_platforms
สำหรับกฎ android_binary
และรวมอยู่ในเอาต์พุตสุดท้าย
ไม่มีค่าเริ่มต้นสำหรับแฟล็กนี้ เพราะคุณจะต้องกำหนดและใช้แพลตฟอร์ม 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
ระบบจะปิดใช้ 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
ดู --android_platforms
เพิ่มเติม
--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
เพื่อคอมไพล์โค้ดในการกำหนดค่า exec เช่น สำหรับเครื่องมือที่ทำงานระหว่างบิลด์ จุดประสงค์หลักของ Flag นี้คือ
เปิดใช้การคอมไพล์ข้ามกัน
--javabase=(label)
ตัวเลือกนี้ตั้งค่าป้ายกำกับของการติดตั้ง Java พื้นฐานเพื่อใช้กับ Bazel Run, Bazel test และไบนารี Java ที่สร้างขึ้นโดยกฎ java_binary
และ java_test
ตัวแปร"ผู้ผลิต" JAVABASE
และ JAVA
ได้มาจากตัวเลือกนี้
--host_javabase=label
ตัวเลือกนี้จะตั้งค่าป้ายกำกับของการติดตั้ง Java พื้นฐานเพื่อใช้ในการกำหนดค่า exec เช่น สำหรับเครื่องมือสร้างโฮสต์ซึ่งรวมถึง JavaBuilder และ Singlejar
ตัวเลือกนี้จะไม่เลือกคอมไพเลอร์ Java ที่ใช้ในการคอมไพล์ไฟล์ซอร์สของ Java คุณเลือกคอมไพเลอร์ได้โดยการตั้งค่าตัวเลือก --java_toolchain
กลยุทธ์การดำเนินการ
ตัวเลือกเหล่านี้มีผลต่อวิธีที่ Bazel จะเรียกใช้บิลด์ ซึ่งไม่ควรมีผลกระทบที่สำคัญใดๆ ต่อไฟล์เอาต์พุตที่สร้างโดยบิลด์ โดยส่วนใหญ่แล้ว ผลลัพธ์หลักคือ ความเร็วของบิลด์
--spawn_strategy=strategy
ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีดำเนินการตามคำสั่ง
standalone
จะทำให้มีการเรียกใช้คำสั่งเป็นกระบวนการย่อยภายในเครื่อง ค่านี้จะเลิกใช้งาน โปรดใช้local
แทนsandboxed
จะทำให้เรียกใช้คำสั่งภายในแซนด์บ็อกซ์ในเครื่องภายใน ซึ่งกำหนดให้ไฟล์อินพุต การอ้างอิงข้อมูล และเครื่องมือทั้งหมดแสดงเป็นทรัพยากร Dependency โดยตรงในแอตทริบิวต์srcs
,data
และtools
Bazel จะเปิดใช้แซนด์บ็อกซ์ในเครื่องโดยค่าเริ่มต้นบนระบบที่รองรับการดำเนินการแซนด์บ็อกซ์local
จะทำให้มีการเรียกใช้คำสั่งเป็นกระบวนการย่อยภายในเครื่องworker
จะทำให้ออกคำสั่งโดยใช้ผู้ปฏิบัติงานถาวร (หากมี)docker
จะทำให้เรียกใช้คำสั่งภายในแซนด์บ็อกซ์ของ Docker ในเครื่อง คุณต้องติดตั้ง Docker ก่อนจึงจะดำเนินการดังกล่าวได้remote
จะทำให้เรียกใช้คำสั่งจากระยะไกล ซึ่งจะใช้ได้เฉพาะในกรณีที่มีการกำหนดค่าผู้ดำเนินการระยะไกลแยกกัน
--strategy mnemonic=strategy
ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีดำเนินการตามคำสั่ง โดยลบล้าง --spawn_strategy (และ --genrule_strategy ที่มีกฎการช่วยจำ) แบบรายบุคคล ดูกลยุทธ์ที่รองรับและผลกระทบได้ที่ --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=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
ตัวเลือกนี้ทำให้เบลล์แสดงข้อความความคืบหน้าไม่เกิน 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)FORMATTED_DATE
: เวลาของบิลด์ที่จัดรูปแบบเป็นyyyy MMM d HH mm ss EEE
(เช่น 2023 มิ.ย. 2014 29 ศ.) ใน UTC
ใน 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)
แฟล็กชั่วคราวสำหรับการทดสอบการเปลี่ยนแปลงระดับการเข้าถึงเริ่มต้นแบบเบเซล ไม่ได้มีไว้เพื่อการใช้งานทั่วไป แต่บันทึกไว้เพื่อความครบถ้วนสมบูรณ์
--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 ตรวจพบการเปลี่ยนแปลงในการทดสอบหรือการอ้างอิง
- การทดสอบจะทําเครื่องหมายเป็น
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
: รหัสกระบวนการของกระบวนการของเซิร์ฟเวอร์ Bazelserver_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
จะวิเคราะห์โปรไฟล์การติดตาม 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 ที่ใช้โดยกระบวนการของเซิร์ฟเวอร์ 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 โดยระบุเวลาที่ข้อความจะแสดง