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

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

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

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

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

ตัวเลือก

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

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

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

--package_path

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

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

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

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

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

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

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

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

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

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

คุณระบุ Flag --action_env นี้ได้หลายครั้ง หากมีการกําหนดค่าให้กับตัวแปรเดียวกันใน Flag --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 จะขึ้นต้นด้วยชื่อกฎ android_binary โดยมี "lib" เช่น หากชื่อของ 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 แทนการระบุแฟล็กนี้

--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 run, bazel test และสำหรับไบนารี 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 ทําให้ระบบเรียกใช้คําสั่งภายในแซนด์บ็อกซ์บนเครื่อง โดยกำหนดให้ไฟล์อินพุต ทรัพยากร Dependency และเครื่องมือทั้งหมดต้องแสดงการขึ้นต่อกันโดยตรงในแอตทริบิวต์ 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 บางรายการ ดูรายละเอียดเกี่ยวกับการจับคู่นิพจน์ทั่วไปได้ที่ --per_file_copt ดู--spawn_strategy สำหรับกลยุทธ์ที่รองรับและผลลัพธ์ของกลยุทธ์

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

  • ตัวอย่างเช่น --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' จะเรียกใช้ 'Compiling //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) ตามด้วย [-|*Flo] (เช่น --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1) การตั้งค่าสถานะเป็นอิสระ อาจมีการตั้งค่า 1 หรือทั้ง 2 อย่างก็ได้ โดยค่าเริ่มต้น Bazel จะประมาณปริมาณ RAM และจำนวนแกน CPU จากการกำหนดค่าของระบบในเครื่องโดยตรง

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

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

เช่นเดียวกับ 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

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

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=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 นั้นขึ้นอยู่กับเฟรมเวิร์กการทดสอบที่รับผิดชอบในการเรียกใช้การทดสอบ ซึ่งอาจเป็นนิพจน์ทั่วไป สตริงย่อย หรือนิพจน์ทั่วไปแบบนิพจน์ทั่วไป --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

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

--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 หากเป็นไปได้ เพื่อให้คัดลอกและวางลงใน Command Prompt ของเชลล์ได้ง่ายๆ (วงเล็บรอบๆ มีไว้เพื่อปกป้องเชลล์จากการเรียกใช้ 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)

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

หากคําสั่งสถานะเวิร์กสเปซไม่สําเร็จ (ออกไม่ใช่ 0) ไม่ว่าด้วยเหตุผลใดก็ตาม การสร้างจะล้มเหลว

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

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

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

--[no]stamp

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

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

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

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

แพลตฟอร์ม

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

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

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

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

--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 หรือ LONG เนื่องจากค่าเหล่านี้มีระยะเวลานานเกินไป

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

เมื่อไบนารีเป็นการทดสอบ ไดเรกทอรีการทำงานปัจจุบันจะเป็นรูท exec และระบบจะพยายามอย่างสุจริตเพื่อจำลองสภาพแวดล้อมที่มักจะใช้ทดสอบ แต่การจําลองยังไม่สมบูรณ์ และการทดสอบที่มีหลายชาดไม่สามารถทํางานด้วยวิธีนี้ได้ (ใช้--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 รายการ ได้แก่ query และ cquery ความแตกต่างหลักระหว่างคําสั่ง 2 รายการนี้คือ query จะทํางานหลังจากระยะการโหลด และ cquery จะทํางานหลังจากระยะการวิเคราะห์ เครื่องมือเหล่านี้เป็นความช่วยเหลือที่มีคุณค่าอย่างยิ่งสำหรับงานวิศวกรรมซอฟต์แวร์หลายอย่าง

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

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

เครื่องมือ Query ยอมรับตัวเลือกบรรทัดคำสั่งหลายรายการ --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: Absolute Path ไปยังไดเรกทอรีเอาต์พุตใต้รูทการดําเนินการที่ใช้สำหรับไฟล์ทั้งหมดที่สร้างขึ้นจริงจากคําสั่งบิลด์ หากไดเรกทอรีของพื้นที่ทำงานเขียนได้ ระบบจะวางลิงก์สัญลักษณ์ชื่อ bazel-out ไว้ที่นั่นเพื่อชี้ไปยังไดเรกทอรีนี้

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

  • bazel-bin, bazel-testlogs, bazel-genfiles: รายงานเส้นทางสัมบูรณ์ไปยังไดเรกทอรี bazel-* ซึ่งมีโปรแกรมที่บิลด์สร้างขึ้น ซึ่งโดยปกติแล้ว (แต่ก็ไม่เสมอไป) จะเป็นค่าเดียวกับ bazel-* symlink ที่สร้างขึ้นไดเรกทอรีเวิร์กสเปซพื้นฐานหลังจากการบิลด์สําเร็จ อย่างไรก็ตาม หากไดเรกทอรีของพื้นที่ทํางานเป็นแบบอ่านอย่างเดียว ระบบจะไม่สร้าง bazel-* symlink สคริปต์ที่ใช้ค่าที่ bazel info รายงานแทนที่จะถือว่ามีลิงก์สัญลักษณ์อยู่จะมีประสิทธิภาพมากกว่า
  • สภาพแวดล้อม "Make" ที่สมบูรณ์ หากระบุ Flag --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 symlink ไม่ได้ด้วยเหตุผลบางประการ (เช่น หากคุณสร้างจากไดเรกทอรีที่อ่านอย่างเดียว)

% 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 mobile-install

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

การติดตามความทรงจำ

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

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

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

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

canonicalize-flags

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

คุณสามารถใช้ตัวเลือก --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 "ด้านซ้าย") แต่เปลี่ยนชื่อเพื่อไม่ให้สับสนกับ Flag การสร้าง --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

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