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

รายงานปัญหา ดูแหล่งที่มา Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

ตัวเลือก

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

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

ตำแหน่งแพ็กเกจ

--package_path

คำเตือน: เราเลิกใช้งานตัวเลือก --package_path แล้ว Bazel ต้องการให้แพ็กเกจ ในที่เก็บหลักอยู่ใต้รูทของพื้นที่ทำงาน

ตัวเลือกนี้จะระบุชุดไดเรกทอรีที่ค้นหาเพื่อ หาไฟล์ 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% ในเส้นทางแพ็กเกจจะขยายเป็น /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 MODULE.bazel
  % bazel build --package_path /some/other/path //foo

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

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

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

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

--fdo_optimize=profile-zip

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

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

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

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

--java_language_version=version

ตัวเลือกนี้ระบุเวอร์ชันของแหล่งที่มาของ Java เช่น

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

คอมไพล์และอนุญาตเฉพาะโครงสร้างที่เข้ากันได้กับข้อกำหนด Java 8 เท่านั้น ค่าเริ่มต้นคือ 11 --> ค่าที่เป็นไปได้คือ 8, 9, 10, 11, 17 และ 21 และอาจขยายได้โดย การลงทะเบียน Toolchain Java ที่กำหนดเองโดยใช้ default_java_toolchain

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

ตัวเลือกนี้ช่วยให้ส่งอาร์กิวเมนต์ของตัวเลือกไปยัง javac ได้ โดยใช้ได้ กับอาร์กิวเมนต์ขนาดใหญ่ 1 รายการ หรือหลายครั้งกับอาร์กิวเมนต์แต่ละรายการ เช่น

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

จะสร้าง java_binary ใหม่ด้วยข้อมูลการแก้ไขข้อบกพร่องเริ่มต้นของ javac (แทนที่จะเป็นค่าเริ่มต้นของ Bazel)

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

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

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

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

