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

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

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

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

ตัวเลือก

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

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

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

--package_path

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

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

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

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

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

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

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

--output_filter=regex

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

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

แฟล็กเครื่องมือ

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--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 แต่ละไฟล์

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

สำหรับคอมไพเลอร์ LLVM อาร์กิวเมนต์ยังเป็นไดเรกทอรีที่ใช้ดัมพ์ไฟล์ข้อมูลโปรไฟล์ LLVM ดิบด้วย ตัวอย่างเช่น --fdo_instrument=/path/to/rawprof/dir/

ใช้ตัวเลือก --fdo_instrument และ --fdo_optimize พร้อมกันไม่ได้

--fdo_optimize=profile-zip

ตัวเลือก --fdo_optimize จะใช้ข้อมูลโปรไฟล์ไฟล์ต่อออบเจ็กต์เพื่อเพิ่มประสิทธิภาพ FDO (การเพิ่มประสิทธิภาพที่มุ่งเน้นความคิดเห็น) เมื่อคอมไพล์ สำหรับ GCC อาร์กิวเมนต์ที่ระบุคือไฟล์ ZIP ที่มีโครงสร้างไฟล์ .gcda ที่สร้างไว้ก่อนหน้านี้ของไฟล์ .gcda ซึ่งมีข้อมูลโปรไฟล์ของไฟล์ .o แต่ละไฟล์

หรืออาร์กิวเมนต์ที่ระบุอาจชี้ไปยังโปรไฟล์อัตโนมัติที่ระบุโดยส่วนขยาย .afdo ก็ได้

สำหรับคอมไพเลอร์ LLVM อาร์กิวเมนต์ที่ระบุควรชี้ไปยังไฟล์เอาต์พุตโปรไฟล์ LLVM ที่จัดทำดัชนีซึ่งจัดเตรียมโดยเครื่องมือ llvm-profdata และควรมีส่วนขยาย .profdata

ใช้ตัวเลือก --fdo_instrument และ --fdo_optimize พร้อมกันไม่ได้

--java_language_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

จะใช้ VM ของเซิร์ฟเวอร์เพื่อเปิดไบนารีของ Java ทั้งหมดและตั้งค่าขนาดฮีปเริ่มต้นสำหรับ VM เป็น 256 MB

--javacopt=javac-option

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

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

จะสร้าง java_binary อีกครั้งโดยใช้ข้อมูลการแก้ไขข้อบกพร่องเริ่มต้นของ javac (แทนข้อมูลเริ่มต้นของ bazel)

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

  -source 8 -target 8 -encoding UTF-8

--strict_java_deps (default|strict|off|warn|error)

ตัวเลือกนี้จะควบคุมว่า Javac จะตรวจสอบการขึ้นต่อกันโดยตรงที่ขาดหายไปหรือไม่ เป้าหมาย Java ต้องประกาศเป้าหมายที่ใช้โดยตรงทั้งหมดอย่างชัดแจ้งเป็นทรัพยากร Dependency Flag นี้จะสั่งให้ javac ระบุ Jar ที่ใช้ในการตรวจสอบประเภทไฟล์ Java แต่ละไฟล์จริง และเตือน/แสดงข้อผิดพลาดหากไฟล์เหล่านั้นไม่ใช่เอาต์พุตของข้อกำหนดโดยตรงของเป้าหมายปัจจุบัน

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

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

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

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

ตัวเลือก --compilation_mode (มักย่อเป็น -c โดยเฉพาะ -c opt) จะใช้อาร์กิวเมนต์ของ fastbuild, dbg หรือ opt และส่งผลต่อตัวเลือกการสร้างโค้ด C/C++ ต่างๆ เช่น ระดับการเพิ่มประสิทธิภาพและความสมบูรณ์ของตารางการแก้ไขข้อบกพร่อง Bazel ใช้ไดเรกทอรีเอาต์พุตที่แตกต่างกันสำหรับโหมดการคอมไพล์แต่ละโหมด คุณจึงสลับโหมดต่างๆ ได้โดยไม่ต้องสร้างใหม่ทุกครั้ง

