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

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 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 สำหรับแพ็กเกจที่ระบุ

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

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

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

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

  1. หากอักขระตัวแรกคือ / เส้นทางจะเป็นสัมบูรณ์
  2. หากเส้นทางขึ้นต้นด้วย %workspace% ระบบจะใช้เส้นทางแบบสัมพัทธ์ ไปยังไดเรกทอรี Bazel ที่ล้อมรอบอยู่ที่ใกล้ที่สุด เช่น หากไดเรกทอรีที่ใช้งานอยู่ มีค่าเป็น /home/bob/clients/bob_client/bazel/foo ค่า สตริง %workspace% ในเส้นทางแพ็กเกจถูกขยาย ไปยัง /home/bob/clients/bob_client/bazel
  3. ส่วนข้อมูลอื่นๆ จะเกี่ยวข้องกับไดเรกทอรีที่ใช้งานอยู่ ซึ่งโดยปกติแล้วจะไม่ใช่ สิ่งที่คุณตั้งใจจะทำ และอาจทำงานโดยไม่คาดคิดหากคุณใช้ Bazel จากไดเรกทอรีด้านล่างพื้นที่ทำงาน bazel ตัวอย่างเช่น หากคุณใช้องค์ประกอบเส้นทางแพ็กเกจ . จากนั้นเพิ่ม cd ลงในไดเรกทอรี แพ็กเกจ /home/bob/clients/bob_client/bazel/foo จะได้รับการแก้ไขจาก ไดเรกทอรี /home/bob/clients/bob_client/bazel/foo

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

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

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

--copt=cc-option

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

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

  % 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 และจะเป็น โปรดทราบว่าการตั้งค่า Flag --strip ของ Bazel จะลบล้าง --linkopt=-Wl,--strip-all ดังนั้นคุณควรตั้งค่าอย่างใดอย่างหนึ่งเท่านั้น

หากคุณกำลังสร้างไบนารีเดียว และต้องการให้ตัดสัญลักษณ์ทั้งหมดออก คุณสามารถ ส่ง --stripopt=--strip-all และสร้าง เป้าหมายเวอร์ชัน //foo:bar.stripped ตามที่อธิบายไว้ในส่วนเกี่ยวกับ --stripopt จะมีการใช้การดำเนินการตัดโฆษณาหลังจากไบนารีสุดท้ายเป็น ลิงก์อยู่ แทนที่จะรวมการตัดการทำงานของลิงก์ทั้งหมดของบิลด์ออก

--stripopt=strip-option

นี่เป็นตัวเลือกเพิ่มเติมสำหรับส่งผ่านไปยังคำสั่ง strip เมื่อสร้าง ไบนารี *.stripped ค่าเริ่มต้น มีค่า -S -p ตัวเลือกนี้ใช้ได้หลายครั้ง

--fdo_instrument=profile-output-dir

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

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

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

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

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

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

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

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

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

ระบุการแจ้งว่าไม่เหมาะสม --action_env นี้ได้หลายครั้ง หากมีการกำหนดค่าให้กับ ในแฟล็ก --action_env หลายรายการ การมอบหมายล่าสุดจะชนะ

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

การตั้งค่าสถานะนี้ใช้ได้เฉพาะเมื่อใช้ร่วมกับ แฟล็ก --experimental_action_listener

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

แพลตฟอร์มที่จะสร้าง deps ทรานซิชันของ กฎ android_binary ข้อ (โดยเฉพาะสำหรับทรัพยากร Dependency แบบเนทีฟ เช่น C++) สำหรับ ตัวอย่างเช่น หาก cc_library ปรากฏในแท็ก deps ของการสัญจรของ กฎ android_binary ข้อที่สร้างขึ้นนี้สร้างขึ้น 1 ครั้งสำหรับแต่ละแพลตฟอร์มที่ระบุด้วย --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++ รวมถึงคำนำหน้าที่ขึ้นอยู่กับแพลตฟอร์มด้วย

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

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

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

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

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

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

--dynamic_mode=mode

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

โหมด:

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--android_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

ตัวเลือกนี้จะระบุว่าควรใช้กลยุทธ์ใดเพื่อเรียกใช้คำสั่งที่มีคำอธิบาย ตรงกับ 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' รัน "คอมไพล์ //foo/bar/baz" ด้วยกลยุทธ์ local และกลับไปที่ sandboxed หากไม่สำเร็จ

--genrule_strategy=strategy

นี่คือเนื้อหาแบบสั้นที่เลิกใช้งานแล้วสำหรับ --strategy=Genrule=strategy

--jobs=n (- จ)

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

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

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

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

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

หากระบุ Bazel จะสร้างเฉพาะสิ่งที่จำเป็นต่อการเรียกใช้ *_test เท่านั้น และ test_suite กฎที่ไม่ได้กรองเนื่องจาก ขนาด [size] หมดเวลา แท็กหรือ ภาษา หากระบุไว้ 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

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

--save_temps

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

ขณะนี้แฟล็ก --save_temps ใช้ได้กับกฎ cc_* เท่านั้น

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

และ

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

--test_filter=filter-expression

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

การตีความ filter-expression โดยเฉพาะตาม เฟรมเวิร์กการทดสอบที่รับผิดชอบในการทำการทดสอบ อาจเป็นโลก สตริงย่อย หรือ regexp --test_filter ช่วยอำนวยความสะดวก การส่งผ่านอาร์กิวเมนต์ตัวกรอง --test_arg ที่แตกต่างกัน แต่เฟรมเวิร์กบางรายการอาจไม่รองรับ

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

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

