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

รายงานปัญหาopen_in_new ดูซอร์สโค้ดopen_in_new รุ่น Nightly · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

ตัวเลือก

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

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

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

--package_path

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

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

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

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

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

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

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

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

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

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

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

--deleted_packages

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

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

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

--[no]check_visibility

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

--output_filter=regex

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

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

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

ธงเครื่องมือ

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

--copt=cc-option

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

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

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

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

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

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

เช่น

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

--linkopt=linker-option

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

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

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

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

--strip (always|never|sometimes)

ตัวเลือกนี้กำหนดว่า Bazel จะนำข้อมูลการแก้ไขข้อบกพร่องออกจาก ไบนารีและไลบรารีที่แชร์ทั้งหมด โดยการเรียกใช้ Linker ด้วยตัวเลือก -Wl,--strip-debug --strip=always หมายถึงตัดข้อมูลการแก้ไขข้อบกพร่องออกเสมอ --strip=never หมายความว่าไม่ตัดข้อมูลการแก้ไขข้อบกพร่องออก ค่าเริ่มต้น --strip=sometimes หมายถึงตัดหาก --compilation_mode มีค่าเป็น fastbuild

  % bazel build --strip=always //foo:bar

จะคอมไพล์เป้าหมายขณะลบข้อมูลการแก้ไขข้อบกพร่องออกจากไบนารีที่สร้างขึ้นทั้งหมด

ตัวเลือก --strip ของ Bazel สอดคล้องกับตัวเลือก --strip-debug ของ ld ตรงที่จะกรองเฉพาะข้อมูลการแก้ไขข้อบกพร่องออก หากต้องการนำสัญลักษณ์ทั้งหมดออกไม่ว่าด้วยเหตุผลใดก็ตาม ไม่ใช่แค่สัญลักษณ์แก้ไขข้อบกพร่อง คุณต้องใช้ตัวเลือก --strip-all ของ ld ซึ่งทำได้โดยการส่ง --linkopt=-Wl,--strip-all ไปยัง Bazel นอกจากนี้ โปรดทราบว่าการตั้งค่า 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 แต่ละไฟล์

เมื่อสร้างต้นไม้ข้อมูลโปรไฟล์แล้ว คุณควรใส่ต้นไม้โปรไฟล์ลงในไฟล์ ZIP แล้วส่งไปยังตัวเลือก --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 โดยใช้ JDK ดังกล่าว

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

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

  -source 8 -target 8 -encoding UTF-8

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

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

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

โดยค่าเริ่มต้น extra_actions ทั้งหมดในการปิดทางอ้อมของ กำหนดเวลาในการสร้างเป้าหมายที่ขอแล้ว --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 ในกฎบิลด์

โหมด:

• 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 ระบบจะปิดใช้ Fission ในทุกที่ ค่าเริ่มต้นคือ no

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

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

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อใช้งานกับเวอร์ชันเก่าเท่านั้น

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

ไม่มีการดำเนินการใดๆ เก็บไว้เพื่อใช้งานกับเวอร์ชันเก่าเท่านั้น

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

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

--[no]build_runfile_links

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

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

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

--save_temps

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

ปัจจุบัน Flag --save_temps ใช้ได้กับกฎ cc_* เท่านั้น

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

และ

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

โปรดดู --verbose_failures ด้านล่าง

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

--verbose_failures

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

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

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

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

--workspace_status_command=program

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

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

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

Bazel แบ่งคีย์ออกเป็น 2 ที่เก็บข้อมูล ได้แก่ "เสถียร" และ "ผันผวน" (ชื่อ "เสถียร" และ "ผันผวน" ฟังดูขัดแย้งกับความรู้สึกทั่วไป แต่ไม่ต้องคิดมาก)

จากนั้น Bazel เขียนคู่คีย์-ค่าลงในไฟล์ 2 ไฟล์ดังนี้

• bazel-out/stable-status.txt มีคีย์และค่าทั้งหมดที่ชื่อคีย์ขึ้นต้นด้วย STABLE_
• bazel-out/volatile-status.txt มีคีย์และค่าที่เหลือ

สัญญาคือ

• "เสถียร" คีย์ ควรเปลี่ยนน้อยมาก หากเป็นไปได้ หากเนื้อหาของ bazel-out/stable-status.txt เปลี่ยนแปลง Bazel จะลบล้างการดำเนินการที่ขึ้นอยู่กับเนื้อหาดังกล่าว กล่าวคือ หากค่าของคีย์ที่เสถียรมีการเปลี่ยนแปลง Bazel จะเรียกใช้การดำเนินการที่มีการประทับอีกครั้ง ดังนั้น สถานะที่เสถียรจึงไม่ควรประกอบด้วยสิ่งต่างๆ เช่น การประทับเวลา เนื่องจากจะเกิดการเปลี่ยนแปลงทั้งหมด และทำให้ Bazel แสดงการทำงานที่ประทับตราอีกครั้งในแต่ละงานสร้าง

  Bazel จะส่งออกคีย์แบบคงที่ต่อไปนี้เสมอ

  • BUILD_EMBED_LABEL: ค่าของ --embed_label
  • BUILD_HOST: ชื่อเครื่องโฮสต์ที่ Bazel ทำงานอยู่
  • BUILD_USER: ชื่อผู้ใช้ที่ Bazel ทำงานอยู่

