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

รายงานปัญหาopen_in_new ดูแหล่งที่มาopen_in_new รุ่น 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 ตัวอย่างเช่น หากคุณใช้องค์ประกอบ package-path . แล้ว cd ไปยังไดเรกทอรี /home/bob/clients/bob_client/bazel/foo ระบบจะแก้ไขแพ็กเกจจากไดเรกทอรี /home/bob/clients/bob_client/bazel/foo

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

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

ตัวอย่าง: การสร้างจากไคลเอ็นต์ว่าง

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

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

การตรวจสอบข้อผิดพลาด

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

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

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

ตัวเลือกนี้ใช้อาร์กิวเมนต์ซึ่งจะส่งไปยังคอมไพเลอร์เมื่อคอมไพล์ไฟล์ต้นฉบับ C

ข้อกำหนดนี้คล้ายกับ --copt แต่มีผลกับการคอมไพล์ C เท่านั้น ไม่เกี่ยวข้องกับการคอมไพล์หรือการลิงก์ C++ คุณจึงส่งตัวเลือกเฉพาะ C ได้ (เช่น -Wno-pointer-sign) โดยใช้ --conlyopt

--cxxopt=cc-option

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

คำสั่งนี้คล้ายกับ --copt แต่มีผลกับการคอมไพล์ C++ เท่านั้น จะไม่มีผลกับการคอมไพล์หรือลิงก์ C คุณจึงส่งตัวเลือกเฉพาะ C++ (เช่น -fpermissive หรือ -fno-implicit-templates) ได้โดยใช้ --cxxopt

เช่น

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

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

การดำเนินการนี้คล้ายกับ --copt แต่มีผลเฉพาะกับการลิงก์เท่านั้น จะไม่มีผลกับการคอมไพล์ คุณจึงส่งตัวเลือกคอมไพเลอร์ที่เหมาะสําหรับเวลาลิงก์เท่านั้นได้ (เช่น -lssp หรือ -Wl,--wrap,abort) โดยใช้ --linkopt เช่น

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

กฎการสร้างยังระบุตัวเลือกลิงก์ในแอตทริบิวต์ได้ด้วย การตั้งค่าของตัวเลือกนี้จะมีความสำคัญเหนือกว่าเสมอ ดูcc_library.linkopts เพิ่มเติม

--strip (always|never|sometimes)

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

ตัวเลือกนี้อนุญาตให้ส่งผ่านอาร์กิวเมนต์ตัวเลือกไปยัง Java VM โดยสามารถใช้กับอาร์กิวเมนต์ใหญ่รายการเดียว หรือใช้กับอาร์กิวเมนต์แต่ละรายการหลายครั้งก็ได้ เช่น

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

ระบุการแจ้งว่าไม่เหมาะสม --action_env นี้ได้หลายครั้ง หากมีการกําหนดค่าให้กับตัวแปรเดียวกันใน Flag --action_env หลายรายการ การกำหนดล่าสุดจะมีผล

--experimental_action_listener=label

ตัวเลือก experimental_action_listener จะสั่งให้ Bazel ใช้รายละเอียดจากกฎ action_listener ที่ระบุโดย label เพื่อแทรก extra_actions ลงในกราฟการสร้าง

--[no]experimental_extra_action_top_level_only

หากตั้งค่าตัวเลือกนี้เป็น "จริง" ระบบจะตั้งเวลาการดำเนินการเพิ่มเติมที่ระบุโดยตัวเลือกบรรทัดคำสั่ง --experimental_action_listener ไว้สำหรับเป้าหมายระดับบนสุดเท่านั้น

--experimental_extra_action_filter=regex

ตัวเลือก experimental_extra_action_filter จะสั่งให้ Bazel กรองชุดเป้าหมายเพื่อตั้งเวลาให้ extra_actions

ใช้แฟล็กนี้ได้เมื่อใช้ร่วมกับแฟล็ก --experimental_action_listener เท่านั้น

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