• fastbuild หมายความว่าสร้างเร็วที่สุดเท่าที่จะเป็นไปได้ คือสร้างข้อมูลการแก้ไขข้อบกพร่องให้น้อยที่สุด (-gmlt -Wl,-S) และไม่ต้องเพิ่มประสิทธิภาพ ตัวเลือกนี้เป็นค่าเริ่มต้น หมายเหตุ: ระบบจะไม่ตั้งค่า -DNDEBUG
• dbg หมายถึงสร้างที่มีการเปิดใช้การแก้ไขข้อบกพร่อง (-g) เพื่อให้คุณใช้ gdb (หรือโปรแกรมแก้ไขข้อบกพร่องอื่น) ได้
• opt หมายถึงบิลด์ที่เปิดใช้การเพิ่มประสิทธิภาพและปิดใช้การเรียก assert() (-O2 -DNDEBUG) ระบบจะไม่สร้างข้อมูลการแก้ไขข้อบกพร่องในโหมด opt เว้นแต่คุณจะส่ง --copt -g ด้วย

--cpu=cpu

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

--action_env=VAR=VALUE

ระบุชุดตัวแปรสภาพแวดล้อมที่ใช้ได้ในระหว่างการดำเนินการทั้งหมด คุณระบุตัวแปรได้ด้วยชื่อ ซึ่งในกรณีนี้จะนำค่ามาจากสภาพแวดล้อมการเรียกใช้ หรือโดยคู่ name=value ซึ่งจะตั้งค่าโดยไม่ขึ้นอยู่กับสภาพแวดล้อมการเรียกใช้

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

แพลตฟอร์มสำหรับสร้างกฎ deps แบบทรานซิชันของ android_binary (โดยเฉพาะสำหรับทรัพยากร Dependency แบบเนทีฟ เช่น C++) ตัวอย่างเช่น หาก cc_library ปรากฏใน deps ทรานซิชันของกฎ android_binary ระบบจะสร้างขึ้นครั้งเดียวสำหรับแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms สำหรับกฎ android_binary และรวมไว้ในเอาต์พุตสุดท้าย

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

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

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

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

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

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

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

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

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

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

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

--dynamic_mode=mode

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

โหมด

• auto: แปลงเป็นโหมดที่ขึ้นอยู่กับแพลตฟอร์ม default สำหรับ Linux และ off สำหรับ 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 และลิงก์จะสร้างไฟล์ปฏิบัติการที่ไม่ขึ้นอยู่กับตำแหน่ง ("-พาย") ค่าเริ่มต้นคือปิดใช้

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

เลิกใช้งานแล้ว ซึ่งไม่ควรระบุโดยตรง

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

--[no]build_runfile_links

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

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

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

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

--[no]use_ijars

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

  % bazel test --test_size_filters=small,medium //foo:all

และ

  % bazel test --test_size_filters=-large,-enormous //foo:all

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

  % bazel test --test_lang_filters=foo,bar //baz/...

จะทดสอบเฉพาะเป้าหมายที่เป็นอินสแตนซ์ของ foo_test หรือ bar_test ใน //baz/... ส่วน

  % bazel test --test_lang_filters=-foo,-bar //baz/...

จะทดสอบเป้าหมายทั้งหมดใน //baz/... ยกเว้นอินสแตนซ์ foo_test และ bar_test

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

ผู้ใช้อาจต้องการเลือกค่าระหว่างการสร้างเป้าหมายกลุ่มเล็กๆ สลับไปมาเป็นประจำ (เช่น ระหว่างรอบการทดสอบการแก้ไข-คอมไพล์) และเป้าหมายกลุ่มใหญ่ (เช่น เมื่อสร้างพื้นที่ทำงานใหม่หรือเรียกใช้การทดสอบการถดถอย) ในกรณีแรก ข้อมูลผลลัพธ์จะมีประโยชน์มาก แต่ในกรณีหลังจะมีประโยชน์น้อยกว่า เช่นเดียวกับตัวเลือกทั้งหมด คุณสามารถระบุตัวเลือกนี้โดยนัยผ่านไฟล์ .bazelrc

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

--sandbox_debug

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

--subcommands (-s)

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

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

ระบบจะพิมพ์คำสั่งเป็นไวยากรณ์ที่เข้ากันได้กับ Bourne shell หากเป็นไปได้ เพื่อให้คัดลอกและวางลงใน Command Prompt ของเชลล์ได้ง่ายๆ (วงเล็บรอบๆ มีไว้เพื่อปกป้องเชลล์จากการเรียกใช้ cd และ exec อย่าลืมคัดลอกวงเล็บเหล่านี้ด้วย!) อย่างไรก็ตาม คำสั่งบางอย่างมีการใช้งานภายใน Bazel เช่น การสร้างต้นไม้ Symlink จะไม่มีบรรทัดคำสั่งที่จะแสดงสำหรับรายการเหล่านี้

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

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

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

--verbose_failures

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

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

สถานะ Workspace

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

--workspace_status_command=program

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