--explain=logfile

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

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

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

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

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

--verbose_failures

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

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

สถานะพื้นที่ทำงาน

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

--workspace_status_command=program

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

ค่าของแฟล็กต้องเป็นเส้นทางไปยังโปรแกรมเนทีฟ ใน Linux/macOS ไฟล์นี้อาจเป็นไฟล์สั่งการได้ ใน Windows ไฟล์นี้ต้องเป็นไบนารีดั้งเดิม ซึ่งมักจะเป็น ".exe", ".bat" หรือ ".cmd"

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

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: เวลาของบิลด์เป็นวินาทีนับตั้งแต่ Unix Epoch (ค่า จาก System.currentTimeMillis() หารด้วย 1,000)
    • FORMATTED_DATE: เวลาของบิลด์ที่จัดรูปแบบเป็น yyyy MMM d HH mm ss EEE(เช่น 2023 201 44 29 มิ.ย. 2023 ใน 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 จะไม่ประทับตราไบนารีที่สร้างขึ้นสำหรับการกำหนดค่าผู้บริหาร โดยไม่คำนึงถึงตัวเลือกนี้หรือแอตทริบิวต์ stamp สำหรับกฎที่ตั้งค่าไว้ stamp = 0 (ค่าเริ่มต้นสำหรับกฎ *_test) การประทับตราจะถูกปิดใช้โดยไม่คำนึงถึง --[no]stamp การระบุ --stamp จะไม่บังคับให้สร้างเป้าหมายใหม่หาก ไม่ได้เปลี่ยนแปลงการขึ้นต่อกัน

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

แฟล็กชั่วคราวสำหรับการทดสอบการเปลี่ยนแปลงระดับการเข้าถึงเริ่มต้นของ 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 บิต" เทียบกับ "32bit" ตัวเลือกนี้ แยกความแตกต่างของลิงก์สัญลักษณ์ bazel-bin (ฯลฯ)

กำลังทดสอบ

หากต้องการสร้างและทำการทดสอบด้วย Bazel ให้พิมพ์ bazel test ตามด้วย ชื่อของเป้าหมายทดสอบ

โดยค่าเริ่มต้น คำสั่งนี้จะดำเนินการสร้างและทดสอบพร้อมกัน การสร้างเป้าหมายที่ระบุทั้งหมด (รวมทั้งเป้าหมายอื่นๆ ที่ไม่ใช่การทดสอบ) เป้าหมายที่ระบุในบรรทัดคำสั่ง) และการทดสอบ *_test และ test_suite เป้าหมายทันที ข้อกำหนดเบื้องต้นนั้นขึ้นมา ซึ่งหมายความว่า การดำเนินการทดสอบนั้น แทรกสลับกับสิ่งปลูกสร้าง การทำเช่นนี้มักจะส่งผล ที่เพิ่มขึ้น

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

--cache_test_results=(yes|no|auto) (-t)

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

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

หาก "ไม่" การทดสอบทั้งหมดจะดำเนินการอย่างไม่มีเงื่อนไข

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

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

--check_tests_up_to_date

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

ตัวเลือกนี้ยังกล่าวเป็นนัย พฤติกรรม [--check_up_to_date](#check-up-to-date) รายการ

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

--test_verbose_timeout_warnings

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

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

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

สถานะของเป้าหมายที่การเรียกใช้ล้มเหลวขึ้นอยู่กับค่าของพารามิเตอร์ แฟล็ก --runs_per_test_detects_flakes รายการ:

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

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

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

--test_arg=arg

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

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

กำลังทำความสะอาดเอาต์พุตของบิลด์

คำสั่ง clean

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

ตัวเลือก --[no]implicit_deps ซึ่งเปิดใช้อยู่โดยค่าเริ่มต้นทำให้เกิดสาเหตุ การขึ้นต่อกันโดยนัยที่จะรวมอยู่ในกราฟทรัพยากร Dependency ที่การค้นหาทำงาน CANNOT TRANSLATE การขึ้นต่อกันโดยปริยายคือทรัพยากรที่ไม่ได้ระบุไว้อย่างชัดแจ้งในไฟล์ 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 นี้ หรือ "เวอร์ชันที่กำลังพัฒนา" หากนี่ไม่ใช่การเผยแพร่ 2.
  • workspace เส้นทางสัมบูรณ์ไปยังพื้นที่ทำงานฐาน ไดเรกทอรี

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

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

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

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

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

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

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

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

mobile-install

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

โปรดดูข้อมูลเพิ่มเติมที่การติดตั้ง Bazel สำหรับอุปกรณ์เคลื่อนที่

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

--incremental

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

หากคุณใช้อุปกรณ์ที่มี Marshmallow ขึ้นไป โปรดพิจารณา แฟล็ก --split_apks

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

canonicalize-flags

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

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

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

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

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

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

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

--output_base=dir

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

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

เช่น

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

ในคำสั่งนี้ คำสั่ง Bazel สองคำสั่งจะทำงานพร้อมกัน (เนื่องจาก โอเปอเรเตอร์ Shell &amp;) แต่ละรายการใช้ Bazel ที่ต่างกัน อินสแตนซ์ของเซิร์ฟเวอร์ (เนื่องจากฐานเอาต์พุตต่างกัน) ในทางกลับกัน หากใช้ฐานเอาต์พุตเริ่มต้นในทั้ง 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 (บางครั้งเรียกว่า "ขวามือ" --host_javabase)

--host_jvm_args=string

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

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

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

ตัวเลือกเบ็ดเตล็ด

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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