• ค่าของคีย์ "ผันผวน" อาจเปลี่ยนแปลงบ่อยครั้ง Bazel คาดหวังว่าค่าเหล่านี้จะเปลี่ยนแปลงอยู่เสมอ เช่นเดียวกับการประทับเวลา และอัปเดตไฟล์ bazel-out/volatile-status.txt ตามความเหมาะสม เพื่อหลีกเลี่ยง แต่การดำเนินการที่ประทับตราอีกครั้ง Bazel ทำทีว่าไฟล์ไม่เปลี่ยนแปลงเลย การเปลี่ยนแปลง กล่าวคือ หากไฟล์สถานะที่มีความผันผวนเป็นไฟล์เดียวที่มีเนื้อหา Bazel จะไม่ทำให้การทำงานที่อ้างอิงอยู่นั้นถูกยกเลิก หากอินพุตอื่นๆ ของการดำเนินการมีการเปลี่ยนแปลง Bazel จะเรียกใช้การดำเนินการนั้นอีกครั้ง และการดำเนินการจะเห็นสถานะที่ไม่แน่นอนที่อัปเดตแล้ว แต่การเปลี่ยนแปลงสถานะที่ไม่แน่นอนเพียงอย่างเดียวจะไม่ทำให้การดำเนินการเป็นโมฆะ

  Bazel จะแสดงผลคีย์ที่มีการเปลี่ยนแปลงได้ต่อไปนี้เสมอ

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

แพลตฟอร์ม

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

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

--platforms=labels

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

--host_platform=label

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

--extra_execution_platforms=labels

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

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

--symlink_prefix=string

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

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

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

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

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

--platform_suffix=string

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

--default_visibility=(private|public)

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

--starlark_cpu_profile=_file_

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

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

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

ถ้าต้องการข้อมูลเดียวกันในมุมมองต่างๆ ลองใช้คำสั่ง pprof svg web และ list

การใช้ Bazel สำหรับรุ่น

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

ตัวเลือกสำคัญ

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

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

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

• --package_path
• --symlink_prefix ในการจัดการบิลด์สำหรับการกำหนดค่าหลายรายการ การแยกความแตกต่างของแต่ละบิลด์จะสะดวกกว่า ที่มีตัวระบุที่แตกต่างกัน เช่น "64 บิต" เทียบกับ "32bit" ตัวเลือกนี้ แยกความแตกต่างของลิงก์สัญลักษณ์ bazel-bin (ฯลฯ)

กำลังทดสอบ

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

ตัวเลือกนี้ยังกล่าวเป็นนัย --check_up_to_date

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

--test_verbose_timeout_warnings

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

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

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

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

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

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

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

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

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

ระบุว่าควรแสดงข้อมูลสรุปผลการทดสอบอย่างไร

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

--test_output=output_style

ระบุว่าควรแสดงเอาต์พุตทดสอบอย่างไร ดังนี้

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

--java_debug

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

--[no]verbose_test_summary

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

--test_tmpdir=path

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

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

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

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

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

--test_arg=arg

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

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

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

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

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

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

ตัวอย่าง

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

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

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

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

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

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

คําสั่ง bazel run คล้ายกับ bazel build ยกเว้นว่าจะใช้สร้างและเรียกใช้เป้าหมายเดียว เซสชันทั่วไปมีดังนี้ (//java/myapp:myapp ทักทายและพิมพ์ args ออกมา)

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

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

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

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

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

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

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

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

ตัวอย่างเช่น "แสดงตำแหน่งของคำจำกัดความ (ในไฟล์ BUILD) ของ genrules ทั้งหมดที่จำเป็นต่อการสร้างการทดสอบทั้งหมดในต้นไม้ 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 นี้ใช้สำหรับผู้ใช้ปัจจุบัน Bazel จะติดตั้งไฟล์ปฏิบัติการที่จําเป็นภายในไว้ด้านล่างไดเรกทอรีนี้

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

ตัวอย่าง: คอมไพเลอร์ C++ สำหรับการกำหนดค่าปัจจุบัน นี่คือตัวแปร $(CC) ในสภาพแวดล้อม "Make" จึงต้องใช้ Flag --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

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

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

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

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

--start_app

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

--debug_app

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

--start=_start_type_

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

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

--adb=path

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

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

--adb_arg=serial

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

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

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

adb -s deadbeef install ...

--incremental_install_verbosity=number

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

dump

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

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

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

analyze-profile

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

canonicalize-flags

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

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

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

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

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

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

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

--output_base=dir

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

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

เช่น

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

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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