ค่าของแฟล็กต้องเป็นเส้นทางไปยังโปรแกรมเนทีฟ ใน 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)
  • FORMATTED_DATE: เวลาของบิลด์ที่จัดรูปแบบเป็น yyyy MMM d HH mm ss EEE(เช่น 2023 มิถุนายน 2 01 44 29 ศุกร์) ใน UTC

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

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

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

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

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

--[no]stamp

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

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

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

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

เปลี่ยนคำนำหน้าของลิงก์สัญลักษณ์แบบอำนวยความสะดวกที่สร้างขึ้น ค่าเริ่มต้นสำหรับคำนำหน้าลิงก์สัญลักษณ์คือ bazel- ซึ่งจะสร้างลิงก์สัญลักษณ์ bazel-bin, bazel-testlogs และ bazel-genfiles

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

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

• ระงับการสร้างสัญลักษณ์ลิงก์: --symlink_prefix=/ จะทำให้ Bazel ไม่สร้างหรืออัปเดตสัญลักษณ์ลิงก์ใดๆ รวมถึงสัญลักษณ์ลิงก์ bazel-out และ bazel-<workspace> ใช้ตัวเลือกนี้เพื่อระงับการสร้างลิงก์สัญลักษณ์ทั้งหมด

• ลดความยุ่งเหยิง: --symlink_prefix=.bazel/ จะทำให้ Bazel สร้าง ลิงก์สัญลักษณ์ที่เรียกว่า bin (ฯลฯ) ภายในไดเรกทอรีที่ซ่อนอยู่ .bazel

--platform_suffix=string

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

--default_visibility=(private|public)

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

• --bazelrc=/dev/null
• --nokeep_state_after_build

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

• --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 หรือจำนวนการทดสอบที่ผ่านทั้งหมด การทดสอบที่ไม่ผ่านความพยายามทั้งหมดที่อนุญาตจะถือว่าไม่ผ่าน

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

เมื่อไบนารีเป็นการทดสอบ ไดเรกทอรีที่ใช้งานอยู่ในปัจจุบันจะเป็นรูทของปฏิบัติการและพยายามโดยสุจริตเพื่อจำลองการทดสอบสภาพแวดล้อม แต่การจําลองยังไม่สมบูรณ์ และการทดสอบที่มีหลายชาดไม่สามารถทํางานด้วยวิธีนี้ได้ (ใช้--test_sharding_strategy=disabledตัวเลือกบรรทัดคําสั่งเพื่อแก้ปัญหานี้ได้)

ตัวแปรสภาพแวดล้อมเพิ่มเติมต่อไปนี้ยังพร้อมใช้งานสำหรับไบนารีด้วย

• BUILD_WORKSPACE_DIRECTORY: รูทของพื้นที่ทำงานที่มีการเรียกใช้บิลด์
• BUILD_WORKING_DIRECTORY: ไดเรกทอรีที่ใช้งานอยู่ในปัจจุบันซึ่งใช้เรียกใช้ Bazel

ตัวอย่างเช่น สามารถใช้ข้อมูลเหล่านี้เพื่อตีความชื่อไฟล์ในบรรทัดคำสั่งในลักษณะที่ใช้งานง่าย

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

--run_under=command-prefix

ซึ่งจะมีผลเหมือนกับตัวเลือก --run_under สำหรับ bazel test (ดูด้านบน) เว้นแต่จะมีผลกับคำสั่งที่เรียกใช้โดย bazel run แทนที่จะเป็นการทดสอบที่เรียกใช้โดย bazel test และไม่สามารถเรียกใช้ภายใต้ป้ายกำกับ

การกรองเอาต์พุตของการบันทึกจาก Bazel

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

ตัวอย่างเช่น bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

การดำเนินการทดสอบ

bazel run ยังดำเนินการกับไบนารีการทดสอบได้ด้วย ซึ่งจะส่งผลจากการทดสอบในที่ใกล้เคียงกับสภาพแวดล้อมตามที่อธิบายไว้ในการเขียนการทดสอบ โปรดทราบว่าไม่มีอาร์กิวเมนต์ --test_* ที่มีผลกระทบเมื่อเรียกใช้การทดสอบในลักษณะนี้ ยกเว้น --test_arg

การล้างเอาต์พุตการสร้าง

คำสั่ง clean

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

โปรดทราบว่าอินสแตนซ์ Bazel แต่ละรายการเชื่อมโยงกับเวิร์กスペースเดียว ดังนั้นคำสั่ง clean จะลบเอาต์พุตทั้งหมดออกจากบิลด์ทั้งหมดที่คุณทำกับอินสแตนซ์ Bazel นั้นในเวิร์กスペースนั้น

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น "แสดงตำแหน่งของคำจำกัดความ (ในไฟล์ BUILD) ของกฎ Gen ทั้งหมดที่จำเป็นในการสร้างการทดสอบทั้งหมดในทรี PEBL"

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

