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

รายงานปัญหา ดูแหล่งที่มา รุ่น Nightly · 7.4 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

ตัวเลือก

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

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

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

--package_path

คำเตือน: ระบบเลิกใช้งานตัวเลือก --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% ใน package-path เป็น /home/bob/clients/bob_client/bazel
  3. ส่วนรายการอื่นๆ จะยึดตามไดเรกทอรีที่ใช้งานอยู่ ซึ่งปกติแล้วไม่ใช่สิ่งที่คุณต้องการทำ และอาจทํางานอย่างไม่คาดคิดหากคุณใช้ Bazel จากไดเรกทอรีที่อยู่ด้านล่างเวิร์กสเปซ Bazel ตัวอย่างเช่น หากคุณใช้องค์ประกอบ package-path . แล้ว cd ไปยังไดเรกทอรี /home/bob/clients/bob_client/bazel/foo ระบบจะแก้ไขแพ็กเกจจากไดเรกทอรี /home/bob/clients/bob_client/bazel/foo

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

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

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

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch 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 จะลบข้อมูลการแก้ไขข้อบกพร่องออกจากไฟล์ไบนารีและไลบรารีที่ใช้ร่วมกันทั้งหมดหรือไม่ โดยเรียกใช้โปรแกรมลิงก์ด้วยตัวเลือก -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 ค่าเริ่มต้นคือ 11 --> ค่าที่เป็นไปได้คือ 8, 9, 10, 11, 17 และ 21 และอาจขยายได้โดย registering custom Java toolchains using default_java_toolchain

--tool_java_language_version=version

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

--java_runtime_version=version

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

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

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

ค่าเริ่มต้นคือ local_jdk ค่าที่เป็นไปได้คือ local_jdk, local_jdk_version, remotejdk_11, remotejdk_17 และ remotejdk_21 คุณสามารถขยายค่าได้โดยลงทะเบียน 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 จะสร้างข้อผิดพลาดแทนคำเตือน ซึ่งจะทำให้เป้าหมายปัจจุบันสร้างไม่สำเร็จหากพบการพึ่งพาโดยตรงที่ขาดหายไป ลักษณะการทำงานนี้เป็นลักษณะเริ่มต้นด้วยเมื่อไม่ได้ระบุ Flag

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

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

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

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

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

--cpu=cpu

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

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

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

--[no]experimental_extra_action_top_level_only

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

--experimental_extra_action_filter=regex

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

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

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

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

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

--host_cpu=cpu

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

--android_platforms=platform[,platform]*

แพลตฟอร์มที่จะสร้าง deps แบบทรานซิทีฟของกฎ android_binary (โดยเฉพาะสําหรับข้อกําหนดของเนทีฟ เช่น C++) ตัวอย่างเช่น หาก cc_library ปรากฏใน deps แบบทรานซิทีฟของกฎ android_binary ระบบจะสร้าง cc_library 1 ครั้งสําหรับแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms สําหรับกฎ android_binary และรวมไว้ในเอาต์พุตสุดท้าย

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

ระบบจะสร้างไฟล์ .so 1 ไฟล์และแพ็กเกจไว้ใน APK สำหรับแต่ละแพลตฟอร์มที่ระบุด้วย --android_platforms ชื่อไฟล์ .so จะขึ้นต้นด้วย "lib" ตามด้วยชื่อกฎ android_binary เช่น หากชื่อของ android_binary คือ "foo" ไฟล์จะเป็น libfoo.so

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