แพลตฟอร์มที่จะสร้าง deps แบบทรานซิทีฟของกฎ android_binary (โดยเฉพาะสําหรับข้อกําหนดของเนทีฟ เช่น C++) ตัวอย่างเช่น หาก cc_library ปรากฏใน deps แบบทรานซิทีฟของกฎ android_binary ระบบจะสร้าง cc_library 1 ครั้งสําหรับแต่ละแพลตฟอร์มที่ระบุด้วย --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 จะใช้ได้เฉพาะเส้นทางการเรียกใช้ ในกรณีนี้ นิพจน์ทั่วไปไม่ควรขึ้นต้นด้วย "//" เนื่องจากไม่ตรงกับเส้นทางการดําเนินการใดๆ ชื่อแพ็กเกจจะใช้ได้ดังนี้ --per_file_copt=base/.*\.pb\.cc@-g0 การดำเนินการนี้จะจับคู่ทุก .pb.cc ไฟล์ภายใต้ไดเรกทอรีที่ชื่อ base

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

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

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

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

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

--dynamic_mode=mode

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

โหมด

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

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

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

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

--force_ignore_dash_static

หากตั้งค่า Flag นี้ ระบบจะไม่สนใจตัวเลือก -static ใน linkopts ของไฟล์ BUILD กฎ cc_* การดำเนินการนี้มีไว้เพื่อแก้ปัญหาชั่วคราวสำหรับบิลด์ C++ ที่เพิ่มความแข็งแกร่งเท่านั้น

--[no]force_pic

หากเปิดใช้ การคอมไพล์ C++ ทั้งหมดจะสร้างโค้ดที่ไม่ขึ้นกับตำแหน่ง ("-fPIC") การลิงก์จะเลือกไลบรารีที่สร้างไว้ล่วงหน้าแบบ PIC มากกว่าไลบรารีที่ไม่ใช่ PIC และการลิงก์จะสร้างไฟล์ปฏิบัติการที่ไม่ขึ้นกับตำแหน่ง ("-pie") ค่าเริ่มต้นคือปิดใช้

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

เมื่อระบุแล้ว ให้ใช้การใช้งาน malloc ที่ระบุเสมอ โดยลบล้างแอตทริบิวต์ malloc="target" ทั้งหมด รวมถึงในเป้าหมายที่ใช้ค่าเริ่มต้น (โดยไม่ระบุ malloc)

--crosstool_top=label

ตัวเลือกนี้จะระบุตำแหน่งของชุดคอมไพเลอร์ Crosstool ที่จะใช้ในการคอมไพล์ C++ ทั้งหมดระหว่างการสร้าง Bazel จะค้นหาไฟล์ CROSSTOOL ในตำแหน่งนั้นและใช้ไฟล์ดังกล่าวเพื่อกำหนดการตั้งค่าสำหรับ --compiler โดยอัตโนมัติ

--host_crosstool_top=label

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

--apple_crosstool_top=label

เครื่องมือข้ามแพลตฟอร์มที่จะใช้คอมไพล์กฎ C/C++ ในdepsของกฎ objc*, ios* และ apple* แบบทรานซิทีฟ สำหรับเป้าหมายเหล่านั้น แฟล็กนี้จะแทนที่ --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 แทนการระบุ Flag นี้

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--strategy mnemonic=strategy

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

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

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

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

• ตัวอย่างเช่น --strategy_regexp=//foo.*\\.cc,-//foo/bar=local หมายถึงการดําเนินการโดยใช้กลยุทธ์ local หากคําอธิบายตรงกับ //foo.*.cc แต่ไม่ใช่ //foo/bar
• ตัวอย่างเช่น --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed จะเรียกใช้ "การคอมไพล์ //foo/bar/baz" ด้วยกลยุทธ์ sandboxed แต่การกลับลำดับจะเรียกใช้ด้วย local
• ตัวอย่างเช่น --strategy_regexp='Compiling.*/bar=local,sandboxed' จะเรียกใช้ '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 อาจมีประโยชน์ในการตรวจสอบว่าเป้าหมายทั้งหมดคอมไพล์เป้าหมายหรือไม่เกิดโอเวอร์เฮดสำหรับการสร้างแผนผังการเรียกใช้ไฟล์

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

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