การค้นหากราฟการดําเนินการ

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

เครื่องมือนี้ยอมรับตัวเลือกบรรทัดคำสั่งหลายรายการ --output เลือกรูปแบบเอาต์พุต รูปแบบเอาต์พุตเริ่มต้น (text) เป็นรูปแบบที่มนุษย์อ่านได้ ให้ใช้ proto หรือ textproto สำหรับรูปแบบที่เครื่องอ่านได้ สิ่งที่น่าสังเกตคือคําสั่ง aquery จะทํางานบนบิลด์ Bazel ปกติและรับชุดตัวเลือกที่ใช้ได้ในระหว่างบิลด์

รองรับชุดฟังก์ชันเดียวกับที่ใช้ได้กับ query แบบดั้งเดิม แต่ใช้กับ siblings, buildfiles และ tests ไม่ได้

ดูรายละเอียดเพิ่มเติมได้ที่ข้อความค้นหากราฟการดำเนินการ

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

help

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

--[no]long (-l)

โดยค่าเริ่มต้น bazel help [topic] จะพิมพ์เฉพาะสรุปตัวเลือกที่เกี่ยวข้องสำหรับหัวข้อหนึ่งๆ หากระบุตัวเลือก --long ระบบจะพิมพ์ประเภท ค่าเริ่มต้น และคำอธิบายแบบเต็มของแต่ละตัวเลือกด้วย

shutdown

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

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

shutdown ยอมรับตัวเลือก --iff_heap_size_greater_than _n_ 1 รายการ ซึ่งต้องใช้อาร์กิวเมนต์จำนวนเต็ม (เป็น MB) หากระบุค่านี้ ระบบจะปิดระบบโดยขึ้นอยู่กับปริมาณหน่วยความจำที่ใช้ไป ซึ่งมีประโยชน์สำหรับสคริปต์ที่เริ่มการบิลด์จำนวนมาก เนื่องจากการรั่วไหลของหน่วยความจำในเซิร์ฟเวอร์ Bazel อาจทำให้เซิร์ฟเวอร์ขัดข้องโดยไม่คาดคิดในบางครั้ง การดำเนินการรีสตาร์ทแบบมีเงื่อนไขจะป้องกันไม่ให้เกิดเหตุการณ์นี้

info

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

