Perintah dan Opsi

Halaman ini membahas opsi yang tersedia dengan berbagai perintah Bazel, seperti bazel build, bazel run, dan bazel test. Halaman ini adalah pendamping untuk daftar perintah Bazel di Membangun dengan Bazel.

Sintaksis target

Beberapa perintah, seperti build atau test, dapat beroperasi pada daftar target. Target ini menggunakan sintaksis yang lebih fleksibel daripada label, yang didokumentasikan dalam Menentukan target untuk membangun.

Opsi

Bagian berikut menjelaskan opsi yang tersedia selama build. Jika --long digunakan pada perintah bantuan, pesan bantuan online memberikan informasi ringkasan tentang arti, jenis, dan nilai default untuk setiap opsi.

Sebagian besar opsi hanya dapat ditentukan satu kali. Jika ditentukan beberapa kali, instance terakhir yang akan digunakan. Opsi yang dapat ditentukan beberapa kali diidentifikasi dalam bantuan online dengan teks 'dapat digunakan beberapa kali'.

Lokasi paket

--package_path

PERINGATAN: Opsi --package_path tidak digunakan lagi. Bazel lebih memilih paket di repositori utama berada di bawah root ruang kerja.

Opsi ini menentukan kumpulan direktori yang ditelusuri untuk menemukan file BUILD untuk paket tertentu.

Bazel menemukan paketnya dengan menelusuri jalur paket. Ini adalah daftar berurutan direktori bazel yang dipisahkan dengan titik dua, yang masing-masing merupakan root dari pohon sumber parsial.

Untuk menentukan jalur paket kustom menggunakan opsi --package_path:

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

Elemen jalur paket dapat ditentukan dalam tiga format:

1. Jika karakter pertama adalah /, jalur bersifat absolut.
2. Jika jalur dimulai dengan %workspace%, jalur akan diambil relatif ke direktori bazel terdekat. Misalnya, jika direktori kerja Anda adalah /home/bob/clients/bob_client/bazel/foo, maka string %workspace% di package-path akan diperluas menjadi /home/bob/clients/bob_client/bazel.
3. Hal lainnya diambil relatif terhadap direktori kerja. Biasanya, Anda tidak bermaksud melakukan hal ini, dan mungkin berperilaku tidak terduga jika Anda menggunakan Bazel dari direktori di bawah ruang kerja bazel. Misalnya, jika Anda menggunakan elemen package-path ., lalu cd ke direktori /home/bob/clients/bob_client/bazel/foo, paket akan diselesaikan dari direktori /home/bob/clients/bob_client/bazel/foo.

Jika Anda menggunakan jalur paket non-default, tentukan di file konfigurasi Bazel untuk mempermudah.

Bazel tidak mengharuskan paket apa pun berada di direktori saat ini, sehingga Anda dapat melakukan build dari ruang kerja bazel kosong jika semua paket yang diperlukan dapat ditemukan di tempat lain di jalur paket.

Contoh: Membangun dari klien kosong

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

--deleted_packages

Opsi ini menentukan daftar paket yang dipisahkan koma yang harus dianggap dihapus oleh Bazel, dan tidak mencoba memuat dari direktori mana pun di jalur paket. Tindakan ini dapat digunakan untuk menyimulasikan penghapusan paket tanpa benar-benar menghapusnya. Opsi ini dapat diteruskan beberapa kali, dan dalam hal ini daftar individual digabungkan.

Memeriksa error

Opsi ini mengontrol pemeriksaan error dan/atau peringatan Bazel.

--[no]check_visibility

Jika opsi ini disetel ke false, pemeriksaan visibilitas akan diturunkan menjadi peringatan. Nilai default opsi ini adalah benar, sehingga secara default, pemeriksaan visibilitas dilakukan.

--output_filter=regex

Opsi --output_filter hanya akan menampilkan peringatan build dan kompilasi untuk target yang cocok dengan ekspresi reguler. Jika target tidak cocok dengan ekspresi reguler yang diberikan dan eksekusinya berhasil, output standar dan error standarnya akan dibuang.

Berikut beberapa nilai umum untuk opsi ini:

Tombol alat

Opsi ini mengontrol opsi mana yang akan diteruskan Bazel ke alat lain.

--copt=cc-option

Opsi ini mengambil argumen yang akan diteruskan ke compiler. Argumen akan diteruskan ke compiler setiap kali dipanggil untuk praproses, kompilasi, dan/atau perakitan kode C, C++, atau assembler. Tidak akan diteruskan saat menautkan.

Opsi ini dapat digunakan beberapa kali. Contoh:

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

akan mengompilasi library foo tanpa tabel debug, sehingga menghasilkan kode yang independen dari posisi.

--host_copt=cc-option

Opsi ini mengambil argumen yang akan diteruskan ke compiler untuk file sumber yang dikompilasi dalam konfigurasi exec. Hal ini serupa dengan opsi --copt, tetapi hanya berlaku untuk konfigurasi exec.

--host_conlyopt=cc-option

Opsi ini mengambil argumen yang akan diteruskan ke compiler untuk file sumber C yang dikompilasi dalam konfigurasi exec. Hal ini serupa dengan opsi --conlyopt, tetapi hanya berlaku untuk konfigurasi exec.

--host_cxxopt=cc-option

Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber C++ yang dikompilasi dalam konfigurasi exec. Hal ini serupa dengan opsi --cxxopt, tetapi hanya berlaku untuk konfigurasi exec.

--host_linkopt=linker-option

Opsi ini mengambil argumen yang akan diteruskan ke linker untuk file sumber yang dikompilasi dalam konfigurasi exec. Hal ini serupa dengan opsi --linkopt, tetapi hanya berlaku untuk konfigurasi exec.

--conlyopt=cc-option

Opsi ini memerlukan argumen yang akan diteruskan ke compiler saat mengompilasi file sumber C.

Opsi ini mirip dengan --copt, tetapi hanya berlaku untuk kompilasi C, bukan untuk kompilasi atau penautan C++. Jadi, Anda dapat meneruskan opsi khusus C (seperti -Wno-pointer-sign) menggunakan --conlyopt.

--cxxopt=cc-option

Opsi ini memerlukan argumen yang akan diteruskan ke compiler saat mengompilasi file sumber C++.

Ini mirip dengan --copt, tetapi hanya berlaku untuk kompilasi C++, bukan untuk kompilasi atau penautan C. Jadi, Anda dapat meneruskan opsi khusus C++ (seperti -fpermissive atau -fno-implicit-templates) menggunakan --cxxopt.

Contoh:

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

--linkopt=linker-option

Opsi ini mengambil argumen yang akan diteruskan ke compiler saat menautkan.

Hal ini mirip dengan --copt, tetapi hanya berlaku untuk penautan, bukan kompilasi. Jadi, Anda dapat meneruskan opsi compiler yang hanya masuk akal pada waktu penautan (seperti -lssp atau -Wl,--wrap,abort) menggunakan --linkopt. Contoh:

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

Aturan build juga dapat menentukan opsi link dalam atributnya. Setelan opsi ini selalu diprioritaskan. Lihat juga cc_library.linkopts.

--strip (always|never|sometimes)

Opsi ini menentukan apakah Bazel akan menghapus informasi pen-debug-an dari semua biner dan library bersama, dengan memanggil linker menggunakan opsi -Wl,--strip-debug. --strip=always berarti selalu menghapus informasi proses debug. --strip=never berarti tidak pernah menghapus informasi proses debug. Nilai default --strip=sometimes berarti hapus jika --compilation_mode adalah fastbuild.

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

akan mengompilasi target sambil menghapus informasi pen-debug-an dari semua biner yang dihasilkan.

Opsi --strip Bazel sesuai dengan opsi --strip-debug ld: opsi ini hanya menghapus informasi proses debug. Jika karena alasan tertentu Anda ingin menghapus semua simbol, bukan hanya simbol debug, Anda harus menggunakan opsi --strip-all ld, yang dapat Anda lakukan dengan meneruskan --linkopt=-Wl,--strip-all ke Bazel. Perlu juga diperhatikan bahwa menyetel flag --strip Bazel akan menggantikan --linkopt=-Wl,--strip-all, jadi Anda hanya boleh menyetel salah satunya.

Jika Anda hanya membuat satu biner dan ingin semua simbol dihapus, Anda juga dapat meneruskan --stripopt=--strip-all dan membuat versi //foo:bar.stripped target secara eksplisit. Seperti yang dijelaskan di bagian tentang --stripopt, ini menerapkan tindakan penghapusan setelah biner akhir ditautkan, bukan menyertakan penghapusan di semua tindakan penautan build.

--stripopt=strip-option

Ini adalah opsi tambahan yang akan diteruskan ke perintah strip saat membuat biner *.stripped. Defaultnya adalah -S -p. Opsi ini dapat digunakan beberapa kali.

--fdo_instrument=profile-output-dir

Opsi --fdo_instrument memungkinkan pembuatan output profil FDO (pengoptimalan yang diarahkan oleh masukan) saat biner C/C++ yang di-build dijalankan. Untuk GCC, argumen yang diberikan digunakan sebagai awalan direktori untuk struktur direktori file per objek dari file .gcda yang berisi informasi profil untuk setiap file .o.

Setelah hierarki data profil dibuat, hierarki profil harus di-zip, dan diberikan ke opsi --fdo_optimize=profile-zip Bazel untuk mengaktifkan kompilasi yang dioptimalkan untuk FDO.

Untuk compiler LLVM, argumennya juga merupakan direktori tempat file data profil LLVM mentah di-dump. Contoh: --fdo_instrument=/path/to/rawprof/dir/

Opsi --fdo_instrument dan --fdo_optimize tidak dapat digunakan secara bersamaan.

--fdo_optimize=profile-zip

Opsi --fdo_optimize memungkinkan penggunaan informasi profil file per objek untuk melakukan pengoptimalan FDO (pengoptimalan yang diarahkan oleh umpan balik) saat mengompilasi. Untuk GCC, argumen yang diberikan adalah file zip yang berisi struktur file .gcda yang dibuat sebelumnya yang berisi informasi profil untuk setiap file .o.

Atau, argumen yang diberikan dapat mengarah ke profil otomatis yang diidentifikasi oleh ekstensi .afdo.

Untuk compiler LLVM, argumen yang diberikan harus mengarah ke file output profil LLVM terindeks yang disiapkan oleh alat llvm-profdata, dan harus memiliki ekstensi .profdata.

Opsi --fdo_instrument dan --fdo_optimize tidak dapat digunakan secara bersamaan.

--java_language_version=version

Opsi ini menentukan versi sumber Java. Contoh:

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

mengompilasi dan hanya mengizinkan konstruksi yang kompatibel dengan spesifikasi Java 8. Nilai defaultnya adalah 11. --> Nilai yang mungkin adalah: 8, 9, 10, 11, 17, dan 21, dan dapat diperluas dengan mendaftarkan toolchain Java kustom menggunakan default_java_toolchain.

--tool_java_language_version=version

Versi bahasa Java yang digunakan untuk mem-build alat yang dieksekusi selama build. Nilai defaultnya adalah 11.

--java_runtime_version=version

Opsi ini menentukan versi JVM yang akan digunakan untuk mengeksekusi kode dan menjalankan pengujian. Contoh:

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

mendownload JDK 11 dari repositori jarak jauh dan menjalankan aplikasi Java menggunakan JDK tersebut.

Nilai defaultnya adalah local_jdk. Nilai yang mungkin adalah: local_jdk, local_jdk_version, remotejdk_11, remotejdk_17, dan remotejdk_21. Anda dapat memperluas nilai dengan mendaftarkan JVM kustom menggunakan aturan repositori local_java_repository atau remote_java_repository.

--tool_java_runtime_version=version

Versi JVM yang digunakan untuk menjalankan alat yang diperlukan selama build. Nilai defaultnya adalah remotejdk_11.

--jvmopt=jvm-option

Opsi ini memungkinkan argumen opsi diteruskan ke VM Java. Fungsi ini dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:

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

akan menggunakan VM server untuk meluncurkan semua biner Java dan menetapkan ukuran heap startup untuk VM menjadi 256 MB.

--javacopt=javac-option

Opsi ini memungkinkan argumen opsi diteruskan ke javac. Fungsi ini dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:

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

akan membangun ulang java_binary dengan info debug default javac (bukan default bazel).

