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

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

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

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

--output_filter=regex

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

ค่าทั่วไปสำหรับตัวเลือกนี้มีดังนี้

`--output_filter='^//(first/project|second/project):'` แสดงเอาต์พุตสำหรับแพ็กเกจที่ระบุ
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` ไม่ต้องแสดงเอาต์พุตสำหรับแพ็กเกจที่ระบุ
`--output_filter=` แสดงทุกอย่าง
`--output_filter=DONT_MATCH_ANYTHING` ไม่แสดง

ธงเครื่องมือ

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

--copt=cc-option

ตัวเลือกนี้จะรับอาร์กิวเมนต์ที่จะส่งไปยังคอมไพเลอร์ อาร์กิวเมนต์จะถูกส่งผ่านไปยังคอมไพเลอร์เมื่อใดก็ตามที่มีการเรียกใช้สำหรับการประมวลผลล่วงหน้า การคอมไพล์ และ/หรือการรวมโค้ด C, C++ หรือแอสเซมเมอร์ ระบบจะไม่ส่งค่านี้เมื่อลิงก์

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--tool_java_language_version=version

เวอร์ชันภาษา Java ที่ใช้ในการสร้างเครื่องมือที่ดำเนินการในระหว่างบิลด์ ค่าเริ่มต้นคือ 11

--java_runtime_version=version

ตัวเลือกนี้จะระบุเวอร์ชันของ JVM ที่จะใช้ในการเรียกใช้โค้ดและทำการทดสอบ เช่น

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

ดาวน์โหลด JDK 11 จากที่เก็บระยะไกลและเรียกใช้แอปพลิเคชัน Java โดยใช้ที่เก็บดังกล่าว

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

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

สร้างอรรถศาสตร์

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

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

--compiler=version

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

--android_sdk=label

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีดำเนินการตามคำสั่ง โดยลบล้าง --spawn_strategy (และ --genrule_strategy ด้วย mnemonic Genrule) ตามความสามารถในการจำ ดู--spawn_strategy สำหรับกลยุทธ์ที่รองรับและผลลัพธ์ของกลยุทธ์

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

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

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

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

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

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

เมื่อเรียกใช้การทดสอบ (หรือแอปพลิเคชัน) ระบบจะรวบรวมข้อมูลรันไทม์และข้อกําหนดไว้ในที่เดียวกัน ภายในแผนผังเอาต์พุตของ Bazel โดยทั่วไปแล้ว ต้นไม้ "runfiles" นี้จะได้รับการรูทเป็นพี่น้องของไบนารีหรือการทดสอบที่เกี่ยวข้อง ในระหว่างการเรียกใช้การทดสอบ ระบบอาจเข้าถึงไฟล์รันไทม์โดยใช้เส้นทางของรูปแบบ $TEST_SRCDIR/workspace/packagename/filename ต้นไม้ 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 จะเลือกกฎในพื้นที่ภาษาเดียวกันเป็นหลัก สำหรับกฎหลายรายการที่มีค่ากำหนดเดียวกัน ระบบจะเลือกกฎที่ปรากฏขึ้นก่อนในไฟล์ 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 นั้นขึ้นอยู่กับเฟรมเวิร์กการทดสอบที่รับผิดชอบในการเรียกใช้การทดสอบ ซึ่งอาจเป็นนิพจน์ทั่วไป สตริงย่อย หรือนิพจน์ทั่วไปแบบนิพจน์ทั่วไป --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 หากเป็นไปได้ เพื่อให้คัดลอกและวางลงใน Command Prompt ของเชลล์ได้ง่ายๆ (วงเล็บรอบๆ มีไว้เพื่อปกป้องเชลล์จากการเรียกใช้ cd และ exec อย่าลืมคัดลอกวงเล็บเหล่านี้ด้วย!) อย่างไรก็ตาม คำสั่งบางรายการจะใช้ภายใน Bazel เช่น การสร้างต้นไม้สัญลักษณ์ลิงก์ จะไม่มีบรรทัดคำสั่งที่จะแสดงสำหรับรายการเหล่านี้

--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 จะไม่ดําเนินการใดๆ เลย (ออกด้วยค่า 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 จะไม่บังคับให้สร้างเป้าหมายใหม่หากทรัพยากร Dependency ไม่เปลี่ยนแปลง

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

หากตั้งค่าตัวเลือกนี้เป็น "อัตโนมัติ" (ค่าเริ่มต้น) 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

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

เข้าถึงสภาพแวดล้อมได้จากภายในการทดสอบโดยใช้ System.getenv("var") (Java), getenv("var") (C หรือ C++),

--run_under=command-prefix

ซึ่งจะระบุคำนำหน้าที่จะใส่ไว้หน้าคำสั่งทดสอบก่อนเรียกใช้ ระบบจะแบ่ง command-prefix เป็นคำโดยใช้กฎการแยกออกเป็นโทเค็นของ Bourne shell จากนั้นจะใส่รายการคำไว้ข้างหน้าคำสั่งที่จะดำเนินการ

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

มีข้อควรระวังบางประการดังนี้

  • 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 ซึ่งเปิดใช้โดยค่าเริ่มต้นจะทําให้ระบบรวมข้อกําหนดในคําจํากัดความที่ไม่ใช่เป้าหมายไว้ในกราฟข้อกําหนดซึ่งการค้นหาจะทํางาน

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

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

ตัวอย่างเช่น คอมไพเลอร์ C++ สําหรับการกําหนดค่าปัจจุบัน นี่เป็นตัวแปร $(CC) ในสภาพแวดล้อม "Make" จึงจำเป็นต้องมีแฟล็ก --show_make_env

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

เช่น ไดเรกทอรีเอาต์พุต bazel-bin สำหรับการกำหนดค่าปัจจุบัน การดำเนินการนี้รับประกันว่าถูกต้องแม้ในกรณีที่สร้าง bazel-bin 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

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

แฟล็กนี้ไม่ส่งผลต่อ 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

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