การเลือกเอาต์พุต

ตัวเลือกเหล่านี้จะเป็นตัวกำหนดสิ่งที่จะสร้างหรือทดสอบ

--[no]build

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

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

--[no]build_tests_only

หากระบุไว้ Bazel จะสร้างเฉพาะสิ่งที่จําเป็นต่อการใช้งานกฎ *_test และ test_suite ที่ไม่ได้กรองเนื่องจากขนาด การหมดเวลา แท็ก หรือภาษา หากระบุ Bazel จะละเว้นเป้าหมายอื่นๆ ที่ระบุไว้ในบรรทัดคำสั่ง โดยค่าเริ่มต้น ตัวเลือกนี้จะปิดอยู่และ Bazel จะสร้างทุกอย่างที่ขอ รวมถึงกฎ *_test และ test_suite ที่กรองออกจากการทดสอบ วิธีนี้มีประโยชน์เนื่องจากการเรียกใช้ bazel test --build_tests_only foo/... อาจตรวจไม่พบการหยุดทำงานของบิลด์ทั้งหมดในแผนผัง foo

--[no]check_up_to_date

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

ดู --check_tests_up_to_date เพิ่มเติม

--[no]compile_one_dependency

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

หากตั้งค่าตัวเลือกนี้เป็น "auto" (ค่าเริ่มต้น) ไว้ Bazel จะเรียกใช้การทดสอบอีกครั้งก็ต่อเมื่อเป็นไปตามเงื่อนไขต่อไปนี้เท่านั้น

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

หากเป็น "ไม่" ระบบจะเรียกใช้การทดสอบทั้งหมดโดยไม่มีเงื่อนไข

หาก "ใช่" ลักษณะการแคชจะเหมือนกับ "อัตโนมัติ" เว้นแต่ว่าระบบอาจแคชการทดสอบที่ไม่สำเร็จและการเรียกใช้การทดสอบด้วย --runs_per_test

ผู้ใช้ที่เปิดใช้ตัวเลือกนี้โดยค่าเริ่มต้นในไฟล์ .bazelrc อาจเห็นอักษรย่อ -t (เปิด) หรือ -t- (ปิด) เพื่อความสะดวกในการลบล้างค่าเริ่มต้นในการเรียกใช้แต่ละครั้ง

--check_tests_up_to_date

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