Opsi ini diteruskan ke javac setelah opsi default bawaan Bazel untuk javac dan sebelum opsi per aturan. Spesifikasi terakhir dari opsi apa pun ke javac akan menang. Opsi default untuk javac adalah:

  -source 8 -target 8 -encoding UTF-8

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

Opsi ini mengontrol apakah javac memeriksa dependensi langsung yang tidak ada. Target Java harus secara eksplisit mendeklarasikan semua target yang digunakan secara langsung sebagai dependensi. Flag ini menginstruksikan javac untuk menentukan JAR yang benar-benar digunakan untuk pemeriksaan jenis setiap file java, dan memperingatkan/menampilkan error jika JAR tersebut bukan output dari dependensi langsung target saat ini.

• off berarti pemeriksaan dinonaktifkan.
• warn berarti javac akan menghasilkan peringatan java standar berjenis [strict] untuk setiap dependensi langsung yang tidak ada.
• default, strict, dan error semuanya berarti javac akan menghasilkan error, bukan peringatan, sehingga menyebabkan target saat ini gagal dibuat jika ada dependensi langsung yang tidak ada. Ini juga merupakan perilaku default jika tanda tidak ditentukan.

Membangun semantik

Opsi ini memengaruhi perintah build dan/atau konten file output.

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

Opsi --compilation_mode (sering disingkat menjadi -c, terutama -c opt) menggunakan argumen fastbuild, dbg atau opt, dan memengaruhi berbagai opsi pembuatan kode C/C++, seperti tingkat pengoptimalan dan kelengkapan tabel debug. Bazel menggunakan direktori output yang berbeda untuk setiap mode kompilasi yang berbeda, sehingga Anda dapat beralih antar-mode tanpa perlu melakukan pembangunan ulang penuh setiap saat.

• fastbuild berarti build secepat mungkin: buat informasi proses debug minimal (-gmlt -Wl,-S), dan jangan lakukan pengoptimalan. Ini adalah defaultnya. Catatan: -DNDEBUG tidak akan ditetapkan.
• dbg berarti build dengan proses debug diaktifkan (-g), sehingga Anda dapat menggunakan gdb (atau debugger lain).
• opt berarti build dengan pengoptimalan diaktifkan dan dengan panggilan assert() dinonaktifkan (-O2 -DNDEBUG). Informasi pen-debug-an tidak akan dibuat dalam mode opt kecuali jika Anda juga meneruskan --copt -g.

--cpu=cpu

Opsi ini menentukan arsitektur CPU target yang akan digunakan untuk kompilasi biner selama build.

--action_env=VAR=VALUE

Menentukan kumpulan variabel lingkungan yang tersedia selama eksekusi semua tindakan. Variabel dapat ditentukan berdasarkan nama, yang dalam hal ini nilai akan diambil dari lingkungan pemanggilan, atau berdasarkan pasangan name=value yang menetapkan nilai secara independen dari lingkungan pemanggilan.

Flag --action_env ini dapat ditentukan beberapa kali. Jika nilai ditetapkan ke variabel yang sama di beberapa tanda --action_env, penetapan terbaru akan menang.

--experimental_action_listener=label

Opsi experimental_action_listener menginstruksikan Bazel untuk menggunakan detail dari aturan action_listener yang ditentukan oleh label untuk menyisipkan extra_actions ke dalam grafik build.

--[no]experimental_extra_action_top_level_only

Jika opsi ini ditetapkan ke benar (true), tindakan tambahan yang ditentukan oleh opsi baris perintah --experimental_action_listener hanya akan dijadwalkan untuk target tingkat teratas.

--experimental_extra_action_filter=regex

Opsi experimental_extra_action_filter menginstruksikan Bazel untuk memfilter kumpulan target yang akan dijadwalkan extra_actions.

Flag ini hanya berlaku jika digabungkan dengan flag --experimental_action_listener.

Secara default, semua extra_actions dalam penutupan transitif target yang diminta untuk dibangun dijadwalkan untuk dieksekusi. --experimental_extra_action_filter akan membatasi penjadwalan ke extra_actions yang label pemiliknya cocok dengan ekspresi reguler yang ditentukan.

Contoh berikut akan membatasi penjadwalan extra_actions agar hanya berlaku untuk tindakan yang label pemiliknya berisi '/bar/':

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

--host_cpu=cpu

Opsi ini menentukan nama arsitektur CPU yang harus digunakan untuk membuat alat host.

--android_platforms=platform[,platform]*

Platform untuk membangun deps transitif dari aturan android_binary (khususnya untuk dependensi native seperti C++). Misalnya, jika cc_library muncul di deps transitif dari aturan android_binary, cc_library akan dibangun satu kali untuk setiap platform yang ditentukan dengan --android_platforms untuk aturan android_binary, dan disertakan dalam output akhir.

Tidak ada nilai default untuk tanda ini: platform Android kustom harus ditentukan dan digunakan.

Satu file .so dibuat dan dikemas dalam APK untuk setiap platform yang ditentukan dengan --android_platforms. Nama file .so memberi awalan pada nama aturan android_binary dengan "lib". Misalnya, jika nama android_binary adalah "foo", maka file tersebut adalah libfoo.so.

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

