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

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

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

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

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

ตัวเลือก

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

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

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

--package_path

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

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

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

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

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

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

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

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++ หรือแอสเซมเบลอร์ ระบบจะไม่ส่งค่านี้เมื่อลิงก์

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

  % 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

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

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

สําหรับคอมไพเลอร์ 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 พร้อมกันไม่ได้

--[no]output_symbol_counts

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

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

--java_language_version=version

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

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

คอมไพล์และอนุญาตเฉพาะคอนสตรัคต์ที่เข้ากันได้กับข้อกำหนดของ Java 8 ค่าเริ่มต้นคือ 11 --> ค่าที่เป็นไปได้คือ 8, 9, 10, 11, 14 และ 15 และอาจขยายได้โดย registering custom Java toolchains using 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 โดยใช้ JDK ดังกล่าว

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

สร้างความหมาย

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

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

ตัวเลือก --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 ซึ่งจะตั้งค่าโดยไม่ขึ้นอยู่กับสภาพแวดล้อมการเรียกใช้

คุณระบุ Flag --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 ทั้งหมดใน Closure แบบทรานซิทีฟของเป้าหมายที่จะสร้างตามคำขอดำเนินการ --experimental_extra_action_filter จะจำกัดการกำหนดเวลาไว้ที่ extra_actions ของป้ายกำกับเจ้าของที่ตรงกับนิพจน์ทั่วไปที่ระบุ

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

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

--host_cpu=cpu

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

--fat_apk_cpu=cpu[,cpu]*

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

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

โหมด:

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

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

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

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

--force_ignore_dash_static

หากตั้งค่า Flag นี้ ระบบจะไม่สนใจตัวเลือก -static ใน linkopts ของไฟล์ BUILD กฎ cc_* การดำเนินการนี้มีไว้เพื่อแก้ปัญหาชั่วคราวสำหรับบิลด์ 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++ ทั้งหมดระหว่างบิลด์ Bazel จะค้นหาไฟล์ CROSSTOOL ในตำแหน่งนั้นและใช้ไฟล์ดังกล่าวเพื่อกำหนดการตั้งค่าสำหรับ --compiler โดยอัตโนมัติ

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีเรียกใช้คําสั่ง โดยลบล้าง --spawn_strategy (และ --genrule_strategy ที่มี mnemonicGenrule) ตาม mnemonic แต่ละรายการ ดู --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 วินาที และหลังจากนั้นระบบจะรายงานความคืบหน้าทุกๆ นาที

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

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

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

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

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

--save_temps

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

ปัจจุบัน Flag --save_temps ใช้ได้กับกฎ cc_* เท่านั้น

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

  % bazel test --test_size_filters=small,medium //foo:all
และ 
  % bazel test --test_size_filters=-large,-enormous //foo:all

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=lang[,lang]*

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

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

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

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

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

--verbose_failures

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

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

สถานะ Workspace

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

--workspace_status_command=program

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

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

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

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

จากนั้น 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 มิถุนายน 2 01 44 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 โปรดดูรายละเอียดจาก Build Encyclopedia เมื่อกฎตั้งค่า stamp = -1 (ค่าเริ่มต้นสำหรับกฎ *_binary) ตัวเลือกนี้จะกำหนดว่าเปิดใช้การประทับตราหรือไม่

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

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

เปลี่ยนคำนำหน้าของลิงก์สัญลักษณ์ที่สะดวกซึ่งสร้างขึ้น ค่าเริ่มต้นสำหรับคำนำหน้าลิงก์สัญลักษณ์คือ 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)

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

--[no]use_action_cache

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

--starlark_cpu_profile=_file_

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

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

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

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

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

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

ตัวเลือกที่สําคัญ

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

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

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

การทดสอบที่ทำงานอยู่

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

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

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

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