หากมี ไฟล์ C++ ที่มีป้ายกำกับหรือเส้นทางการเรียกใช้ที่ตรงกับนิพจน์ทั่วไปสำหรับการรวมรายการใดรายการหนึ่งและไม่ตรงกับนิพจน์ทั่วไปสำหรับการยกเว้นรายการใดรายการหนึ่งจะสร้างขึ้นด้วยตัวเลือกที่ระบุ การจับคู่ป้ายกำกับจะใช้รูปแบบ Canonical ของป้ายกำกับ (เช่น //package:label_name)

เส้นทางการดําเนินการคือเส้นทางแบบสัมพัทธ์ไปยังไดเรกทอรีเวิร์กสเปซ รวมถึงชื่อพื้นฐาน (รวมถึงนามสกุล) ของไฟล์ C++ รวมถึงคำนำหน้าแบบแพลตฟอร์มด้วย

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

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

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

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

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

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

--dynamic_mode=mode

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

โหมด

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

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

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

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

--force_ignore_dash_static

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

--[no]force_pic

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

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--compiler=version

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

--android_sdk=label

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

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

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

--java_toolchain=label

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

--host_java_toolchain=label

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

--javabase=(label)

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

--host_javabase=label

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

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

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

--spawn_strategy=strategy

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

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

--strategy mnemonic=strategy

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

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

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

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

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

--genrule_strategy=strategy

นี่เป็นอักษรย่อของ --strategy=Genrule=strategy ที่ใช้ไม่ได้แล้ว

--jobs=n (-j)

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

--progress_report_interval=n

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

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

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

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

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

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

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

--[no]build_runfile_manifests

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

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

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

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

--[no]use_ijars

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

--[no]interface_shared_objects

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

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

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

--[no]build

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

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

--[no]build_tests_only

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

--[no]check_up_to_date

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

โปรดดู--check_tests_up_to_date

--[no]compile_one_dependency

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

--save_temps

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

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

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

--build_tag_filters=tag[,tag]*

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

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

--test_size_filters=size[,size]*

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

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

และ

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

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

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

--test_timeout_filters=timeout[,timeout]*

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

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

--test_tag_filters=tag[,tag]*

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

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

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

--test_filter=filter-expression

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

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

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

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

--explain=logfile

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

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

--verbose_explanations

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

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

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

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

--profile=file

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

--[no]show_loading_progress

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

--[no]show_progress

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

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

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

--sandbox_debug

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

--subcommands (-s)

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

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

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

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

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

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

--verbose_failures

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

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

สถานะ Workspace

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

--workspace_status_command=program

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

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

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

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

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

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

สัญญามีเนื้อหาดังนี้

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

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

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

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

    • BUILD_TIMESTAMP: เวลาของบิลด์เป็นวินาทีนับตั้งแต่ Unix Epoch (ค่าของ System.currentTimeMillis() หารด้วย 1,000)
    • FORMATTED_DATE: เวลาของบิลด์ในรูปแบบ yyyy MMM d HH mm ss EEE(เช่น 2023 มิ.ย. 2 01 44 29 ศุกร์) ใน UTC

ใน Linux/macOS คุณสามารถส่ง --workspace_status_command=/bin/true เพื่อปิดใช้การดึงข้อมูลสถานะเวิร์กスペースได้ เนื่องจาก true จะไม่ดําเนินการใดๆ เลย (ออกด้วยค่า 0) และจะไม่แสดงผลลัพธ์ ใน Windows คุณสามารถส่งเส้นทางของ true.exe ใน MSYS เพื่อให้ได้ผลลัพธ์เดียวกัน

หากคําสั่งสถานะเวิร์กสเปซไม่สําเร็จ (ออกไม่ใช่ 0) ไม่ว่าด้วยเหตุผลใดก็ตาม การสร้างจะล้มเหลว

ตัวอย่างโปรแกรมใน Linux ที่ใช้ Git

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

ส่งเส้นทางของโปรแกรมนี้ด้วย --workspace_status_command แล้วไฟล์สถานะที่เสถียรจะมีบรรทัด STABLE และไฟล์สถานะที่ไม่เสถียรจะมีบรรทัดที่เหลือ

--[no]stamp

ตัวเลือกนี้ใช้ร่วมกับแอตทริบิวต์กฎ stamp เพื่อควบคุมว่าจะฝังข้อมูลบิลด์ในไบนารีหรือไม่

คุณเปิดหรือปิดใช้การประทับอย่างชัดแจ้งในแต่ละกฎได้โดยใช้แอตทริบิวต์ stamp โปรดดูรายละเอียดในสารานุกรมบิลด์ เมื่อกฎตั้งค่า stamp = -1 (ค่าเริ่มต้นสำหรับกฎ *_binary) ตัวเลือกนี้จะกำหนดว่าจะเปิดใช้การประทับหรือไม่

Bazel จะไม่ประทับตราไบนารีที่สร้างขึ้นสำหรับการกำหนดค่า exec ไม่ว่าตัวเลือกนี้หรือแอตทริบิวต์ 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

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

--toolchain_resolution_debug=regex

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

เบ็ดเตล็ด

--flag_alias=alias_name=target_path

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

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

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

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

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

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

--platform_suffix=string

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

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

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

การทดสอบที่ทำงานอยู่

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

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

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

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

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

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

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

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

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

--check_tests_up_to_date

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

ตัวเลือกนี้ยังใช้กับลักษณะการทํางานของ --check_up_to_date ด้วย

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

--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 หรือจำนวนการทดสอบที่ผ่านทั้งหมด การทดสอบที่ไม่ผ่านความพยายามทั้งหมดที่อนุญาตจะถือว่าไม่ผ่าน

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

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

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

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

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

--run_under=command-prefix

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

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

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

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

ตัวอย่าง

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

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

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

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

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

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

คําสั่ง bazel run คล้ายกับ bazel build ยกเว้นว่าจะใช้สร้างและเรียกใช้เป้าหมายเดียว เซสชันทั่วไปมีดังนี้ (//java/myapp:myapp ทักทายและพิมพ์ 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 สร้างขึ้นโดยตรง และลักษณะการทํางานจะแตกต่างกันไปโดยขึ้นอยู่กับว่าไบนารีที่จะเรียกใช้เป็นการทดสอบหรือไม่

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

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

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

  • BUILD_WORKSPACE_DIRECTORY: รูทของเวิร์กスペースที่เรียกใช้บิลด์
  • BUILD_WORKING_DIRECTORY: ไดเรกทอรีที่ใช้งานอยู่ในปัจจุบันซึ่งใช้เรียกใช้ Bazel
  • BUILD_ID: รหัสบิลด์ของคําเรียกใช้ bazel run ซึ่งโดยปกติแล้วจะเป็นค่าที่ไม่ซ้ำกัน ยกเว้นในกรณีที่มีการเรียกใช้ Bazel ด้วย --script_path และใช้สคริปต์ที่ได้ซ้ำ
  • BUILD_EXECROOT: รูทการดําเนินการของการเรียกใช้ bazel run

ซึ่งอาจใช้เพื่อตีความชื่อไฟล์ในบรรทัดคำสั่งในลักษณะที่ใช้งานง่าย

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

--run_under=command-prefix

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

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

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

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

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

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

การล้างเอาต์พุตการสร้าง

คำสั่ง clean

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

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

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

  % bazel clean --expunge

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

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

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

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

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

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

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

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

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

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

info

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

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

ข้อมูลที่ไม่ต้องกำหนดค่า

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

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

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

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

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

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

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

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

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

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

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

% bazel info server_pid
1285

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

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

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

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version และ --version

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

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

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

mobile-install

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

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

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

--incremental

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

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

--split_apks

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

--output_user_root=dir

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

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

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

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

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

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

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

--host_jvm_debug

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

--autodetect_server_javabase

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

--batch

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

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

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

--max_idle_secs=n

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

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

--[no]shutdown_on_low_sys_mem

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

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

--[no]block_for_lock

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

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

--io_nice_level=n

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

--batch_cpu_scheduling

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

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

--[no]announce_rc

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

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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