ตัวเลือกนี้ยังใช้กับ[--check_up_to_date](#check-up-to-date)พฤติกรรมด้วย

ตัวเลือกนี้อาจเป็นประโยชน์สำหรับการตรวจสอบก่อนส่ง

--test_verbose_timeout_warnings

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

ตัวอย่างเช่น การทดสอบที่ปกติจะใช้เวลา 1-2 นาทีไม่ควรมีระยะหมดเวลาเป็น ETERNAL หรือ LONG เนื่องจากค่าเหล่านี้มีระยะเวลานานเกินไป

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

--[no]test_keep_going

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

หากระบุตัวเลขเพียงตัวเดียว การทดสอบทั้งหมดจะทํางานตามจํานวนนั้น หรือจะระบุนิพจน์ทั่วไปโดยใช้ไวยากรณ์ ดังนี้ regex@number ซึ่งจะจำกัดผลของ --runs_per_test ไว้สำหรับเป้าหมายที่ตรงกับนิพจน์ทั่วไป (--runs_per_test=^//pizza:.*@4 ทำการทดสอบทั้งหมดไม่เกิน //pizza/ 4 ครั้ง) ระบุ --runs_per_test รูปแบบนี้ได้มากกว่า 1 ครั้ง

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

ระบุวิธีแสดงสรุปผลการทดสอบ

• short จะพิมพ์ผลลัพธ์ของการทดสอบแต่ละรายการพร้อมกับชื่อไฟล์ที่มีเอาต์พุตการทดสอบหากการทดสอบไม่สำเร็จ นี่คือค่าเริ่มต้น
• terse เหมือนกับ short แต่สั้นกว่า: พิมพ์เฉพาะข้อมูลเกี่ยวกับการทดสอบที่ไม่ผ่าน
• detailed จะพิมพ์แต่ละเฟรมทดสอบที่ดำเนินการไม่สำเร็จ ไม่ใช่แค่การทดสอบแต่ละรายการ และละเว้นชื่อไฟล์เอาต์พุตทดสอบ
• none ไม่พิมพ์ข้อมูลสรุปการทดสอบ

--test_output=output_style

ระบุวิธีแสดงผลลัพธ์การทดสอบ

• summary แสดงสรุปว่าแต่ละการทดสอบผ่านหรือไม่ และยังแสดงชื่อไฟล์บันทึกเอาต์พุตสําหรับการทดสอบที่ไม่สําเร็จด้วย ระบบจะพิมพ์สรุปเมื่อบิลด์เสร็จสิ้น (ระหว่างการบิลด์ คุณจะเห็นเฉพาะข้อความความคืบหน้าง่ายๆ เมื่อการทดสอบเริ่มขึ้น ผ่าน หรือไม่ผ่าน) นี่คือลักษณะการทำงานเริ่มต้น
• errors จะส่งเอาต์พุต stdout/stderr ที่รวมกันจากการทดสอบที่ไม่สําเร็จไปยัง stdout เท่านั้นทันทีที่การทดสอบเสร็จสมบูรณ์ เพื่อให้มั่นใจว่าเอาต์พุตการทดสอบจากการทดสอบพร้อมกันจะไม่ซ้อนทับกัน พิมพ์ข้อมูลสรุปที่บิลด์ตามเอาต์พุตข้อมูลสรุปด้านบน
• all คล้ายกับ errors แต่จะแสดงผลลัพธ์ของการทดสอบทั้งหมด รวมถึงการทดสอบที่ผ่าน
• streamed สตรีมเอาต์พุต stdout/stderr จากการทดสอบแต่ละรายการแบบเรียลไทม์

--java_debug

ตัวเลือกนี้จะทำให้เครื่องเสมือน Java ของการทดสอบ Java รอการเชื่อมต่อจากโปรแกรมแก้ไขข้อบกพร่องที่เป็นไปตามข้อกำหนด JDWP ก่อนเริ่มการทดสอบ ตัวเลือกนี้จะนัยถึง --test_output=streamed

--[no]verbose_test_summary

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

--test_tmpdir=path

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

--test_timeout=seconds หรือ --test_timeout=seconds,seconds,seconds,seconds

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

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

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

--test_arg=arg

ส่งตัวเลือก/ธง/อาร์กิวเมนต์บรรทัดคำสั่งไปยังกระบวนการทดสอบแต่ละรายการ คุณใช้ตัวเลือกนี้ได้หลายครั้งเพื่อส่งอาร์กิวเมนต์หลายรายการ เช่น --test_arg=--logtostderr --test_arg=--v=3

--test_env=variable=_value_ หรือ --test_env=variable

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

• changelist: รายการเปลี่ยนแปลงที่มีการเผยแพร่ Bazel เวอร์ชันนี้
• label: ป้ายกำกับรุ่นสำหรับอินสแตนซ์ Bazel นี้ หรือ "เวอร์ชันสำหรับนักพัฒนาซอฟต์แวร์" หากไม่ใช่ไบนารีที่เผยแพร่ มีประโยชน์มากเมื่อรายงานข้อบกพร่อง

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

mobile-install

คำสั่ง mobile-install จะติดตั้งแอปลงในอุปกรณ์เคลื่อนที่ ปัจจุบันรองรับเฉพาะอุปกรณ์ Android ที่ใช้ ART เท่านั้น

ดูข้อมูลเพิ่มเติมได้ที่ bazel mobile-install

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

canonicalize-flags

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

ใช้ตัวเลือก --for_command เพื่อเลือกระหว่างคำสั่งต่างๆ ได้ ปัจจุบันรองรับเฉพาะ build และ test ข้อผิดพลาดที่คำสั่งที่ระบุไม่รองรับจะทำให้ระบบแสดงข้อผิดพลาด

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

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

ตัวเลือกเริ่มต้น

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

ตัวเลือกทั้งหมดที่อธิบายในส่วนนี้ต้องระบุโดยใช้รูปแบบ --key=value หรือ --key value นอกจากนี้ ตัวเลือกเหล่านี้ต้องปรากฏก่อนชื่อของคำสั่ง Bazel ด้วย ใช้ startup --key=value เพื่อแสดงรายการเหล่านี้ในไฟล์ .bazelrc

--output_base=dir

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

โดยค่าเริ่มต้น ฐานเอาต์พุตจะมาจากชื่อเข้าสู่ระบบของผู้ใช้ และชื่อไดเรกทอรีของเวิร์กスペース (ที่จริงคือข้อมูลสรุป MD5) ดังนั้นค่าทั่วไปจึงมีลักษณะดังนี้ /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e

เช่น

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

ตั้งค่าระดับ 0-7 สําหรับการจัดตารางเวลา IO ตามความพยายามที่ดีที่สุด 0 คือลำดับความสำคัญสูงสุด ส่วน 7 คือลำดับความสำคัญต่ำสุด ตัวจัดตารางเวลาแบบคาดการณ์จะดำเนินการตามลำดับความสำคัญสูงสุด 4 เท่านั้น ระบบจะไม่สนใจค่าเชิงลบ

--batch_cpu_scheduling

ใช้การจัดสรร CPU batch สำหรับ Bazel นโยบายนี้มีประโยชน์สำหรับปริมาณงานที่เป็นแบบไม่โต้ตอบ แต่ไม่ต้องการเปลี่ยนค่า Nice ดู "man 2 sched_setscheduler" นโยบายนี้อาจให้การโต้ตอบของระบบที่ดียิ่งขึ้น ซึ่งลดอัตราการส่งข้อมูลของ Bazel

ตัวเลือกอื่นๆ

--[no]announce_rc

ควบคุมว่า Bazel จะประกาศตัวเลือกคำสั่งที่อ่านจากไฟล์ bazelrc เมื่อเริ่มต้นหรือไม่ (ตัวเลือกการเริ่มต้นจะประกาศโดยไม่มีเงื่อนไข)

--color (yes|no|auto)

ตัวเลือกนี้จะกำหนดว่า Bazel จะใช้สีเพื่อไฮไลต์ผลลัพธ์บนหน้าจอไหม

หากตั้งค่าตัวเลือกนี้เป็น yes ระบบจะเปิดใช้เอาต์พุตสี หากตั้งค่าตัวเลือกนี้เป็น auto นั้น Bazel จะใช้เอาต์พุตสีก็ต่อเมื่อมีการส่งเอาต์พุตไปยังเทอร์มินัลและมีการกําหนดตัวแปรสภาพแวดล้อม TERM เป็นค่าอื่นที่ไม่ใช่ dumb, emacs หรือ xterm-mono หากตั้งค่าตัวเลือกนี้เป็น no ระบบจะปิดใช้เอาต์พุตสี ไม่ว่าเอาต์พุตจะไปยังเทอร์มินัลหรือไม่ และไม่ว่าการตั้งค่าตัวแปรสภาพแวดล้อม TERM จะเป็นอย่างไรก็ตาม

--config=name

เลือกส่วนการกำหนดค่าเพิ่มเติมจากไฟล์ rc สำหรับ command ปัจจุบัน ระบบจะดึงตัวเลือกจาก command:name ด้วย หากมีส่วนดังกล่าว ระบุได้หลายครั้งเพื่อเพิ่ม Flag จากส่วนการกําหนดค่าหลายส่วน ส่วนขยายอาจหมายถึงคำจำกัดความอื่นๆ (เช่น การขยายสายได้)

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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