คำสั่ง info ยังใช้อาร์กิวเมนต์ (ไม่บังคับ) เพียงรายการเดียว ซึ่งเป็นชื่อของคีย์ใดคีย์หนึ่งในรายการด้านล่าง ในกรณีนี้ bazel info key จะพิมพ์เฉพาะค่าของคีย์ดังกล่าว (วิธีนี้สะดวกอย่างยิ่งเมื่อเขียนสคริปต์ Bazel เนื่องจากคุณไม่ต้องส่งผ่านผลลัพธ์ผ่าน sed -ne /key:/s/key://p

ข้อมูลที่ขึ้นอยู่กับการกําหนดค่า

• release: ป้ายกำกับรุ่นสำหรับอินสแตนซ์ Bazel นี้ หรือ "เวอร์ชันพัฒนา" หากไม่ใช่ไบนารีที่ปล่อยแล้ว
• workspaceเส้นทางสัมบูรณ์ไปยังไดเรกทอรีพื้นที่ทำงานฐาน

• install_base: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีการติดตั้งที่อินสแตนซ์ Bazel นี้ใช้สำหรับผู้ใช้ปัจจุบัน Bazel ติดตั้งไฟล์ปฏิบัติการที่จำเป็นภายในใต้ไดเรกทอรีนี้

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

• execution_root: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีรูทการดําเนินการภายใต้ 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 ยอมรับตัวเลือกทั้งหมดที่ควบคุมการวิเคราะห์ทรัพยากร เนื่องจากการกําหนดค่าบางอย่างจะระบุตําแหน่งของไดเรกทอรีเอาต์พุตของบิลด์ ตัวเลือกคอมไพเลอร์ และอื่นๆ

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

--start_app

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

--debug_app

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

--start=_start_type_

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

• NO ไม่เริ่มแอป ซึ่งเป็นค่าเริ่มต้น
• COLD เริ่มแอปจากสถานะปกติหลังจากติดตั้ง
• WARM เก็บรักษาและคืนค่าสถานะของแอปพลิเคชันในการติดตั้งที่เพิ่มขึ้น
• DEBUG รอโปรแกรมแก้ไขข้อบกพร่องก่อนที่จะเริ่มแอปในสถานะที่สะอาดหลังจากติดตั้ง

--adb=path

ระบุไบนารี adb ที่จะใช้

ค่าเริ่มต้นคือการใช้ adb ใน Android SDK ที่ระบุโดย --android_sdk

--adb_arg=serial

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

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

เรียกใช้ adb เป็น

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

คำสั่ง dump จะพิมพ์ไปยังไฟล์ย่อยของสถานะภายในของเซิร์ฟเวอร์ Bazel คำสั่งนี้มีจุดประสงค์หลักเพื่อให้นักพัฒนาซอฟต์แวร์ Bazel ใช้ จึงไม่ได้ระบุเอาต์พุตของคำสั่งนี้และอาจมีการเปลี่ยนแปลง

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

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

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

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

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

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 ที่ใช้โดยกระบวนการเซิร์ฟเวอร์ 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 รายการจะทำงานพร้อมกัน (เนื่องจากโอเปอเรเตอร์ & ของเชลล์) โดยแต่ละรายการจะใช้อินสแตนซ์เซิร์ฟเวอร์ Bazel ที่แตกต่างกัน (เนื่องจากฐานเอาต์พุตต่างกัน) ในทางตรงกันข้าม หากใช้ฐานเอาต์พุตเริ่มต้นในทั้ง 2 คำสั่ง ระบบจะส่งคําขอทั้ง 2 รายการไปยังเซิร์ฟเวอร์เดียวกัน ซึ่งจะจัดการคําขอตามลําดับ โดยสร้าง //foo ก่อน ตามด้วยการสร้าง //bar เพิ่มเติม

--output_user_root=dir

ชี้ไปที่ไดเรกทอรีรากที่สร้างเอาต์พุตและฐานผู้ใช้งาน ไดเรกทอรีต้องไม่มีอยู่หรือเป็นของผู้ใช้ที่โทรออก ในอดีต ระบบอนุญาตให้ชี้ไปที่ไดเรกทอรีที่แชร์กันระหว่างผู้ใช้ต่างๆ แต่ไม่ได้รับอนุญาตแล้ว ซึ่งอาจได้รับอนุญาตเมื่อมีการแก้ไขปัญหา #11100 แล้ว

หากระบุตัวเลือก --output_base ระบบจะลบล้างการใช้ --output_user_root เพื่อคํานวณฐานของเอาต์พุต

ตำแหน่งฐานผู้ใช้งานจะคำนวณตาม --output_user_root รวมถึงข้อมูลระบุตัวตน MD5 ของไบนารีแบบฝังของ Bazel

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

--server_javabase=dir

ระบุเครื่องเสมือน Java ที่ Bazel เองทำงาน ค่าต้องเป็นเส้นทางไปยังไดเรกทอรีที่มี JDK หรือ JRE โดยไม่ควรเป็นป้ายกำกับ ตัวเลือกนี้ควรปรากฏก่อนคำสั่ง Bazel ใดๆ เช่น

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

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

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

--host_jvm_args=string

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

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

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

การดำเนินการนี้ไม่ส่งผลต่อ JVM ใดๆ ที่ใช้โดยกระบวนการย่อยของ Bazel เช่น แอปพลิเคชัน การทดสอบ เครื่องมือ และอื่นๆ หากต้องการส่งตัวเลือก JVM ไปยังโปรแกรม Java ที่ดำเนินการได้ ไม่ว่าจะเรียกใช้โดย bazel run หรือบนบรรทัดคำสั่ง คุณควรใช้อาร์กิวเมนต์ --jvm_flags ซึ่งโปรแกรม java_binary และ java_test ทั้งหมดรองรับ หรือจะใช้ bazel test --test_arg=--jvm_flags=foo ... สำหรับการทดสอบก็ได้

--host_jvm_debug

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

--autodetect_server_javabase

ตัวเลือกนี้จะทำให้ Bazel ค้นหา JDK ที่ติดตั้งไว้โดยอัตโนมัติเมื่อเริ่มต้นใช้งาน และกลับไปใช้ JRE ที่ติดตั้งไว้หาก JRE ที่ฝังไว้ไม่พร้อมใช้งาน คุณสามารถใช้ --explicit_server_javabase เพื่อเลือก JRE ที่ชัดเจน ซึ่งใช้ Bazel ด้วย

--batch

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

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

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

--max_idle_secs=n

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

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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