Jika ada, setiap file C++ dengan label atau jalur eksekusi yang cocok dengan salah satu ekspresi regex penyertaan dan tidak cocok dengan ekspresi pengecualian mana pun akan dibangun dengan opsi yang diberikan. Pencocokan label menggunakan bentuk kanonis label (yaitu //package:label_name).

Jalur eksekusi adalah jalur relatif ke direktori ruang kerja Anda, termasuk nama dasar (termasuk ekstensi) file C++. Hal ini juga mencakup awalan yang bergantung pada platform.

Untuk mencocokkan file yang dihasilkan (seperti output genrule), Bazel hanya dapat menggunakan jalur eksekusi. Dalam hal ini, ekspresi reguler tidak boleh diawali dengan '//' karena tidak cocok dengan jalur eksekusi apa pun. Nama paket dapat digunakan seperti ini: --per_file_copt=base/.*\.pb\.cc@-g0. Ini akan mencocokkan setiap file .pb.cc di direktori bernama base.

Opsi ini dapat digunakan beberapa kali.

Opsi ini diterapkan terlepas dari mode kompilasi yang digunakan. Misalnya, Anda dapat mengompilasi dengan --compilation_mode=opt dan mengompilasi beberapa file secara selektif dengan mengaktifkan pengoptimalan yang lebih kuat, atau dengan menonaktifkan pengoptimalan.

Peringatan: Jika beberapa file dikompilasi secara selektif dengan simbol debug, simbol tersebut mungkin dihapus selama penautan. Hal ini dapat dicegah dengan menetapkan --strip=never.

Sintaksis: [+-]regex[,[+-]regex]...@option[,option]... dengan regex adalah ekspresi reguler yang dapat diberi awalan + untuk mengidentifikasi pola sertakan dan - untuk mengidentifikasi pola kecualikan. option adalah opsi arbitrer yang diteruskan ke compiler C++. Jika opsi berisi ,, opsi tersebut harus dikutip seperti ini \,. Opsi juga dapat berisi @, karena hanya @ pertama yang digunakan untuk memisahkan ekspresi reguler dari opsi.

Contoh: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs menambahkan opsi -O0 dan -fprofile-arcs ke command line compiler C++ untuk semua file .cc di //foo/, kecuali file.cc.

--dynamic_mode=mode

Menentukan apakah biner C++ akan ditautkan secara dinamis, berinteraksi dengan atribut linkstatic pada aturan build.

Mode:

• default: Memungkinkan bazel memilih apakah akan menautkan secara dinamis. Lihat linkstatic untuk mengetahui informasi selengkapnya.
• fully: Menautkan semua target secara dinamis. Tindakan ini akan mempercepat waktu penautan dan mengurangi ukuran biner yang dihasilkan.
• off: Menautkan semua target dalam mode sebagian besar statis. Jika -static ditetapkan di linkopts, target akan berubah menjadi sepenuhnya statis.

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

Mengaktifkan Fission, yang menulis informasi debug C++ ke file .dwo khusus, bukan file .o, yang seharusnya ditulis ke sana. Hal ini secara substansial mengurangi ukuran input ke link dan dapat mengurangi waktu penautan.

Jika disetel ke [dbg][,opt][,fastbuild] (contoh: --fission=dbg,fastbuild), Fission hanya diaktifkan untuk kumpulan mode kompilasi yang ditentukan. Hal ini berguna untuk setelan bazelrc. Jika disetel ke yes, Fission akan diaktifkan secara universal. Jika disetel ke no, Fission akan dinonaktifkan secara universal. Default-nya adalah no.

--force_ignore_dash_static

Jika tanda ini disetel, semua opsi -static di linkopts file BUILD aturan cc_* akan diabaikan. Hal ini hanya dimaksudkan sebagai solusi untuk build penguatan C++.

--[no]force_pic

Jika diaktifkan, semua kompilasi C++ menghasilkan kode independen posisi ("-fPIC"), link lebih memilih library bawaan PIC daripada library non-PIC, dan link menghasilkan dapat dieksekusi independen posisi ("-pie"). Default-nya adalah dinonaktifkan.

--android_resource_shrinking

Memilih apakah akan melakukan pengecilan resource untuk aturan android_binary. Menetapkan default untuk atribut shrink_resources pada aturan android_binary; lihat dokumentasi untuk aturan tersebut guna mengetahui detail lebih lanjut. Nonaktif secara default.

--custom_malloc=malloc-library-target

Jika ditentukan, selalu gunakan implementasi malloc yang diberikan, menggantikan semua atribut malloc="target", termasuk di target yang menggunakan default (dengan tidak menentukan malloc apa pun).

--crosstool_top=label

Opsi ini menentukan lokasi rangkaian compiler crosstool yang akan digunakan untuk semua kompilasi C++ selama build. Bazel akan mencari file CROSSTOOL di lokasi tersebut dan menggunakannya untuk menentukan setelan --compiler secara otomatis.

--host_crosstool_top=label

Jika tidak ditentukan, Bazel akan menggunakan nilai --crosstool_top untuk mengompilasi kode dalam konfigurasi eksekusi, seperti alat yang dijalankan selama build. Tujuan utama tanda ini adalah untuk mengaktifkan kompilasi silang.

--apple_crosstool_top=label

Crosstool yang akan digunakan untuk mengompilasi aturan C/C++ dalam deps transitif dari aturan objc*, ios*, dan apple*. Untuk target tersebut, tanda ini menggantikan --crosstool_top.

--compiler=version

Opsi ini menentukan versi compiler C/C++ (seperti gcc-4.1.0) yang akan digunakan untuk kompilasi biner selama build. Jika Anda ingin membangun dengan crosstool kustom, Anda harus menggunakan file CROSSTOOL, bukan menentukan flag ini.

--android_sdk=label

Tidak digunakan lagi. Hal ini tidak boleh ditentukan secara langsung.

Opsi ini menentukan toolchain Android SDK/platform dan library runtime Android yang akan digunakan untuk membangun aturan terkait Android.

Android SDK akan otomatis dipilih jika aturan android_sdk_repository ditentukan dalam file WORKSPACE.

--java_toolchain=label

No-op. Hanya dipertahankan untuk kompatibilitas mundur.

--host_java_toolchain=label

No-op. Hanya dipertahankan untuk kompatibilitas mundur.

--javabase=(label)

No-op. Hanya dipertahankan untuk kompatibilitas mundur.

--host_javabase=label

No-op. Hanya dipertahankan untuk kompatibilitas mundur.

Strategi eksekusi

Opsi ini memengaruhi cara Bazel akan mengeksekusi build. Hal ini tidak akan berdampak signifikan pada file output yang dihasilkan oleh build. Biasanya, efek utamanya adalah pada kecepatan build.

--spawn_strategy=strategy

Opsi ini mengontrol tempat dan cara perintah dieksekusi.

• standalone menyebabkan perintah dieksekusi sebagai subproses lokal. Nilai ini tidak digunakan lagi. Sebagai gantinya, gunakan local.
• sandboxed menyebabkan perintah dieksekusi di dalam sandbox di mesin lokal. Hal ini mengharuskan semua file input, dependensi data, dan alat dicantumkan sebagai dependensi langsung dalam atribut srcs, data, dan tools. Bazel mengaktifkan sandbox lokal secara default, pada sistem yang mendukung eksekusi sandbox.
• local menyebabkan perintah dieksekusi sebagai subproses lokal.
• worker menyebabkan perintah dieksekusi menggunakan pekerja persisten, jika tersedia.
• docker menyebabkan perintah dieksekusi di dalam sandbox docker di komputer lokal. Langkah ini mengharuskan Docker diinstal.
• remote menyebabkan perintah dieksekusi dari jarak jauh; ini hanya tersedia jika pelaksana jarak jauh telah dikonfigurasi secara terpisah.

--strategy mnemonic=strategy

Opsi ini mengontrol tempat dan cara perintah dieksekusi, menggantikan --spawn_strategy (dan --genrule_strategy dengan mnemonic Genrule) berdasarkan per-mnemonic. Lihat --spawn_strategy untuk mengetahui strategi yang didukung dan efeknya.

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

Opsi ini menentukan strategi mana yang harus digunakan untuk menjalankan perintah yang memiliki deskripsi yang cocok dengan regex_filter tertentu. Lihat --per_file_copt untuk mengetahui detail tentang pencocokan regex_filter. Lihat --spawn_strategy untuk mengetahui strategi yang didukung dan efeknya.

regex_filter terakhir yang cocok dengan deskripsi akan digunakan. Opsi ini menggantikan flag lain untuk menentukan strategi.

• Contoh: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local berarti menjalankan tindakan menggunakan strategi local jika deskripsinya cocok dengan //foo.*.cc, tetapi tidak cocok dengan //foo/bar.
• Contoh: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed menjalankan 'Compiling //foo/bar/baz' dengan strategi sandboxed, tetapi membalikkan urutan akan menjalankannya dengan local.
• Contoh: --strategy_regexp='Compiling.*/bar=local,sandboxed' menjalankan 'Compiling //foo/bar/baz' dengan strategi local dan melakukan penggantian ke sandboxed jika gagal.

--genrule_strategy=strategy

Ini adalah singkatan yang tidak digunakan lagi untuk --strategy=Genrule=strategy.

--jobs=n (-j)

Opsi ini, yang menggunakan argumen bilangan bulat, menentukan batas jumlah tugas yang harus dijalankan secara serentak selama fase eksekusi build.

--progress_report_interval=n

Bazel secara berkala mencetak laporan progres pada tugas yang belum selesai (seperti pengujian yang berjalan lama). Opsi ini menetapkan frekuensi pelaporan, progres akan dicetak setiap n detik.

Nilai defaultnya adalah 0, yang berarti algoritma inkremental: laporan pertama akan dicetak setelah 10 detik, lalu 30 detik, dan setelah itu, progres dilaporkan setiap menit.

Saat bazel menggunakan kontrol kursor, seperti yang ditentukan oleh --curses, progres dilaporkan setiap detik.

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

Opsi ini menentukan jumlah resource lokal (RAM dalam MB dan jumlah core logis CPU) yang dapat dipertimbangkan Bazel saat menjadwalkan aktivitas build dan pengujian untuk dijalankan secara lokal. Argumen ini menggunakan bilangan bulat, atau kata kunci (HOST_RAM atau HOST_CPUS) yang secara opsional diikuti dengan [-|*float] (misalnya, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). Flag ini independen; salah satu atau keduanya dapat ditetapkan. Secara default, Bazel memperkirakan jumlah RAM dan jumlah core CPU langsung dari konfigurasi sistem lokal.

--[no]build_runfile_links

Opsi ini, yang diaktifkan secara default, menentukan apakah symlink runfile untuk pengujian dan biner harus dibuat di direktori output. Penggunaan --nobuild_runfile_links dapat berguna untuk memvalidasi apakah semua target dikompilasi tanpa menimbulkan overhead untuk membangun hierarki runfile.

Saat pengujian (atau aplikasi) dieksekusi, dependensi data waktu prosesnya dikumpulkan di satu tempat. Dalam struktur output Bazel, struktur "runfiles" ini biasanya berakar sebagai saudara dari biner atau pengujian yang sesuai. Selama eksekusi pengujian, runfile dapat diakses menggunakan jalur dalam bentuk $TEST_SRCDIR/canonical_repo_name/packagename/filename. Struktur runfile memastikan bahwa pengujian memiliki akses ke semua file yang memiliki dependensi yang dideklarasikan, dan tidak lebih. Secara default, hierarki runfile diimplementasikan dengan membuat serangkaian link simbolis ke file yang diperlukan. Seiring bertambahnya kumpulan link, biaya operasi ini juga meningkat, dan untuk beberapa build besar, hal ini dapat berkontribusi secara signifikan terhadap waktu build secara keseluruhan, terutama karena setiap pengujian (atau aplikasi) memerlukan hierarki file yang dapat dijalankan sendiri.

--[no]build_runfile_manifests

Opsi ini, yang diaktifkan secara default, menentukan apakah manifes file yang dapat dijalankan harus ditulis ke struktur output. Menonaktifkannya berarti --nobuild_runfile_links.

Fitur ini dapat dinonaktifkan saat menjalankan pengujian dari jarak jauh, karena hierarki runfile akan dibuat dari jarak jauh dari manifes dalam memori.

--[no]discard_analysis_cache

Jika opsi ini diaktifkan, Bazel akan menghapus cache analisis tepat sebelum eksekusi dimulai, sehingga membebaskan memori tambahan (sekitar 10%) untuk fase eksekusi. Kelemahannya adalah build inkremental selanjutnya akan lebih lambat. Lihat juga mode hemat memori.

--[no]keep_going (-k)

Seperti di GNU Make, fase eksekusi build berhenti saat kesalahan pertama terjadi. Terkadang, ada baiknya mencoba membangun sebanyak mungkin meskipun menghadapi error. Opsi ini mengaktifkan perilaku tersebut, dan jika ditentukan, build akan mencoba membangun setiap target yang prasyaratnya berhasil dibangun, tetapi akan mengabaikan error.

Meskipun opsi ini biasanya terkait dengan fase eksekusi build, opsi ini juga memengaruhi fase analisis: jika beberapa target ditentukan dalam perintah build, tetapi hanya beberapa di antaranya yang dapat dianalisis dengan berhasil, build akan berhenti dengan error kecuali jika --keep_going ditentukan, dalam hal ini build akan dilanjutkan ke fase eksekusi, tetapi hanya untuk target yang berhasil dianalisis.

--[no]use_ijars

Opsi ini mengubah cara target java_library dikompilasi oleh Bazel. Daripada menggunakan output java_library untuk mengompilasi target java_library dependen, Bazel akan membuat JAR antarmuka yang hanya berisi tanda tangan anggota non-pribadi (metode dan kolom akses publik, terlindungi, dan default (paket)) serta menggunakan JAR antarmuka untuk mengompilasi target dependen. Hal ini memungkinkan untuk menghindari kompilasi ulang saat perubahan hanya dilakukan pada isi metode atau anggota pribadi suatu class.

--[no]interface_shared_objects

Opsi ini mengaktifkan objek bersama antarmuka, yang membuat biner dan library bersama lainnya bergantung pada antarmuka objek bersama, bukan implementasinya. Jika hanya implementasi yang berubah, Bazel dapat menghindari pembangunan ulang target yang bergantung pada library bersama yang diubah secara tidak perlu.

Pemilihan output

Opsi ini menentukan apa yang akan di-build atau diuji.

--[no]build

Opsi ini menyebabkan fase eksekusi build terjadi; opsi ini aktif secara default. Jika dinonaktifkan, fase eksekusi akan dilewati, dan hanya dua fase pertama, yaitu pemuatan dan analisis, yang terjadi.

Opsi ini dapat berguna untuk memvalidasi file BUILD dan mendeteksi error dalam input, tanpa benar-benar membangun apa pun.

--[no]build_tests_only

Jika ditentukan, Bazel hanya akan membangun apa yang diperlukan untuk menjalankan aturan *_test dan test_suite yang tidak difilter karena ukuran, waktu tunggu, tag, atau bahasa. Jika ditentukan, Bazel akan mengabaikan target lain yang ditentukan di command line. Secara default, opsi ini dinonaktifkan dan Bazel akan membangun semua yang diminta, termasuk aturan *_test dan test_suite yang difilter dari pengujian. Hal ini berguna karena menjalankan bazel test --build_tests_only foo/... mungkin tidak mendeteksi semua kerusakan build di pohon foo.

--[no]check_up_to_date

Opsi ini menyebabkan Bazel tidak melakukan build, tetapi hanya memeriksa apakah semua target yang ditentukan sudah terbaru. Jika demikian, build akan berhasil diselesaikan seperti biasa. Namun, jika ada file yang sudah tidak berlaku, error akan dilaporkan dan build akan gagal, bukan dibuat. Opsi ini mungkin berguna untuk menentukan apakah build telah dilakukan lebih baru daripada pengeditan sumber (misalnya, untuk pemeriksaan sebelum pengiriman) tanpa menimbulkan biaya build.

Lihat juga --check_tests_up_to_date.

--[no]compile_one_dependency

Kompilasi satu dependensi file argumen. Hal ini berguna untuk memeriksa sintaksis file sumber di IDE, misalnya, dengan membangun kembali satu target yang bergantung pada file sumber untuk mendeteksi error sedini mungkin dalam siklus edit/build/pengujian. Argumen ini memengaruhi cara semua argumen non-flag ditafsirkan: setiap argumen harus berupa label target file atau nama file biasa yang relatif terhadap direktori kerja saat ini, dan satu aturan yang bergantung pada setiap nama file sumber dibuat. Untuk sumber C++ dan Java, aturan dalam ruang bahasa yang sama lebih dipilih. Untuk beberapa aturan dengan preferensi yang sama, aturan yang muncul pertama kali dalam file BUILD akan dipilih. Pola target yang diberi nama secara eksplisit yang tidak mereferensikan file sumber akan menghasilkan error.

--save_temps

Opsi --save_temps menyebabkan output sementara dari compiler disimpan. File ini mencakup file .s (kode assembler), .i (C yang telah diproses sebelumnya), dan .ii (C++ yang telah diproses sebelumnya). Output ini sering kali berguna untuk proses debug. File sementara hanya akan dibuat untuk kumpulan target yang ditentukan di command line.

Saat ini, tanda --save_temps hanya berfungsi untuk aturan cc_*.

Untuk memastikan Bazel mencetak lokasi file output tambahan, periksa apakah setelan --show_result n Anda cukup tinggi.

--build_tag_filters=tag[,tag]*

Jika ditentukan, Bazel hanya akan membangun target yang memiliki setidaknya satu tag yang diperlukan (jika ada yang ditentukan) dan tidak memiliki tag yang dikecualikan. Filter tag build ditentukan sebagai daftar kata kunci tag yang dipisahkan koma, yang secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag wajib juga dapat memiliki tanda '+' di depannya.

Saat menjalankan pengujian, Bazel mengabaikan --build_tag_filters untuk target pengujian, yang dibuat dan dijalankan meskipun tidak cocok dengan filter ini. Untuk menghindari pembuatan, filter target pengujian menggunakan --test_tag_filters atau dengan mengecualikannya secara eksplisit.

--test_size_filters=size[,size]*

Jika ditentukan, Bazel hanya akan menguji (atau membangun jika --build_tests_only juga ditentukan) target pengujian dengan ukuran yang diberikan. Filter ukuran pengujian ditentukan sebagai daftar nilai ukuran pengujian yang diizinkan yang dipisahkan dengan koma (kecil, sedang, besar, atau sangat besar), yang secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan ukuran pengujian yang dikecualikan. Misalnya,

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

dan

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

hanya akan menguji pengujian kecil dan sedang di dalam //foo.

Secara default, pemfilteran ukuran pengujian tidak diterapkan.

--test_timeout_filters=timeout[,timeout]*

Jika ditentukan, Bazel hanya akan menguji (atau membangun jika --build_tests_only juga ditentukan) target pengujian dengan waktu tunggu yang diberikan. Filter waktu tunggu pengujian ditentukan sebagai daftar nilai waktu tunggu pengujian yang diizinkan yang dipisahkan koma (pendek, sedang, panjang, atau abadi), yang secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan waktu tunggu pengujian yang dikecualikan. Lihat --test_size_filters untuk contoh sintaksis.

Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.

--test_tag_filters=tag[,tag]*

Jika ditentukan, Bazel hanya akan menguji (atau membangun jika --build_tests_only juga ditentukan) target pengujian yang memiliki setidaknya satu tag yang diperlukan (jika ada yang ditentukan) dan tidak memiliki tag yang dikecualikan. Filter tag pengujian ditentukan sebagai daftar kata kunci tag yang dipisahkan koma, yang secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag wajib juga dapat memiliki tanda '+' di depannya.

Misalnya,

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

akan menguji target yang diberi tag performance atau stress, tetapi tidak diberi tag flaky.

Secara default, pemfilteran tag pengujian tidak diterapkan. Perhatikan bahwa Anda juga dapat memfilter tag size dan local pengujian dengan cara ini.

--test_lang_filters=string[,string]*

Menentukan daftar string yang dipisahkan koma yang merujuk ke nama class aturan pengujian. Untuk merujuk ke class aturan foo_test, gunakan string "foo". Bazel akan menguji (atau membangun jika --build_tests_only juga ditentukan) hanya target class aturan yang dirujuk. Untuk mengecualikan target tersebut, gunakan string "-foo". Misalnya,

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

hanya akan menguji target yang merupakan instance foo_test atau bar_test di //baz/..., sementara

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

akan menguji semua target di //baz/... kecuali instance foo_test dan bar_test.

--test_filter=filter-expression

Menentukan filter yang dapat digunakan runner pengujian untuk memilih subset pengujian yang akan dijalankan. Semua target yang ditentukan dalam pemanggilan dibuat, tetapi bergantung pada ekspresinya, hanya beberapa target yang dapat dieksekusi; dalam beberapa kasus, hanya metode pengujian tertentu yang dijalankan.

Penafsiran khusus filter-expression bergantung pada framework pengujian yang bertanggung jawab untuk menjalankan pengujian. Dapat berupa glob, substring, atau regexp. --test_filter adalah cara mudah untuk meneruskan argumen filter --test_arg yang berbeda, tetapi tidak semua framework mendukungnya.

Panjang

Opsi ini mengontrol kejelasan output Bazel, baik ke terminal, atau ke file log tambahan.

--explain=logfile

Opsi ini, yang memerlukan argumen nama file, menyebabkan pemeriksa dependensi di fase eksekusi bazel build menjelaskan, untuk setiap langkah build, alasan langkah tersebut dieksekusi, atau bahwa langkah tersebut sudah terbaru. Penjelasan ditulis ke file log.

Jika Anda mengalami pembangunan ulang yang tidak terduga, opsi ini dapat membantu memahami alasannya. Tambahkan ke .bazelrc Anda agar logging terjadi untuk semua build berikutnya, lalu periksa log saat Anda melihat langkah eksekusi yang dijalankan secara tidak terduga. Opsi ini dapat menyebabkan sedikit penurunan performa, jadi sebaiknya hapus opsi ini jika tidak lagi diperlukan.

--verbose_explanations

Opsi ini meningkatkan kejelasan penjelasan yang dihasilkan saat opsi --explain diaktifkan.

Khususnya, jika penjelasan verbose diaktifkan, dan file output dibangun ulang karena perintah yang digunakan untuk membangunnya telah berubah, maka output dalam file penjelasan akan mencakup detail lengkap perintah baru (setidaknya untuk sebagian besar perintah).

Menggunakan opsi ini dapat meningkatkan panjang file penjelasan yang dihasilkan dan penalti performa penggunaan --explain secara signifikan.

Jika --explain tidak diaktifkan, maka --verbose_explanations tidak akan berpengaruh.

--profile=file

Opsi ini, yang menggunakan argumen nama file, menyebabkan Bazel menulis data pembuatan profil ke dalam file. Data tersebut kemudian dapat dianalisis atau diuraikan menggunakan perintah bazel analyze-profile. Profil Build dapat berguna untuk memahami di mana perintah build Bazel menghabiskan waktunya.

--[no]show_loading_progress

Opsi ini menyebabkan Bazel menampilkan pesan progres pemuatan paket. Jika dinonaktifkan, pesan tidak akan ditampilkan.

--[no]show_progress

Opsi ini menyebabkan pesan progres ditampilkan; opsi ini aktif secara default. Jika dinonaktifkan, pesan progres akan disembunyikan.

--show_progress_rate_limit=n

Opsi ini menyebabkan bazel menampilkan paling banyak satu pesan progres per n detik, dengan n adalah bilangan real. Nilai default untuk opsi ini adalah 0,02, yang berarti bazel akan membatasi pesan progres menjadi satu per setiap 0,02 detik.

--show_result=n

Opsi ini mengontrol pencetakan informasi hasil di akhir perintah bazel build. Secara default, jika satu target build ditentukan, Bazel akan mencetak pesan yang menyatakan apakah target berhasil diupdate atau tidak, dan jika berhasil, daftar file output yang dibuat target. Jika beberapa target ditentukan, informasi hasil tidak akan ditampilkan.

Meskipun informasi hasil mungkin berguna untuk build satu target atau beberapa target, untuk build besar (seperti seluruh hierarki project tingkat teratas), informasi ini dapat membebani dan mengganggu; opsi ini memungkinkan informasi tersebut dikontrol. --show_result mengambil argumen bilangan bulat, yang merupakan jumlah maksimum target yang informasi hasil lengkapnya harus dicetak. Secara default, nilainya adalah 1. Di atas nilai minimum ini, tidak ada informasi hasil yang ditampilkan untuk masing-masing target. Dengan demikian, nol menyebabkan informasi hasil selalu disembunyikan, dan nilai yang sangat besar menyebabkan hasil selalu dicetak.

Pengguna mungkin ingin memilih nilai di antaranya jika mereka secara rutin berganti-ganti antara membuat grup kecil target (misalnya, selama siklus kompilasi-edit-pengujian) dan grup besar target (misalnya, saat membuat ruang kerja baru atau menjalankan pengujian regresi). Dalam kasus pertama, informasi hasil sangat berguna, sedangkan dalam kasus kedua, informasi tersebut kurang berguna. Seperti semua opsi, opsi ini dapat ditentukan secara implisit melalui file .bazelrc.

File dicetak sehingga memudahkan untuk menyalin dan menempelkan nama file ke shell, untuk menjalankan file yang dapat dieksekusi bawaan. Pesan "terbaru" atau "gagal" untuk setiap target dapat dengan mudah diuraikan oleh skrip yang mendorong build.

--sandbox_debug

Opsi ini menyebabkan Bazel mencetak informasi proses debug tambahan saat menggunakan sandbox untuk eksekusi tindakan. Opsi ini juga mempertahankan direktori sandbox, sehingga file yang terlihat oleh tindakan selama eksekusi dapat diperiksa.

--subcommands (-s)

Opsi ini menyebabkan fase eksekusi Bazel mencetak command line lengkap untuk setiap perintah sebelum mengeksekusinya.

  >>>>> # //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)

Jika memungkinkan, perintah dicetak dalam sintaksis yang kompatibel dengan Bourne shell, sehingga dapat dengan mudah disalin dan ditempel ke command prompt shell. (Tanda kurung di sekitarnya disediakan untuk melindungi shell Anda dari panggilan cd dan exec; pastikan untuk menyalinnya!) Namun, beberapa perintah diterapkan secara internal dalam Bazel, seperti membuat pohon symlink. Untuk ini, tidak ada command line yang dapat ditampilkan.

--subcommands=pretty_print dapat diteruskan untuk mencetak argumen perintah sebagai daftar, bukan sebagai satu baris. Hal ini dapat membantu membuat baris perintah yang panjang lebih mudah dibaca.

Lihat juga --verbose_failures di bawah.

Untuk mencatat subperintah ke file dalam format yang mudah digunakan alat, lihat --execution_log_json_file dan --execution_log_binary_file.

--verbose_failures

Opsi ini menyebabkan fase eksekusi Bazel mencetak command line lengkap untuk perintah yang gagal. Hal ini dapat sangat berguna untuk men-debug build yang gagal.

Perintah yang gagal dicetak dalam sintaksis yang kompatibel dengan Bourne shell, yang cocok untuk disalin dan ditempel ke perintah shell.

Status Workspace

Gunakan opsi ini untuk "membubuhi stempel" biner yang dibuat Bazel: untuk menyematkan informasi tambahan ke dalam biner, seperti revisi kontrol sumber atau informasi terkait ruang kerja lainnya. Anda dapat menggunakan mekanisme ini dengan aturan yang mendukung atribut stamp, seperti genrule, cc_binary, dan lainnya.

--workspace_status_command=program

Dengan tanda ini, Anda dapat menentukan biner yang dijalankan Bazel sebelum setiap build. Program ini dapat melaporkan informasi tentang status ruang kerja, seperti revisi kontrol sumber saat ini.

Nilai tanda harus berupa jalur ke program native. Di Linux/macOS, ini dapat berupa file yang dapat dieksekusi. Di Windows, ini harus berupa biner native, biasanya file ".exe", ".bat", atau ".cmd".

Program harus mencetak nol atau lebih pasangan kunci/nilai ke output standar, satu entri di setiap baris, lalu keluar dengan nol (jika tidak, build akan gagal). Nama kunci dapat berupa apa saja, tetapi hanya boleh menggunakan huruf kapital dan garis bawah. Spasi pertama setelah nama kunci memisahkannya dari nilai. Nilainya adalah bagian baris lainnya (termasuk spasi tambahan). Baik kunci maupun nilai tidak boleh mencakup beberapa baris. Kunci tidak boleh diduplikasi.

Bazel memartisi kunci ke dalam dua bucket: "stabil" dan "tidak stabil". (Nama "stabil" dan "volatile" agak berlawanan dengan intuisi, jadi jangan terlalu memikirkannya.)

Kemudian, Bazel menulis pasangan nilai kunci ke dalam dua file:

• bazel-out/stable-status.txt berisi semua kunci dan nilai yang nama kuncinya diawali dengan STABLE_
• bazel-out/volatile-status.txt berisi kunci lainnya dan nilainya

Kontraknya adalah:

• Nilai kunci "stabil" harus jarang berubah, jika memungkinkan. Jika konten bazel-out/stable-status.txt berubah, Bazel akan membatalkan validasi tindakan yang bergantung padanya. Dengan kata lain, jika nilai kunci stabil berubah, Bazel akan menjalankan ulang tindakan yang diberi stempel. Oleh karena itu, status stabil tidak boleh berisi hal-hal seperti stempel waktu, karena stempel waktu berubah setiap saat dan akan membuat Bazel menjalankan ulang tindakan yang diberi stempel dengan setiap build.

  Bazel selalu menghasilkan kunci stabil berikut:

  • BUILD_EMBED_LABEL: nilai --embed_label
  • BUILD_HOST: nama mesin host tempat Bazel berjalan
  • BUILD_USER: nama pengguna yang menjalankan Bazel

• Nilai kunci "volatile" dapat sering berubah. Bazel mengharapkan perubahan ini terjadi setiap saat, seperti stempel waktu, dan memperbarui file bazel-out/volatile-status.txt sebagaimana mestinya. Namun, untuk menghindari menjalankan kembali tindakan yang diberi stempel sepanjang waktu, Bazel berpura-pura bahwa file yang tidak stabil tidak pernah berubah. Dengan kata lain, jika file status sementara adalah satu-satunya file yang isinya telah berubah, Bazel tidak akan membatalkan validasi tindakan yang bergantung padanya. Jika input lain dari tindakan telah berubah, Bazel akan menjalankan kembali tindakan tersebut, dan tindakan akan melihat status tidak stabil yang diperbarui, tetapi hanya perubahan status tidak stabil saja tidak akan membatalkan tindakan.

  Bazel selalu menghasilkan kunci sementara berikut:

  • BUILD_TIMESTAMP: waktu build dalam detik sejak Epoch Unix (nilai System.currentTimeMillis() dibagi seribu)
  • FORMATTED_DATE: waktu build yang diformat sebagai yyyy MMM d HH mm ss EEE(misalnya, 2023 Jun 2 01 44 29 Fri) dalam UTC.

Di Linux/macOS, Anda dapat meneruskan --workspace_status_command=/bin/true untuk menonaktifkan pengambilan status ruang kerja, karena true tidak melakukan apa pun, berhasil (keluar dengan nol) dan tidak mencetak output. Di Windows, Anda dapat meneruskan jalur true.exe MSYS untuk mendapatkan efek yang sama.

Jika perintah status ruang kerja gagal (keluar dengan nilai non-nol) karena alasan apa pun, build akan gagal.

Contoh program di Linux menggunakan 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"

Teruskan jalur program ini dengan --workspace_status_command, dan file status stabil akan menyertakan baris STABIL, sedangkan file status tidak stabil akan menyertakan baris lainnya.

--[no]stamp

Opsi ini, bersama dengan atribut aturan stamp, mengontrol apakah akan menyematkan informasi build dalam biner.

Pemberian stempel dapat diaktifkan atau dinonaktifkan secara eksplisit berdasarkan per aturan menggunakan atribut stamp. Lihat Ensiklopedia Build untuk mengetahui detailnya. Jika aturan menetapkan stamp = -1 (default untuk aturan *_binary), opsi ini akan menentukan apakah pemberian stempel diaktifkan.

Bazel tidak pernah memberi stempel pada biner yang dibuat untuk konfigurasi exec, terlepas dari opsi ini atau atribut stamp. Untuk aturan yang menetapkan stamp = 0 (default untuk aturan *_test), pemberian stempel dinonaktifkan terlepas dari --[no]stamp. Menentukan --stamp tidak memaksa target dibangun kembali jika dependensinya tidak berubah.

Menetapkan --nostamp umumnya diinginkan untuk performa build, karena mengurangi volatilitas input dan memaksimalkan caching build.

Platform

Gunakan opsi ini untuk mengontrol platform host dan target yang mengonfigurasi cara kerja build, dan untuk mengontrol platform eksekusi dan toolchain yang tersedia untuk aturan Bazel.

Lihat informasi latar belakang tentang Platform dan Toolchain.

--platforms=labels

Label aturan platform yang menjelaskan platform target untuk perintah saat ini.

--host_platform=label

Label aturan platform yang menjelaskan sistem host.

--extra_execution_platforms=labels

Platform yang tersedia sebagai platform eksekusi untuk menjalankan tindakan. Platform dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Platform ini akan dipertimbangkan sebelum platform yang dideklarasikan dalam file MODULE.bazel oleh register_execution_platforms(). Opsi ini menerima daftar platform yang dipisahkan koma dalam urutan prioritas. Jika tanda diteruskan beberapa kali, tanda yang terbaru akan menggantikan tanda sebelumnya.

--extra_toolchains=labels

Aturan toolchain yang akan dipertimbangkan selama penyelesaian toolchain. Rangkaian alat dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Rangkaian alat ini akan dipertimbangkan sebelum yang dideklarasikan dalam file MODULE.bazel oleh register_toolchains().

--toolchain_resolution_debug=regex

Mencetak informasi debug saat menemukan toolchain jika jenis toolchain cocok dengan regex. Beberapa ekspresi reguler dapat dipisahkan dengan koma. Ekspresi reguler dapat dinegasikan dengan menggunakan - di awal. Hal ini dapat membantu developer aturan Bazel atau Starlark dalam melakukan debug kegagalan karena toolchain yang tidak ada.

Lain-lain

--flag_alias=alias_name=target_path

Flag praktis yang digunakan untuk mengikat setelan build Starlark yang lebih panjang ke nama yang lebih pendek. Untuk detail selengkapnya, lihat Konfigurasi Starlark.

--symlink_prefix=string

Mengubah awalan link simbolis praktis yang dihasilkan. Nilai default untuk awalan symlink adalah bazel- yang akan membuat symlink bazel-bin, bazel-testlogs, dan bazel-genfiles.

Jika link simbolis tidak dapat dibuat karena alasan apa pun, peringatan akan dikeluarkan, tetapi build tetap dianggap berhasil. Khususnya, hal ini memungkinkan Anda membangun di direktori hanya baca atau direktori yang tidak memiliki izin tulis. Setiap jalur yang dicetak dalam pesan informasi di akhir build hanya akan menggunakan bentuk singkat relatif symlink jika symlink mengarah ke lokasi yang diharapkan; dengan kata lain, Anda dapat mengandalkan kebenaran jalur tersebut, meskipun Anda tidak dapat mengandalkan pembuatan symlink.

Beberapa nilai umum opsi ini:

• Menekan pembuatan symlink: --symlink_prefix=/ akan menyebabkan Bazel tidak membuat atau memperbarui symlink apa pun, termasuk symlink bazel-out dan bazel-<workspace>. Gunakan opsi ini untuk menonaktifkan pembuatan symlink sepenuhnya.

• Mengurangi kekacauan: --symlink_prefix=.bazel/ akan menyebabkan Bazel membuat link simbolis bernama bin (dll.) di dalam direktori tersembunyi .bazel.

--platform_suffix=string

Menambahkan akhiran ke nama pendek konfigurasi, yang digunakan untuk menentukan direktori output. Menetapkan opsi ini ke nilai yang berbeda akan menempatkan file ke direktori yang berbeda, misalnya untuk meningkatkan rasio hit cache untuk build yang sebaliknya akan menimpa file output satu sama lain, atau untuk menyimpan file output untuk perbandingan.

--default_visibility=(private|public)

Flag sementara untuk menguji perubahan visibilitas default bazel. Tidak ditujukan untuk penggunaan umum, tetapi didokumentasikan demi kelengkapan.

--starlark_cpu_profile=_file_

Tanda ini, yang nilainya adalah nama file, menyebabkan Bazel mengumpulkan statistik tentang penggunaan CPU oleh semua thread Starlark, dan menulis profil, dalam format pprof, ke file bernama.

Gunakan opsi ini untuk membantu mengidentifikasi fungsi Starlark yang membuat pemuatan dan analisis menjadi lambat karena komputasi yang berlebihan. Contoh:

$ 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

Untuk tampilan data yang sama yang berbeda, coba perintah pprof svg, web, dan list.

Menggunakan Bazel untuk rilis

Bazel digunakan oleh engineer software selama siklus pengembangan, dan oleh engineer rilis saat menyiapkan biner untuk deployment ke produksi. Bagian ini memberikan daftar tips untuk engineer rilis yang menggunakan Bazel.

Opsi signifikan

Saat menggunakan Bazel untuk build rilis, masalah yang sama muncul seperti pada skrip lain yang melakukan build. Untuk mengetahui detail selengkapnya, lihat Memanggil Bazel dari skrip. Secara khusus, opsi berikut sangat direkomendasikan:

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

Opsi ini juga penting:

• --package_path
• --symlink_prefix: untuk mengelola build untuk beberapa konfigurasi, akan lebih mudah untuk membedakan setiap build dengan ID yang berbeda, seperti "64bit" vs. "32bit". Opsi ini membedakan link simbolik bazel-bin (dll.).

Menjalankan pengujian

Untuk mem-build dan menjalankan pengujian dengan bazel, ketik bazel test, diikuti dengan nama target pengujian.

Secara default, perintah ini melakukan aktivitas build dan pengujian secara bersamaan, membangun semua target yang ditentukan (termasuk target non-pengujian yang ditentukan di command line) dan menguji target *_test dan test_suite segera setelah prasyaratnya dibangun, yang berarti eksekusi pengujian diselingi dengan build. Tindakan ini biasanya menghasilkan peningkatan kecepatan yang signifikan.

Opsi untuk bazel test

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

Jika opsi ini disetel ke 'auto' (default), Bazel hanya akan menjalankan ulang pengujian jika salah satu dari kondisi berikut berlaku:

• Bazel mendeteksi perubahan dalam pengujian atau dependensinya
• pengujian ditandai sebagai external
• beberapa pengujian dijalankan dengan --runs_per_test
• pengujian gagal.

Jika 'tidak', semua pengujian akan dijalankan tanpa syarat.

Jika 'ya', perilaku caching akan sama dengan otomatis kecuali bahwa perilaku ini dapat menyimpan kegagalan pengujian dan menjalankan pengujian dengan --runs_per_test.

Pengguna yang telah mengaktifkan opsi ini secara default di file .bazelrc mereka dapat menemukan singkatan -t (aktif) atau -t- (nonaktif) berguna untuk mengganti default pada proses tertentu.

--check_tests_up_to_date

Opsi ini memberi tahu Bazel untuk tidak menjalankan pengujian, tetapi hanya memeriksa dan melaporkan hasil pengujian yang di-cache. Jika ada pengujian yang belum pernah dibangun dan dijalankan sebelumnya, atau yang hasil pengujiannya sudah tidak berlaku (misalnya, karena kode sumber atau opsi build telah berubah), Bazel akan melaporkan pesan error ("hasil pengujian tidak terbaru"), akan mencatat status pengujian sebagai "TIDAK ADA STATUS" (berwarna merah, jika output warna diaktifkan), dan akan menampilkan kode keluar non-nol.

Opsi ini juga menyiratkan perilaku --check_up_to_date.

Opsi ini mungkin berguna untuk pemeriksaan sebelum pengiriman.

--test_verbose_timeout_warnings

Opsi ini memberi tahu Bazel untuk memperingatkan pengguna secara eksplisit jika waktu tunggu pengujian jauh lebih lama daripada waktu eksekusi pengujian yang sebenarnya. Meskipun batas waktu pengujian harus ditetapkan agar tidak tidak stabil, pengujian yang memiliki batas waktu yang terlalu besar dapat menyembunyikan masalah nyata yang muncul secara tidak terduga.

Misalnya, pengujian yang biasanya dieksekusi dalam satu atau dua menit tidak boleh memiliki waktu tunggu ETERNAL atau LONG karena ini terlalu lama.

Opsi ini berguna untuk membantu pengguna memutuskan nilai waktu tunggu yang baik atau memeriksa nilai waktu tunggu yang ada.

--[no]test_keep_going

Secara default, semua pengujian dijalankan hingga selesai. Namun, jika tanda ini dinonaktifkan, build akan dibatalkan pada setiap pengujian yang tidak lulus. Langkah-langkah build berikutnya dan pemanggilan pengujian tidak dijalankan, dan pemanggilan yang sedang berlangsung dibatalkan. Jangan tentukan --notest_keep_going dan --keep_going sekaligus.

--flaky_test_attempts=attempts

Opsi ini menentukan jumlah maksimum percobaan pengujian jika gagal karena alasan apa pun. Pengujian yang awalnya gagal, tetapi akhirnya berhasil, dilaporkan sebagai FLAKY pada ringkasan pengujian. Namun, dianggap lulus jika menyangkut identifikasi kode keluar Bazel atau jumlah total pengujian yang lulus. Pengujian yang gagal dalam semua percobaan yang diizinkan dianggap gagal.

Secara default (jika opsi ini tidak ditentukan, atau jika disetel ke default), hanya satu upaya yang diizinkan untuk pengujian reguler, dan 3 untuk aturan pengujian dengan setelan atribut flaky. Anda dapat menentukan nilai bilangan bulat untuk mengganti batas maksimum upaya pengujian. Bazel mengizinkan maksimal 10 percobaan pengujian untuk mencegah penyalahgunaan sistem.

--runs_per_test=[regex@]number

Opsi ini menentukan berapa kali setiap pengujian harus dijalankan. Semua eksekusi pengujian diperlakukan sebagai pengujian terpisah (fungsi penggantian akan diterapkan ke masing-masing pengujian secara terpisah).

Status target dengan proses yang gagal bergantung pada nilai tanda --runs_per_test_detects_flakes:

• Jika tidak ada, setiap proses yang gagal akan menyebabkan seluruh pengujian gagal.
• Jika ada dan dua proses dari shard yang sama menampilkan LULUS dan GAGAL, pengujian akan menerima status tidak stabil (kecuali jika proses yang gagal lainnya menyebabkan pengujian gagal).

Jika satu angka ditentukan, semua pengujian akan dijalankan sebanyak jumlah tersebut. Atau, ekspresi reguler dapat ditentukan menggunakan sintaksis regex@number. Hal ini membatasi efek --runs_per_test ke target yang cocok dengan regex (--runs_per_test=^//pizza:.*@4 menjalankan semua pengujian di bawah //pizza/ sebanyak 4 kali). Bentuk --runs_per_test ini dapat ditentukan lebih dari sekali.

--[no]runs_per_test_detects_flakes

Jika opsi ini ditentukan (secara default tidak), Bazel akan mendeteksi shard pengujian yang tidak stabil melalui --runs_per_test. Jika satu atau beberapa proses untuk satu shard gagal dan satu atau beberapa proses untuk shard yang sama berhasil, target akan dianggap tidak stabil dengan tanda. Jika tidak ditentukan, target akan melaporkan status gagal.

--test_summary=output_style

Menentukan cara ringkasan hasil pengujian harus ditampilkan.

• short mencetak hasil setiap pengujian beserta nama file yang berisi output pengujian jika pengujian gagal. Ini adalah nilai default.
• terse seperti short, tetapi lebih singkat: hanya mencetak informasi tentang pengujian yang tidak lulus.
• detailed mencetak setiap kasus pengujian yang gagal, bukan hanya setiap pengujian. Nama file output pengujian tidak disertakan.
• none tidak mencetak ringkasan pengujian.

--test_output=output_style

Menentukan cara output pengujian harus ditampilkan:

• summary menampilkan ringkasan apakah setiap pengujian lulus atau gagal. Juga menampilkan nama file log output untuk pengujian yang gagal. Ringkasan akan dicetak di akhir build (selama build, Anda hanya akan melihat pesan progres sederhana saat pengujian dimulai, lulus, atau gagal). Ini merupakan perilaku default.
• errors mengirimkan output stdout/stderr gabungan dari pengujian yang gagal hanya ke stdout segera setelah pengujian selesai, sehingga output pengujian dari pengujian serentak tidak saling berselang-seling. Mencetak ringkasan pada build sesuai output ringkasan di atas.
• all mirip dengan errors, tetapi mencetak output untuk semua pengujian, termasuk yang lulus.
• streamed mengalirkan output stdout/stderr dari setiap pengujian secara real-time.

--java_debug

Opsi ini menyebabkan mesin virtual Java dari pengujian Java menunggu koneksi dari debugger yang kompatibel dengan JDWP sebelum memulai pengujian. Opsi ini menyiratkan --test_output=streamed.

--[no]verbose_test_summary

Secara default, opsi ini diaktifkan, sehingga waktu pengujian dan informasi tambahan lainnya (seperti upaya pengujian) dicetak ke ringkasan pengujian. Jika --noverbose_test_summary ditentukan, ringkasan pengujian hanya akan mencakup nama pengujian, status pengujian, dan indikator pengujian yang di-cache, serta akan diformat agar tetap berada dalam 80 karakter jika memungkinkan.

--test_tmpdir=path

Menentukan direktori sementara untuk pengujian yang dijalankan secara lokal. Setiap pengujian akan dieksekusi di subdirektori terpisah dalam direktori ini. Direktori akan dibersihkan di awal setiap perintah bazel test. Secara default, bazel akan menempatkan direktori ini di bawah direktori dasar output Bazel.

--test_timeout=seconds ATAU --test_timeout=seconds,seconds,seconds,seconds

Mengganti nilai waktu tunggu untuk semua pengujian dengan menggunakan jumlah detik yang ditentukan sebagai nilai waktu tunggu baru. Jika hanya satu nilai yang diberikan, nilai tersebut akan digunakan untuk semua kategori waktu tunggu pengujian.

Atau, empat nilai yang dipisahkan koma dapat diberikan, yang menentukan waktu tunggu individual untuk pengujian pendek, sedang, panjang, dan abadi (dalam urutan tersebut). Dalam bentuk apa pun, nilai nol atau negatif untuk ukuran pengujian apa pun akan digantikan oleh waktu tunggu default untuk kategori waktu tunggu tertentu seperti yang ditentukan oleh halaman Menulis Pengujian. Secara default, Bazel akan menggunakan waktu tunggu ini untuk semua pengujian dengan menyimpulkan batas waktu tunggu dari ukuran pengujian, baik ukuran tersebut ditetapkan secara implisit maupun eksplisit.

Pengujian yang secara eksplisit menyatakan kategori waktu tunggu sebagai berbeda dari ukurannya akan menerima nilai yang sama seolah-olah waktu tunggu tersebut telah ditetapkan secara implisit oleh tag ukuran. Jadi, pengujian berukuran 'kecil' yang menyatakan waktu tunggu 'panjang' akan memiliki waktu tunggu efektif yang sama dengan pengujian 'besar' tanpa waktu tunggu eksplisit.

--test_arg=arg

Meneruskan opsi/flag/argumen command line ke setiap proses pengujian. Opsi ini dapat digunakan beberapa kali untuk meneruskan beberapa argumen. Misalnya, --test_arg=--logtostderr --test_arg=--v=3.

Perhatikan bahwa, tidak seperti perintah bazel run, Anda tidak dapat meneruskan argumen pengujian secara langsung seperti pada bazel test -- target --logtostderr --v=3. Hal ini karena argumen asing yang diteruskan ke bazel test ditafsirkan sebagai target pengujian tambahan. Artinya, --logtostderr dan --v=3 masing-masing akan ditafsirkan sebagai target pengujian. Ambiguitas ini tidak ada untuk perintah bazel run, yang hanya menerima satu target.

--test_arg dapat diteruskan ke perintah bazel run, tetapi akan diabaikan kecuali jika target yang dijalankan adalah target pengujian. (Seperti halnya flag lainnya, jika diteruskan dalam perintah bazel run setelah token --, perintah tersebut tidak diproses oleh Bazel, tetapi diteruskan secara verbatim ke target yang dieksekusi.)

--test_env=variable=_value_ ATAU --test_env=variable

Menentukan variabel tambahan yang harus dimasukkan ke lingkungan pengujian untuk setiap pengujian. Jika value tidak ditentukan, value akan diwarisi dari lingkungan shell yang digunakan untuk memulai perintah bazel test.

Lingkungan dapat diakses dari dalam pengujian menggunakan System.getenv("var") (Java), getenv("var") (C atau C++),

--run_under=command-prefix

Tindakan ini menentukan awalan yang akan disisipkan runner pengujian di depan perintah pengujian sebelum menjalankannya. command-prefix dibagi menjadi kata-kata menggunakan aturan tokenisasi shell Bourne, lalu daftar kata ditambahkan ke perintah yang akan dieksekusi.

Jika kata pertama adalah label yang sepenuhnya memenuhi syarat (dimulai dengan //), kata tersebut akan dibuat. Kemudian, label diganti dengan lokasi file yang dapat dieksekusi yang sesuai yang ditambahkan ke perintah yang akan dieksekusi bersama dengan kata-kata lainnya.

Beberapa peringatan berlaku:

• PATH yang digunakan untuk menjalankan pengujian mungkin berbeda dengan PATH di lingkungan Anda, sehingga Anda mungkin perlu menggunakan jalur absolut untuk perintah --run_under (kata pertama dalam command-prefix).
• stdin tidak terhubung, sehingga --run_under tidak dapat digunakan untuk perintah interaktif.

Contoh:

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

Pemilihan pengujian

Seperti yang didokumentasikan di bagian Opsi pemilihan output, Anda dapat memfilter pengujian berdasarkan ukuran, waktu tunggu, tag, atau bahasa. Filter nama umum yang praktis dapat meneruskan argumen filter tertentu ke runner pengujian.

Opsi lain untuk bazel test

Sintaksis dan opsi lainnya persis seperti bazel build.

Menjalankan file yang dapat dieksekusi

Perintah bazel run mirip dengan bazel build, kecuali digunakan untuk mem-build dan menjalankan satu target. Berikut adalah sesi umum (//java/myapp:myapp menyapa dan mencetak argumennya):

  % 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 serupa, tetapi tidak identik, dengan pemanggilan langsung biner yang dibuat oleh Bazel dan perilakunya berbeda bergantung pada apakah biner yang akan dipanggil adalah pengujian atau bukan.

Jika biner bukan pengujian, direktori kerja saat ini akan menjadi pohon runfile biner.

Jika biner adalah pengujian, direktori kerja saat ini akan menjadi root eksekusi dan upaya dengan niat baik dilakukan untuk mereplikasi lingkungan tempat pengujian biasanya dijalankan. Namun, emulasi tidak sempurna, dan pengujian yang memiliki beberapa shard tidak dapat dijalankan dengan cara ini (opsi command line --test_sharding_strategy=disabled dapat digunakan untuk mengatasi masalah ini)

Variabel lingkungan tambahan berikut juga tersedia untuk biner:

• BUILD_WORKSPACE_DIRECTORY: root ruang kerja tempat build dijalankan.
• BUILD_WORKING_DIRECTORY: direktori kerja saat ini tempat Bazel dijalankan.
• BUILD_ID: ID build pemanggilan bazel run. Ini biasanya unik, kecuali jika Bazel dijalankan dengan --script_path dan skrip yang dihasilkan digunakan kembali.
• BUILD_EXECROOT: root eksekusi pemanggilan bazel run.

Misalnya, ini dapat digunakan untuk menafsirkan nama file di command line dengan cara yang mudah digunakan.

Opsi untuk bazel run

--run_under=command-prefix

Opsi ini memiliki efek yang sama dengan opsi --run_under untuk bazel test (lihat di atas), kecuali bahwa opsi ini berlaku untuk perintah yang dijalankan oleh bazel run, bukan untuk pengujian yang dijalankan oleh bazel test dan tidak dapat dijalankan dengan label.

Memfilter output logging dari Bazel

Saat memanggil biner dengan bazel run, Bazel mencetak output logging dari Bazel itu sendiri dan biner yang sedang dipanggil. Untuk membuat log tidak terlalu berisik, Anda dapat menekan output dari Bazel itu sendiri dengan tanda --ui_event_filters dan --noshow_progress.

Contoh: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

Menjalankan pengujian

bazel run juga dapat menjalankan biner pengujian, yang akan menjalankan pengujian dalam perkiraan lingkungan yang dijelaskan di Menulis Pengujian. Perhatikan bahwa tidak ada argumen --test_* yang berpengaruh saat menjalankan pengujian dengan cara ini, kecuali --test_arg .

Membersihkan output build

Perintah clean

Bazel memiliki perintah clean, yang serupa dengan Make. Perintah ini menghapus direktori output untuk semua konfigurasi build yang dilakukan oleh instance Bazel ini, atau seluruh pohon kerja yang dibuat oleh instance Bazel ini, dan mereset cache internal. Jika dijalankan tanpa opsi command line, direktori output untuk semua konfigurasi akan dibersihkan.

Ingatlah bahwa setiap instance Bazel dikaitkan dengan satu ruang kerja, sehingga perintah clean akan menghapus semua output dari semua build yang telah Anda lakukan dengan instance Bazel tersebut di ruang kerja tersebut.

Untuk menghapus sepenuhnya seluruh pohon kerja yang dibuat oleh instance Bazel, Anda dapat menentukan opsi --expunge. Saat dijalankan dengan --expunge, perintah clean hanya menghapus seluruh hierarki dasar output yang, selain output build, berisi semua file sementara yang dibuat oleh Bazel. Tindakan ini juga menghentikan server Bazel setelah pembersihan, yang setara dengan perintah shutdown. Misalnya, untuk membersihkan semua rekaman aktivitas disk dan memori instance Bazel, Anda dapat menentukan:

  % bazel clean --expunge

Atau, Anda dapat menghapus di latar belakang menggunakan --expunge_async. Aman untuk memanggil perintah Bazel di klien yang sama saat penghapusan asinkron terus berjalan.

Perintah clean terutama disediakan sebagai cara untuk mengambil kembali ruang disk untuk ruang kerja yang tidak lagi diperlukan. Pembangunan ulang inkremental Bazel mungkin tidak sempurna, sehingga clean dapat digunakan untuk memulihkan status yang konsisten saat masalah muncul.

Desain Bazel sedemikian rupa sehingga masalah ini dapat diperbaiki dan bug ini menjadi prioritas tinggi untuk diperbaiki. Jika Anda pernah menemukan build inkremental yang salah, ajukan laporan bug, dan laporkan bug di alat daripada menggunakan clean.

Membuat kueri grafik dependensi

Bazel menyertakan bahasa kueri untuk mengajukan pertanyaan tentang grafik dependensi yang digunakan selama build. Bahasa kueri digunakan oleh dua perintah: query dan cquery. Perbedaan utama antara kedua perintah ini adalah kueri dijalankan setelah fase pemuatan dan cquery dijalankan setelah fase analisis. Alat ini sangat membantu banyak tugas rekayasa software.

Bahasa kueri ini didasarkan pada ide operasi aljabar atas grafik; bahasa ini didokumentasikan secara mendetail di

Referensi Kueri Bazel. Lihat dokumen tersebut untuk referensi, contoh, dan opsi command line khusus kueri.

Alat kueri menerima beberapa opsi command line. --output memilih format output. --[no]keep_going (dinonaktifkan secara default) menyebabkan alat kueri terus membuat progres saat terjadi error; perilaku ini dapat dinonaktifkan jika hasil yang tidak lengkap tidak dapat diterima jika terjadi error.

Opsi --[no]tool_deps, yang diaktifkan secara default, menyebabkan dependensi dalam konfigurasi non-target disertakan dalam grafik dependensi tempat kueri beroperasi.

Opsi --[no]implicit_deps, yang diaktifkan secara default, menyebabkan dependensi implisit disertakan dalam grafik dependensi tempat kueri beroperasi. Dependensi implisit adalah dependensi yang tidak ditentukan secara eksplisit dalam file BUILD tetapi ditambahkan oleh bazel.

Contoh: "Tampilkan lokasi definisi (dalam file BUILD) semua genrule yang diperlukan untuk membangun semua pengujian dalam hierarki PEBL."

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

Membuat kueri grafik tindakan

Perintah aquery memungkinkan Anda membuat kueri untuk tindakan dalam grafik build. API ini beroperasi pada grafik target yang dikonfigurasi pasca-analisis dan mengekspos informasi tentang tindakan, artefak, dan hubungannya.

Alat ini menerima beberapa opsi command line. --output memilih format output. Format output default (text) dapat dibaca manusia, gunakan proto atau textproto untuk format yang dapat dibaca mesin. Khususnya, perintah aquery berjalan di atas build Bazel biasa dan mewarisi serangkaian opsi yang tersedia selama build.

Composable ini mendukung kumpulan fungsi yang sama yang juga tersedia untuk query tradisional, tetapi siblings, buildfiles, dan tests.

Untuk mengetahui detail selengkapnya, lihat Kueri Grafik Tindakan.

Berbagai perintah dan opsi

help

Perintah help memberikan bantuan online. Secara default, perintah ini menampilkan ringkasan perintah dan topik bantuan yang tersedia, seperti yang ditunjukkan di Membangun dengan Bazel. Menentukan argumen akan menampilkan bantuan mendetail untuk topik tertentu. Sebagian besar topik adalah perintah Bazel, seperti build atau query, tetapi ada beberapa topik bantuan tambahan yang tidak sesuai dengan perintah.

--[no]long (-l)

Secara default, bazel help [topic] hanya mencetak ringkasan opsi yang relevan untuk suatu topik. Jika opsi --long ditentukan, jenis, nilai default, dan deskripsi lengkap setiap opsi juga akan dicetak.

shutdown

Proses server Bazel dapat dihentikan menggunakan perintah shutdown. Perintah ini menyebabkan server Bazel keluar segera setelah menjadi tidak aktif (misalnya, setelah penyelesaian build atau perintah lain yang sedang berlangsung). Untuk mengetahui detail selengkapnya, lihat Penerapan klien/server.

Server Bazel berhenti sendiri setelah waktu tunggu tidak ada aktivitas, sehingga perintah ini jarang diperlukan; namun, perintah ini dapat berguna dalam skrip jika diketahui bahwa tidak ada build lebih lanjut yang akan terjadi di ruang kerja tertentu.

shutdown menerima satu opsi, --iff_heap_size_greater_than _n_, yang memerlukan argumen bilangan bulat (dalam MB). Jika ditentukan, hal ini membuat penonaktifan bersyarat pada jumlah memori yang sudah digunakan. Hal ini berguna untuk skrip yang memulai banyak build, karena kebocoran memori di server Bazel dapat menyebabkan server tersebut mengalami error secara tidak terduga dari waktu ke waktu; melakukan restart bersyarat akan mencegah kondisi ini.

info

Perintah info mencetak berbagai nilai yang terkait dengan instance server Bazel, atau dengan konfigurasi build tertentu. (Ini dapat digunakan oleh skrip yang mendorong build.)

Perintah info juga mengizinkan satu argumen (opsional), yaitu nama salah satu kunci dalam daftar di bawah. Dalam hal ini, bazel info key hanya akan mencetak nilai untuk satu kunci tersebut. (Hal ini sangat praktis saat membuat skrip Bazel, karena tidak perlu menyalurkan hasil melalui sed -ne /key:/s/key://p:

Data independen konfigurasi

• release: label rilis untuk instance Bazel ini, atau "versi pengembangan" jika ini bukan biner yang dirilis.
• workspace jalur absolut ke direktori ruang kerja dasar.

• install_base: jalur absolut ke direktori penginstalan yang digunakan oleh instance Bazel ini untuk pengguna saat ini. Bazel menginstal file yang dapat dieksekusi yang diperlukan secara internal di bawah direktori ini.

• output_base: jalur absolut ke direktori output dasar yang digunakan oleh instance Bazel ini untuk kombinasi pengguna dan ruang kerja saat ini. Bazel menempatkan semua output build dan scratch di bawah direktori ini.

• execution_root: jalur absolut ke direktori root eksekusi di bagian output_base. Direktori ini adalah root untuk semua file yang dapat diakses oleh perintah yang dieksekusi selama build, dan merupakan direktori kerja untuk perintah tersebut. Jika direktori ruang kerja dapat ditulis, link simbolis bernama bazel-<workspace> akan ditempatkan di sana dan mengarah ke direktori ini.

• output_path: jalur absolut ke direktori output di bawah root eksekusi yang digunakan untuk semua file yang benar-benar dibuat sebagai hasil dari perintah build. Jika direktori ruang kerja dapat ditulis, symlink bernama bazel-out akan ditempatkan di sana dan mengarah ke direktori ini.

• server_pid: ID proses dari proses server Bazel.

• server_log: jalur absolut ke file log debug server Bazel. File ini berisi informasi proses debug untuk semua perintah selama masa aktif server Bazel, dan ditujukan untuk penggunaan oleh developer Bazel dan pengguna tingkat lanjut.

• command_log: jalur absolut ke file log perintah; file ini berisi aliran stdout dan stderr yang saling terkait dari perintah Bazel terbaru. Perhatikan bahwa menjalankan bazel info akan menggantikan isi file ini, karena file tersebut kemudian menjadi perintah Bazel terbaru. Namun, lokasi file log perintah tidak akan berubah kecuali jika Anda mengubah setelan opsi --output_base atau --output_user_root.

• used-heap-size, committed-heap-size, max-heap-size: melaporkan berbagai parameter ukuran heap JVM. Masing-masing: memori yang saat ini digunakan, memori yang saat ini dijamin tersedia untuk JVM dari sistem, alokasi maksimum yang mungkin.

• gc-count, gc-time: Jumlah kumulatif pengumpulan sampah sejak awal server Bazel ini dan waktu yang dihabiskan untuk melakukannya. Perhatikan bahwa nilai ini tidak direset di awal setiap build.

• package_path: Daftar jalur yang dipisahkan titik dua yang akan dicari paketnya oleh bazel. Memiliki format yang sama dengan argumen command line build --package_path.

Contoh: ID proses server Bazel.

% bazel info server_pid
1285

Data khusus konfigurasi

Data ini dapat dipengaruhi oleh opsi konfigurasi yang diteruskan ke bazel info, misalnya --cpu, --compilation_mode, dll. Perintah info menerima semua opsi yang mengontrol analisis dependensi, karena beberapa opsi ini menentukan lokasi direktori output build, pilihan compiler, dll.

• bazel-bin, bazel-testlogs, bazel-genfiles: melaporkan jalur absolut ke direktori bazel-* tempat program yang dihasilkan oleh build berada. Ini biasanya, meskipun tidak selalu, sama dengan link simbolis bazel-* yang dibuat di direktori ruang kerja dasar setelah build berhasil. Namun, jika direktori ruang kerja bersifat hanya baca, tidak ada link simbolis bazel-* yang dapat dibuat. Skrip yang menggunakan nilai yang dilaporkan oleh bazel info, bukan mengasumsikan keberadaan symlink, akan lebih andal.
• Lingkungan "Make" yang lengkap. Jika tanda --show_make_env ditentukan, semua variabel di lingkungan "Make" konfigurasi saat ini juga akan ditampilkan (seperti CC, GLIBC_VERSION, dll.). Variabel ini diakses menggunakan sintaksis $(CC) atau varref("CC") di dalam file BUILD.

Contoh: compiler C++ untuk konfigurasi saat ini. Ini adalah variabel $(CC) di lingkungan "Make", jadi tanda --show_make_env diperlukan.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Contoh: direktori output bazel-bin untuk konfigurasi saat ini. Ini dijamin benar bahkan dalam kasus saat symlink bazel-bin tidak dapat dibuat karena alasan tertentu (seperti jika Anda membangun dari direktori hanya baca).

% 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 dan --version

Perintah versi mencetak detail versi tentang biner Bazel yang dibuat, termasuk daftar perubahan saat biner tersebut dibuat dan tanggalnya. Informasi ini sangat berguna untuk menentukan apakah Anda memiliki Bazel terbaru, atau jika Anda melaporkan bug. Beberapa nilai menariknya adalah:

• changelist: changelist saat versi Bazel ini dirilis.
• label: label rilis untuk instance Bazel ini, atau "versi pengembangan" jika ini bukan biner yang dirilis. Sangat berguna saat melaporkan bug.

bazel --version, tanpa argumen lain, akan menghasilkan output yang sama dengan bazel version --gnu_format, kecuali tanpa efek samping yang berpotensi memulai server Bazel atau mengekstrak arsip server. bazel --version dapat dijalankan dari mana saja - tidak memerlukan direktori ruang kerja.

mobile-install

Perintah mobile-install menginstal aplikasi ke perangkat seluler. Saat ini hanya perangkat Android yang menjalankan ART yang didukung.

Lihat bazel mobile-install untuk mengetahui informasi selengkapnya.

Opsi berikut ini didukung:

--incremental

Jika disetel, Bazel akan mencoba menginstal aplikasi secara inkremental, yaitu hanya bagian yang telah berubah sejak build terakhir. Ini tidak dapat memperbarui resource yang dirujuk dari AndroidManifest.xml, kode native, atau resource Java (seperti yang dirujuk oleh Class.getResource()). Jika hal-hal ini berubah, opsi ini harus dihilangkan. Berbeda dengan semangat Bazel dan karena batasan platform Android, pengguna bertanggung jawab untuk mengetahui kapan perintah ini sudah cukup dan kapan penginstalan penuh diperlukan.

Jika Anda menggunakan perangkat dengan Marshmallow atau yang lebih baru, pertimbangkan tanda --split_apks.

--split_apks

Apakah akan menggunakan APK terpisah untuk menginstal dan mengupdate aplikasi di perangkat. Hanya berfungsi dengan perangkat yang menjalankan Marshmallow atau yang lebih baru. Perhatikan bahwa tanda --incremental tidak diperlukan saat menggunakan --split_apks.

--start_app

Memulai aplikasi dalam status bersih setelah menginstal. Setara dengan --start=COLD.

--debug_app

Menunggu debugger terpasang sebelum memulai aplikasi dalam kondisi bersih setelah menginstal. Setara dengan --start=DEBUG.

--start=_start_type_

Cara aplikasi harus dimulai setelah menginstalnya. _start_type_s yang didukung adalah:

• NO Tidak memulai aplikasi. Ini adalah default.
• COLD Memulai aplikasi dari status bersih setelah penginstalan.
• WARM Mempertahankan dan memulihkan status aplikasi pada penginstalan inkremental.
• DEBUG Menunggu debugger sebelum memulai aplikasi dalam status bersih setelah penginstalan.

--adb=path

Menunjukkan biner adb yang akan digunakan.

Defaultnya adalah menggunakan adb di Android SDK yang ditentukan oleh --android_sdk.

--adb_arg=serial

Argumen tambahan untuk adb. Argumen ini muncul sebelum subperintah di command line dan biasanya digunakan untuk menentukan perangkat yang akan diinstal. Misalnya, untuk memilih perangkat Android atau emulator yang akan digunakan:

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

memanggil adb sebagai

adb -s deadbeef install ...

--incremental_install_verbosity=number

Tingkat kejelasan untuk penginstalan inkremental. Setel ke 1 agar logging debug dicetak ke konsol.

dump

Perintah dump mencetak ke stdout dump status internal server Bazel. Perintah ini ditujukan terutama untuk digunakan oleh developer Bazel, sehingga output perintah ini tidak ditentukan, dan dapat berubah.

Secara default, perintah hanya akan mencetak pesan bantuan yang menguraikan kemungkinan opsi untuk mengekspor area tertentu dari status Bazel. Untuk mengekspor status internal, setidaknya salah satu opsi harus ditentukan.

Opsi berikut didukung:

• --action_cache menampilkan konten cache tindakan.
• --packages membuang konten cache paket.
• --skyframe menampilkan status grafik dependensi Bazel internal.
• --rules menampilkan ringkasan aturan untuk setiap aturan dan class aspek, termasuk jumlah dan jumlah tindakan. Hal ini mencakup aturan native dan Starlark. Jika pelacakan memori diaktifkan, konsumsi memori aturan juga akan dicetak.
• --skylark_memory akan mengekspor file .gz yang kompatibel dengan pprof ke jalur yang ditentukan. Anda harus mengaktifkan pelacakan memori agar fitur ini berfungsi.

Pelacakan memori

Beberapa perintah dump memerlukan pelacakan memori. Untuk mengaktifkannya, Anda harus meneruskan flag startup ke Bazel:

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

Java-agent diperiksa ke Bazel di third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.4.jar, jadi pastikan Anda menyesuaikan $BAZEL untuk lokasi penyimpanan repositori Bazel Anda.

Jangan lupa untuk terus meneruskan opsi ini ke Bazel untuk setiap perintah atau server akan dimulai ulang.

Contoh:

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

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

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

analyze-profile

Perintah analyze-profile menganalisis profil rekaman aktivitas JSON yang sebelumnya dikumpulkan selama pemanggilan Bazel.

canonicalize-flags

Perintah canonicalize-flags, yang mengambil daftar opsi untuk perintah Bazel dan menampilkan daftar opsi yang memiliki efek yang sama. Daftar opsi baru bersifat kanonis. Misalnya, dua daftar opsi dengan efek yang sama akan dikanonisasi ke daftar baru yang sama.

Opsi --for_command dapat digunakan untuk memilih di antara berbagai perintah. Saat ini, hanya build dan test yang didukung. Opsi yang tidak didukung oleh perintah tertentu akan menyebabkan error.

Sebagai contoh:

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

Opsi startup

Opsi yang dijelaskan di bagian ini memengaruhi startup mesin virtual Java yang digunakan oleh proses server Bazel, dan berlaku untuk semua perintah berikutnya yang ditangani oleh server tersebut. Jika sudah ada server Bazel yang berjalan dan opsi startup tidak cocok, server akan dimulai ulang.

Semua opsi yang dijelaskan di bagian ini harus ditentukan menggunakan sintaksis --key=value atau --key value. Selain itu, opsi ini harus muncul sebelum nama perintah Bazel. Gunakan startup --key=value untuk mencantumkannya dalam file .bazelrc.

--output_base=dir

Opsi ini memerlukan argumen jalur, yang harus menentukan direktori yang dapat ditulis. Bazel akan menggunakan lokasi ini untuk menulis semua outputnya. Dasar output juga merupakan kunci yang digunakan klien untuk menemukan server Bazel. Dengan mengubah basis output, Anda mengubah server yang akan menangani perintah.

Secara default, dasar output berasal dari nama login pengguna, dan nama direktori ruang kerja (sebenarnya, ringkasan MD5-nya), sehingga nilai umum terlihat seperti: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

Contoh:

 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

Dalam perintah ini, dua perintah Bazel berjalan secara bersamaan (karena operator & shell), masing-masing menggunakan instance server Bazel yang berbeda (karena basis output yang berbeda). Sebaliknya, jika dasar output default digunakan dalam kedua perintah, maka kedua permintaan akan dikirim ke server yang sama, yang akan menanganinya secara berurutan: membangun //foo terlebih dahulu, diikuti dengan build inkremental //bar.

--output_user_root=dir

Menunjuk ke direktori root tempat output dan basis penginstalan dibuat. Direktori tidak boleh ada atau harus dimiliki oleh pengguna yang memanggil. Sebelumnya, hal ini diizinkan untuk mengarah ke direktori yang dibagikan di antara berbagai pengguna tetapi tidak diizinkan lagi. Hal ini dapat diizinkan setelah masalah #11100 diselesaikan.

Jika opsi --output_base ditentukan, opsi ini akan menggantikan penggunaan --output_user_root untuk menghitung basis output.

Lokasi basis penginstalan dihitung berdasarkan --output_user_root, ditambah identitas MD5 biner yang disematkan Bazel.

Anda dapat menggunakan opsi --output_user_root untuk memilih lokasi dasar alternatif untuk semua output Bazel (dasar penginstalan dan dasar output) jika ada lokasi yang lebih baik dalam tata letak sistem file Anda.

--server_javabase=dir

Menentukan Java Virtual Machine tempat Bazel itu sendiri berjalan. Nilai harus berupa jalur ke direktori yang berisi JDK atau JRE. Tidak boleh berupa label. Opsi ini harus muncul sebelum perintah Bazel apa pun, misalnya:

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

Flag ini tidak memengaruhi JVM yang digunakan oleh subproses Bazel seperti aplikasi, pengujian, alat, dan sebagainya. Sebagai gantinya, gunakan opsi build --javabase atau --host_javabase.

Sebelumnya, tanda ini bernama --host_javabase (terkadang disebut sebagai --host_javabase 'sisi kiri'), tetapi diganti namanya untuk menghindari kebingungan dengan tanda build --host_javabase (terkadang disebut sebagai --host_javabase 'sisi kanan').

--host_jvm_args=string

Menentukan opsi startup yang akan diteruskan ke Java virtual machine tempat Bazel itu sendiri berjalan. Hal ini dapat digunakan untuk menetapkan ukuran stack, misalnya:

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

Opsi ini dapat digunakan beberapa kali dengan argumen individual. Perhatikan bahwa flag ini jarang perlu disetel. Anda juga dapat meneruskan daftar string yang dipisahkan spasi, yang masing-masing akan ditafsirkan sebagai argumen JVM terpisah, tetapi fitur ini akan segera dihentikan.

Bahwa hal ini tidak memengaruhi JVM yang digunakan oleh subproses Bazel: aplikasi, pengujian, alat, dan sebagainya. Untuk meneruskan opsi JVM ke program Java yang dapat dieksekusi, baik yang dijalankan oleh bazel run maupun di command line, Anda harus menggunakan argumen --jvm_flags yang didukung oleh semua program java_binary dan java_test. Atau untuk pengujian, gunakan bazel test --test_arg=--jvm_flags=foo ....

--host_jvm_debug

Opsi ini menyebabkan mesin virtual Java menunggu koneksi dari debugger yang kompatibel dengan JDWP sebelum memanggil metode utama Bazel itu sendiri. Ini terutama ditujukan untuk digunakan oleh developer Bazel.

--autodetect_server_javabase

Opsi ini menyebabkan Bazel otomatis menelusuri JDK yang diinstal saat startup, dan melakukan penggantian ke JRE yang diinstal jika JRE sematan tidak tersedia. --explicit_server_javabase dapat digunakan untuk memilih JRE eksplisit untuk menjalankan Bazel.

--batch

Mode batch menyebabkan Bazel tidak menggunakan mode klien/server standar, tetapi menjalankan proses java bazel untuk satu perintah, yang telah digunakan untuk semantik yang lebih dapat diprediksi sehubungan dengan penanganan sinyal, kontrol tugas, dan pewarisan variabel lingkungan, dan diperlukan untuk menjalankan bazel di chroot jail.

Mode batch mempertahankan semantik antrean yang tepat dalam output_base yang sama. Artinya, pemanggilan serentak akan diproses secara berurutan, tanpa tumpang-tindih. Jika Bazel mode batch dijalankan di klien dengan server yang sedang berjalan, Bazel akan menghentikan server terlebih dahulu sebelum memproses perintah.

Bazel akan berjalan lebih lambat dalam mode batch, atau dengan alternatif yang dijelaskan di atas. Hal ini karena, antara lain, cache file build berada di memori, sehingga tidak dipertahankan di antara pemanggilan batch berurutan. Oleh karena itu, penggunaan mode batch sering kali lebih masuk akal dalam kasus ketika performa kurang penting, seperti build berkelanjutan.

--max_idle_secs=n

Opsi ini menentukan berapa lama, dalam detik, proses server Bazel harus menunggu setelah permintaan klien terakhir, sebelum keluar. Nilai defaultnya adalah 10800 (3 jam). --max_idle_secs=0 akan menyebabkan proses server Bazel tetap berjalan tanpa batas waktu.

Opsi ini dapat digunakan oleh skrip yang memanggil Bazel untuk memastikan bahwa skrip tidak meninggalkan proses server Bazel di mesin pengguna saat skrip tidak berjalan. Misalnya, skrip pra-commit mungkin ingin memanggil bazel query untuk memastikan bahwa perubahan yang tertunda pengguna tidak menimbulkan dependensi yang tidak diinginkan. Namun, jika pengguna belum melakukan build baru-baru ini di ruang kerja tersebut, skrip pra-kirim tidak akan diinginkan untuk memulai server Bazel hanya agar server tersebut tetap tidak aktif sepanjang hari. Dengan menentukan nilai --max_idle_secs yang kecil dalam permintaan kueri, skrip dapat memastikan bahwa jika skrip menyebabkan server baru dimulai, server tersebut akan segera keluar, tetapi jika sudah ada server yang berjalan, server tersebut akan terus berjalan hingga tidak ada aktivitas selama waktu yang biasa. Tentu saja, timer tidak ada aktivitas server yang ada akan direset.

--[no]shutdown_on_low_sys_mem

Jika diaktifkan dan --max_idle_secs disetel ke durasi positif, setelah server build tidak digunakan selama beberapa waktu, matikan server saat memori sistem hampir habis. Khusus Linux.

Selain menjalankan pemeriksaan tidak ada aktivitas yang sesuai dengan max_idle_secs, server build akan mulai memantau memori sistem yang tersedia setelah server tidak ada aktivitas selama beberapa waktu. Jika memori sistem yang tersedia menjadi sangat rendah, server akan keluar.

--[no]block_for_lock

Jika diaktifkan, Bazel akan menunggu perintah Bazel lain yang memegang kunci server selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan keluar dengan error jika tidak dapat segera mendapatkan kunci dan melanjutkan.

Developer dapat menggunakan ini dalam pemeriksaan pra-commit untuk menghindari penantian lama yang disebabkan oleh perintah Bazel lain di klien yang sama.

--io_nice_level=n

Menetapkan level dari 0-7 untuk penjadwalan IO upaya terbaik. 0 adalah prioritas tertinggi, 7 adalah prioritas terendah. Penjadwal antisipatif hanya dapat mematuhi hingga prioritas 4. Nilai negatif akan diabaikan.

--batch_cpu_scheduling

Gunakan penjadwalan CPU batch untuk Bazel. Kebijakan ini berguna untuk beban kerja yang tidak interaktif, tetapi tidak ingin menurunkan nilai bagusnya. Lihat 'man 2 sched_setscheduler'. Kebijakan ini dapat memberikan interaktivitas sistem yang lebih baik dengan mengorbankan throughput Bazel.

Opsi lain-lain

--[no]announce_rc

Mengontrol apakah Bazel mengumumkan opsi startup dan opsi perintah yang dibaca dari file bazelrc saat memulai.

--color (yes|no|auto)

Opsi ini menentukan apakah Bazel akan menggunakan warna untuk menandai outputnya di layar.

Jika opsi ini disetel ke yes, output warna akan diaktifkan. Jika opsi ini disetel ke auto, Bazel hanya akan menggunakan output warna jika output dikirim ke terminal dan variabel lingkungan TERM disetel ke nilai selain dumb, emacs, atau xterm-mono. Jika opsi ini disetel ke no, output warna dinonaktifkan, terlepas dari apakah output akan masuk ke terminal dan terlepas dari setelan variabel lingkungan TERM.

--config=name

Memilih bagian konfigurasi tambahan dari file rc; untuk command saat ini, opsi dari command:name juga akan ditarik jika bagian tersebut ada. Dapat ditentukan beberapa kali untuk menambahkan tanda dari beberapa bagian konfigurasi. Perluasan dapat merujuk ke definisi lain (misalnya, perluasan dapat dirangkai).

--curses (yes|no|auto)

Opsi ini menentukan apakah Bazel akan menggunakan kontrol kursor dalam output layarnya. Hal ini menghasilkan lebih sedikit data yang perlu di-scroll, dan aliran output yang lebih ringkas dan mudah dibaca dari Bazel. Hal ini berfungsi dengan baik dengan --color.

Jika opsi ini disetel ke yes, penggunaan kontrol kursor akan diaktifkan. Jika opsi ini disetel ke no, penggunaan kontrol kursor akan dinonaktifkan. Jika opsi ini disetel ke auto, penggunaan kontrol kursor akan diaktifkan dalam kondisi yang sama seperti untuk --color=auto.

--[no]show_timestamps

Jika ditentukan, stempel waktu akan ditambahkan ke setiap pesan yang dihasilkan oleh Bazel yang menentukan waktu pesan ditampilkan.