--compilation_mode option (มักย่อเป็น -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 นี้ได้หลายครั้ง หากมีการกําหนดค่าให้กับตัวแปรเดียวกันใน--action_env Flag หลายรายการ การกําหนดค่าล่าสุดจะชนะ

--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 หนึ่งครั้งสำหรับแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms สำหรับกฎ android_binary และรวมไว้ในเอาต์พุตสุดท้าย

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

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

โหมด:

  • 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

หากตั้งค่าสถานะนี้ ระบบจะไม่สนใจ-static options ใน 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

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

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

--java_toolchain=label

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อความเข้ากันได้แบบย้อนหลังเท่านั้น

--host_java_toolchain=label

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อความเข้ากันได้แบบย้อนหลังเท่านั้น

--javabase=(label)

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อความเข้ากันได้แบบย้อนหลังเท่านั้น

--host_javabase=label

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อความเข้ากันได้แบบย้อนหลังเท่านั้น

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

ตัวเลือกนี้จะควบคุมตำแหน่งและวิธีการเรียกใช้คำสั่ง โดยจะลบล้าง --spawn_strategy (และ --genrule_strategy ที่มีคำช่วยจำ Genrule) ตามคำช่วยจำ ดู--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 เรียกใช้ "Compiling //foo/bar/baz" ด้วยกลยุทธ์ sandboxed แต่การย้อนกลับ ลำดับจะเรียกใช้ด้วย local
  • ตัวอย่าง: --strategy_regexp='Compiling.*/bar=local,sandboxed' runs 'Compiling //foo/bar/baz' with the local strategy and falls back to sandboxed if it fails.

--genrule_strategy=strategy

นี่คือรูปแบบย่อที่เลิกใช้งานแล้วของ --strategy=Genrule=strategy

--jobs=n (-j)

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

--progress_report_interval=n

Bazel จะพิมพ์รายงานความคืบหน้าเป็นระยะๆ เกี่ยวกับงานที่ยังไม่เสร็จ (เช่น การทดสอบที่ใช้เวลานาน) ตัวเลือกนี้จะตั้งค่า ความถี่ในการรายงาน โดยจะพิมพ์ความคืบหน้าทุกๆ n วินาที

ค่าเริ่มต้นคือ 0 ซึ่งหมายถึงอัลกอริทึมแบบเพิ่มทีละรายการ โดยระบบจะพิมพ์รายงานแรกหลังจากผ่านไป 10 วินาที จากนั้นจะพิมพ์หลังจากผ่านไป 30 วินาที และหลังจากนั้นจะรายงานความคืบหน้าทุกๆ 1 นาที

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

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

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

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

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

--[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 เช่น โดยการสร้างเป้าหมายเดียว ที่ขึ้นอยู่กับไฟล์ต้นฉบับใหม่เพื่อตรวจหาข้อผิดพลาดโดยเร็วที่สุด ในวงจรการแก้ไข/การสร้าง/การทดสอบ อาร์กิวเมนต์นี้มีผลต่อวิธีตีความอาร์กิวเมนต์ทั้งหมดที่ไม่ได้เป็นแฟล็ก โดยอาร์กิวเมนต์แต่ละรายการต้องเป็นป้ายกำกับเป้าหมายของไฟล์หรือชื่อไฟล์ธรรมดาที่สัมพันธ์กับไดเรกทอรีการทำงานปัจจุบัน และจะมีการสร้างกฎ 1 ข้อที่ขึ้นอยู่กับชื่อไฟล์ต้นฉบับแต่ละชื่อ สำหรับแหล่งข้อมูล C++ และ Java ระบบจะเลือกกฎในพื้นที่ภาษาเดียวกันก่อน สำหรับ กฎหลายข้อที่มีค่ากำหนดเดียวกัน ระบบจะเลือกกฎที่ปรากฏเป็นอันดับแรกใน ไฟล์ BUILD รูปแบบเป้าหมายที่ตั้งชื่ออย่างชัดเจนซึ่งไม่ได้ อ้างอิงไฟล์ต้นฉบับจะทำให้เกิดข้อผิดพลาด

--save_temps

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

ขณะนี้แฟล็ก --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 ด้วย) เฉพาะเป้าหมายการทดสอบที่มีการหมดเวลาที่ระบุ ตัวกรองการหมดเวลาทดสอบ ระบุเป็นรายการค่าการหมดเวลาทดสอบที่อนุญาตซึ่งคั่นด้วยคอมมา (short, moderate, long หรือ eternal) โดยอาจมีเครื่องหมาย "-" นำหน้าเพื่อใช้ระบุ การหมดเวลาทดสอบที่ยกเว้น ดูไวยากรณ์ตัวอย่างได้ที่ --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, สตริงย่อย หรือนิพจน์ทั่วไป --test_filter เป็นวิธีที่สะดวก ในการส่งอาร์กิวเมนต์ตัวกรอง --test_arg ที่แตกต่างกัน แต่เฟรมเวิร์กบางรายการไม่รองรับ

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

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

--explain=logfile

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

--subcommands=pretty_print อาจส่งไปยัง 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"

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

Bazel จะแบ่งคีย์ออกเป็น 2 กลุ่ม ได้แก่ "คงที่" และ "ไม่คงที่" (ชื่อ "คงที่" และ "ไม่คงที่" อาจดูขัดแย้งกันเล็กน้อย ดังนั้นอย่าคิดมากเกี่ยวกับชื่อเหล่านี้)

จากนั้น 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: เวลาของการสร้างเป็นวินาทีนับตั้งแต่ Epoch ของ Unix (ค่าของ System.currentTimeMillis() หารด้วย 1,000)
    • FORMATTED_DATE: เวลาของบิลด์ในรูปแบบ yyyy MMM d HH mm ss EEE(เช่น 2023 Jun 2 01 44 29 Fri) ใน 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 ไม่ได้บังคับให้ต้องสร้างเป้าหมายใหม่หาก การอ้างอิงของเป้าหมายไม่เปลี่ยนแปลง

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

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

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

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

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

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

--platform_suffix=string

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

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

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

  • --package_path
  • --symlink_prefix: หากต้องการจัดการบิลด์สำหรับการกำหนดค่าหลายรายการ คุณอาจต้องแยกความแตกต่างของแต่ละบิลด์ ด้วยตัวระบุที่แตกต่างกัน เช่น "64 บิต" กับ "32 บิต" ตัวเลือกนี้ จะแยกความแตกต่างของ Symlink 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 ด้วย

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

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

ตัวเลือกนี้จะระบุจำนวนครั้งที่ควรดำเนินการทดสอบแต่ละครั้ง ระบบจะถือว่าการดำเนินการทดสอบทั้งหมดเป็นการทดสอบแยกกัน (ฟังก์ชันการทำงานสำรอง จะมีผลกับการทดสอบแต่ละรายการแยกกัน)

สถานะของเป้าหมายที่มีการเรียกใช้ที่ไม่สําเร็จจะขึ้นอยู่กับค่าของแฟล็ก --runs_per_test_detects_flakes

  • หากไม่มีอยู่ การเรียกใช้ที่ไม่สำเร็จจะทำให้การทดสอบทั้งหมดไม่สำเร็จ
  • หากมีอยู่และ 2 การทดสอบจาก Shard เดียวกันแสดงผล 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 จะตรวจหา Shard การทดสอบที่ไม่เสถียรผ่าน --runs_per_test หากการทดสอบอย่างน้อย 1 ครั้งสำหรับ Shard เดียว ไม่สำเร็จ และการทดสอบอย่างน้อย 1 ครั้งสำหรับ Shard เดียวกันสำเร็จ ระบบจะถือว่าเป้าหมาย ไม่เสถียรพร้อมกับตั้งค่าสถานะ หากไม่ได้ระบุไว้ เป้าหมายจะรายงานสถานะ ไม่สำเร็จ

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

โปรดทราบว่าคุณจะส่งอาร์กิวเมนต์ทดสอบโดยตรงเหมือนใน bazel test -- target --logtostderr --v=3 ไม่ได้ ซึ่งต่างจากคำสั่ง bazel run เนื่องจากระบบจะตีความอาร์กิวเมนต์ภายนอกที่ส่งไปยัง bazel test เป็นเป้าหมายการทดสอบเพิ่มเติม กล่าวคือ --logtostderr และ --v=3 จะได้รับการตีความว่าเป็นเป้าหมายการทดสอบ ความคลุมเครือนี้ไม่มีอยู่สำหรับคำสั่ง bazel run ซึ่งยอมรับเป้าหมายเพียงรายการเดียวเท่านั้น

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

--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 ยกเว้น ใช้เพื่อสร้างและเรียกใช้เป้าหมายเดียว นี่คือเซสชันทั่วไป (//java/myapp:myapp ทักทายและพิมพ์อาร์กิวเมนต์ของตัวเอง):

  % bazel run java/myapp:myapp -- --arg1 --arg2
  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
  INFO: Found 1 target...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp/myapp
  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
  INFO: Build completed successfully, 4 total actions
  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

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

เมื่อไบนารีไม่ใช่การทดสอบ ไดเรกทอรีการทำงานปัจจุบันจะเป็น ทรีไฟล์ที่เรียกใช้ของไบนารี

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง: "แสดงตำแหน่งของคำจำกัดความ (ในไฟล์ BUILD) ของ genrule ทั้งหมดที่จำเป็นต่อการสร้างการทดสอบทั้งหมดในทรี 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 รับตัวเลือก 1 รายการคือ --iff_heap_size_greater_than _n_ ซึ่ง ต้องมีอาร์กิวเมนต์จำนวนเต็ม (ในหน่วย MB) หากระบุไว้ การดำเนินการนี้จะทำให้การปิดเครื่อง ขึ้นอยู่กับปริมาณหน่วยความจำที่ใช้ไปแล้ว ซึ่งมีประโยชน์สำหรับสคริปต์ที่เริ่มต้นการสร้างจำนวนมาก เนื่องจากหน่วยความจำรั่วในเซิร์ฟเวอร์ Bazel อาจทำให้เซิร์ฟเวอร์ขัดข้องเป็นครั้งคราว การรีสตาร์ทแบบมีเงื่อนไขจะช่วยป้องกันปัญหานี้ได้

info

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

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

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

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

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

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

  • execution_root: เส้นทางสัมบูรณ์ไปยังไดเรกทอรีรูทการดำเนินการ ภายใต้ output_base ไดเรกทอรีนี้เป็นรูทของไฟล์ทั้งหมด ที่คำสั่งที่ดำเนินการระหว่างการสร้างเข้าถึงได้ และเป็นไดเรกทอรี การทำงานของคำสั่งเหล่านั้น หากไดเรกทอรีพื้นที่ทำงานเขียนได้ ระบบจะวาง ซิมลิงก์ชื่อ bazel-<workspace> ไว้ที่นั่นซึ่งชี้ไปยังไดเรกทอรีนี้

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

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

ไม่ได้รับผลกระทบจากเรื่องนี้

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

--incremental

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

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

--split_apks

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

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

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

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

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

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

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

ระบบจะเช็คอิน java-agent ใน Bazel ที่ third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar ดังนั้น โปรดปรับ $BAZEL สำหรับที่เก็บข้อมูล Bazel ของคุณ

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

ตัวอย่าง

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.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.4.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.4.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 รายการที่มีผลเหมือนกันจะได้รับการแปลงเป็น Canonical ให้เป็นรายการใหม่เดียวกัน

คุณใช้ตัวเลือก --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 Digest) ดังนั้นค่าทั่วไปจึงมีลักษณะดังนี้ /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e

เช่น

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

โหมดกลุ่มจะยังคงรักษาสื่อความหมายของการจัดคิวที่เหมาะสมภายใน output_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

ใช้batchการจัดกำหนดการ CPU สำหรับ 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 หากมีส่วนดังกล่าว ระบุได้หลายครั้งเพื่อเพิ่มแฟล็กจากส่วนการกำหนดค่าหลายส่วน การขยายความสามารถอ้างอิงถึงคำจำกัดความอื่นๆ ได้ (เช่น การขยายความสามารถสามารถเชื่อมโยงกันได้)

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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