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

รายงานปัญหา ดูแหล่งที่มา

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

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

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

--copt=cc-option

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

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

  % 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

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

--tool_java_language_version=version

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

--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 และก่อนตัวเลือกต่อกฎ ข้อกำหนดสุดท้ายของตัวเลือกใดๆ สำหรับ JavaScript จะชนะ ตัวเลือกเริ่มต้นสำหรับ Javac มีดังนี้

  -source 8 -target 8 -encoding UTF-8

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

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

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

--force_ignore_dash_static

หากตั้งค่าแฟล็กนี้ไว้ ระบบจะละเว้นตัวเลือก -static ใน linkopts ของกฎ cc_* การสร้างไฟล์ BUILD เครื่องมือนี้มีไว้เพื่อเป็นวิธีแก้ปัญหา สำหรับบิลด์ที่ปิดช่องโหว่ของ 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 เพื่อคอมไพล์โค้ดในการกำหนดค่าการดำเนินการ เช่น เครื่องมือที่ทำงานระหว่างบิลด์ จุดประสงค์หลักของ Flag นี้คือ เปิดใช้การคอมไพล์ข้ามกัน

--apple_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

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

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

--genrule_strategy=strategy

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

--jobs=n (-j)

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

--progress_report_interval=n

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

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

เมื่อ 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 โดยตรงจากการกำหนดค่าของระบบในเครื่อง

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

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

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

--save_temps

ตัวเลือก --save_temps จะทำให้ระบบบันทึกเอาต์พุตชั่วคราวจากคอมไพเลอร์ ซึ่งรวมถึงไฟล์ .s (โค้ด Assembler), .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 ด้วย) ทดสอบเฉพาะเป้าหมายที่มีระยะหมดเวลาที่กำหนด ตัวกรองการหมดเวลาทดสอบจะระบุเป็นรายการที่คั่นด้วยคอมมาของค่าการหมดเวลาทดสอบที่อนุญาต (สั้น ปานกลาง ยาว หรือตลอดไป) โดยใส่เครื่องหมาย '-' นำหน้าได้ เพื่อแสดงถึงระยะหมดเวลาทดสอบที่ยกเว้น ดู --test_size_filters ตัวอย่างไวยากรณ์

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--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 บิต" ตัวเลือกนี้จะทำให้ลิงก์สัญลักษณ์ของ 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 หรือ LONG เนื่องจากเป็นการทดสอบที่กว้างเกินไป

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

--[no]test_keep_going

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

--flaky_test_attempts=attempts

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

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

--runs_per_test=[regex@]number

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

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

  • หากไม่มี การเรียกใช้ที่ล้มเหลวจะทำให้การทดสอบทั้งหมดล้มเหลว
  • หากมีและการเรียกใช้ 2 ครั้งจาก PASS และ FAIL แสดงผลชาร์ดเดียวกัน การทดสอบจะได้รับสถานะไม่สม่ำเสมอ (ยกเว้นว่าการเรียกใช้ที่ล้มเหลวอื่นๆ จะทำให้เกิดข้อผิดพลาด)

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

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

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

--test_output=output_style

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

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

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

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

--run_under=command-prefix

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

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

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

  • PATH ที่ใช้ในการทำการทดสอบอาจแตกต่างจาก PATH ในสภาพแวดล้อมของคุณ ดังนั้น คุณจึงอาจต้องใช้เส้นทางสัมบูรณ์สำหรับคำสั่ง --run_under (คำแรกใน command-prefix)
  • stdin ไม่ได้เชื่อมต่อ จึงใช้ --run_under สำหรับคำสั่งแบบอินเทอร์แอกทีฟไม่ได้

ตัวอย่าง

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

การเลือกการทดสอบ

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

ตัวเลือกอื่นๆ สําหรับ bazel test

ไวยากรณ์และตัวเลือกที่เหลือมีลักษณะเหมือน bazel build ทุกประการ

การเรียกใช้ไฟล์ปฏิบัติการ

คำสั่ง bazel run คล้ายกับ bazel build แต่ต่างกันตรงที่ใช้เพื่อสร้างและเรียกใช้เป้าหมายเดียว เซสชันทั่วไปมีดังนี้

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

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

การล้างเอาต์พุตของบิลด์

คำสั่ง clean

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

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

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

  % bazel clean --expunge

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

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

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

การค้นหากราฟการอ้างอิง

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

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

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

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

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

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

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

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

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

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

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

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

โปรดดูรายละเอียดเพิ่มเติมในการค้นหากราฟการดำเนินการ

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

help

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

--[no]long (-l)

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

shutdown

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

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

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

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

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

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

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

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

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

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

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

mobile-install

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

ดูข้อมูลเพิ่มเติมที่การติดตั้งบนอุปกรณ์เคลื่อนที่ในเบเซล

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

--incremental

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

หากคุณใช้อุปกรณ์ที่มี Marshmallow ขึ้นไป ให้ลองใช้ธง --split_apks

--split_apks

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

ระบุเครื่องเสมือน Java ที่ตัวบาเซลเองทำงานอยู่ ค่านี้ต้องเป็นเส้นทางไปยังไดเรกทอรีที่มี 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 --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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

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

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