หากตั้งค่าตัวเลือกนี้เป็น "auto" (ค่าเริ่มต้น) ไว้ 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 หรือ 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 รันไทม์จากกลุ่มเดียวกันแสดงผลลัพธ์เป็น "ผ่าน" และ "ไม่ผ่าน" การทดสอบจะได้รับสถานะ "ไม่เสถียร" (เว้นแต่การรันไทม์อื่นๆ ที่ไม่ผ่านจะทําให้ทดสอบไม่ผ่าน)

หากระบุตัวเลขเพียงตัวเดียว การทดสอบทั้งหมดจะทํางานตามจํานวนนั้น หรือจะระบุนิพจน์ทั่วไปโดยใช้ไวยากรณ์ ดังนี้ 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 ระบบจะรับค่านี้มาจากสภาพแวดล้อมเชลล์ที่ใช้เพื่อเริ่มคำสั่ง 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 เองได้ด้วย Flag --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 คำสั่ง clean จะนําเฉพาะลําดับชั้นฐานเอาต์พุตทั้งหมดออก ซึ่งนอกจากเอาต์พุตของบิลด์แล้ว ยังมีไฟล์ชั่วคราวทั้งหมดที่ Bazel สร้างขึ้นด้วย และยังหยุดเซิร์ฟเวอร์ Bazel หลังจากล้างข้อมูล ซึ่งเทียบเท่ากับคำสั่ง shutdown เช่น หากต้องการล้างดิสก์และการติดตามหน่วยความจำทั้งหมดของอินสแตนซ์ Bazel คุณอาจระบุสิ่งต่อไปนี้

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น "แสดงตําแหน่งของคําจํากัดความ (ในไฟล์ BUILD) ของ genrules ทั้งหมดที่จําเป็นสําหรับสร้างการทดสอบทั้งหมดในลําดับชั้น 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_ ซึ่งต้องใช้อาร์กิวเมนต์แบบจำนวนเต็ม (เป็น 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: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีรูทการดําเนินการภายใต้ output_base ไดเรกทอรีนี้เป็นรูทของไฟล์ทั้งหมดที่เข้าถึงได้สำหรับคำสั่งที่ดำเนินการระหว่างการสร้าง และเป็นไดเรกทอรีการทำงานสำหรับคำสั่งเหล่านั้น หากไดเรกทอรี Workspace เขียนได้ ระบบจะวางไฟล์ซิงค์ชื่อ bazel-<workspace> ที่ชี้ไปยังไดเรกทอรีนี้

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

ตัวอย่างเช่น คอมไพเลอร์ C++ สําหรับการกําหนดค่าปัจจุบัน นี่คือตัวแปร $(CC) ในสภาพแวดล้อม "Make" จึงต้องใช้ Flag --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

คำสั่ง 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 ขึ้นไปเท่านั้น โปรดทราบว่าไม่จำเป็นต้องใช้ Flag --incremental เมื่อใช้ --split_apks

--start_app

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

--debug_app

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

--start=_start_type_

วิธีเริ่มแอปหลังจากติดตั้ง _start_type_ ที่รองรับ ได้แก่

  • 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 จะแสดงผลไปยัง stdout โดยการดัมพ์สถานะภายในของเซิร์ฟเวอร์ Bazel คําสั่งนี้มีไว้สําหรับนักพัฒนาซอฟต์แวร์ Bazel เป็นหลัก ดังนั้นจึงไม่มีการระบุเอาต์พุตของคําสั่งนี้และอาจมีการเปลี่ยนแปลงได้

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

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

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

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

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

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

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

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

canonicalize-flags

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

คุณสามารถใช้ตัวเลือก --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 รายการจะทำงานพร้อมกัน (เนื่องจากโอเปอเรเตอร์ &amp; ของเชลล์) โดยแต่ละรายการจะใช้อินสแตนซ์เซิร์ฟเวอร์ 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

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

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

--host_jvm_args=string

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

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

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

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

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

--max_idle_secs=n

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

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

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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