Untuk dokumentasi rilis stabil, gunakan menu drop-down "Dokumen berversi". Tampilan default mencerminkan versi terbaru di HEAD.

Halaman ini diterjemahkan oleh Cloud Translation API.

Perintah dan Opsi

Laporkan masalah Lihat sumber

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

Sintaksis target

Beberapa perintah, seperti build atau test, dapat beroperasi pada daftar target. Mereka menggunakan sintaksis yang lebih fleksibel daripada label, yang didokumentasikan dalam Menentukan target yang akan dibuat.

Opsi

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

Sebagian besar opsi hanya dapat ditentukan sekali. Jika ditentukan beberapa kali, instance terakhir akan menang. Opsi yang dapat ditentukan beberapa kali diidentifikasi di bantuan online dengan teks 'mungkin digunakan berkali-kali'.

Lokasi paket

`--package_path`

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

Bazel menemukan paketnya dengan menelusuri jalur paket tersebut. Ini adalah daftar direktori bazel yang diurutkan, yang dipisahkan titik dua, yang masing-masing menjadi root 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:

Jika karakter pertama adalah /, jalurnya bersifat absolut.
Jika jalur dimulai dengan %workspace%, jalur akan diambil relatif terhadap direktori bazel pembatas terdekat. Misalnya, jika direktori kerja Anda adalah /home/bob/clients/bob_client/bazel/foo, string %workspace% di jalur paket akan diperluas ke /home/bob/clients/bob_client/bazel.
Yang lainnya akan diambil sesuai dengan direktori kerja. Biasanya ini bukan yang Anda inginkan, dan mungkin berperilaku tidak terduga jika Anda menggunakan Bazel dari direktori di bawah ruang kerja bazel. Misalnya, jika Anda menggunakan elemen jalur paket ., lalu melakukan cd ke direktori /home/bob/clients/bob_client/bazel/foo, paket akan di-resolve dari direktori /home/bob/clients/bob_client/bazel/foo.

Jika Anda menggunakan jalur paket non-default, tentukan dalam file konfigurasi Bazel untuk memudahkan.

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 pada jalur paket.

Contoh: Membuat aplikasi dari klien kosong

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % 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 dicoba dimuat dari direktori mana pun pada jalur paket. Ini dapat digunakan untuk menyimulasikan penghapusan paket tanpa benar-benar menghapusnya. Opsi ini dapat diteruskan beberapa kali, yang dalam hal ini setiap daftar digabungkan.

Pemeriksaan error

Opsi ini mengontrol pemeriksaan error dan/atau peringatan Bazel.

`--[no]check_visibility`

Jika opsi ini disetel ke salah (false), pemeriksaan visibilitas akan didemosikan menjadi peringatan. Nilai default opsi ini adalah benar (true), 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 dihapus.

Berikut adalah beberapa nilai umum untuk opsi ini:

`--output_filter='^//(first/project\|second/project):'`	Menampilkan output untuk paket yang ditentukan.
`--output_filter='^//((?!(first/bad_project\|second/bad_project):).)*$'`	Jangan tampilkan output untuk paket yang ditentukan.
`--output_filter=`	Tampilkan semuanya.
`--output_filter=DONT_MATCH_ANYTHING`	Tidak menampilkan apa-apa.

Tanda alat

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

`--copt=cc-option`

Opsi ini menggunakan argumen yang akan diteruskan ke compiler. Argumen akan diteruskan ke compiler setiap kali dipanggil untuk pra-pemrosesan, kompilasi, dan/atau perakitan kode C, C++, atau assembler. URL tersebut tidak akan diteruskan saat ditautkan.

Opsi ini dapat digunakan beberapa kali. Contoh:

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

akan mengompilasi library foo tanpa tabel debug, yang menghasilkan kode yang tidak bergantung 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 eksekusi.

`--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 mengambil 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 eksekusi.

`--host_linkopt=linker-option`

Opsi ini menggunakan 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 menggunakan 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 -Wno-pointer-sign) menggunakan --conlyopt.

`--cxxopt=cc-option`

Opsi ini menggunakan 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 menggunakan argumen yang akan diteruskan ke compiler saat menautkan.

Ini mirip dengan --copt, tetapi hanya berlaku untuk penautan, bukan kompilasi. Jadi, Anda dapat meneruskan opsi compiler yang hanya relevan 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 di atributnya. Setelan opsi ini selalu diprioritaskan. Lihat juga cc_library.linkopts.

`--strip (always|never|sometimes)`

Opsi ini menentukan apakah Bazel akan menghapus informasi proses debug 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 strip jika --compilation_mode adalah fastbuild.

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

akan mengompilasi target saat menghapus informasi proses debug 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 dilakukan dengan meneruskan --linkopt=-Wl,--strip-all ke Bazel. Perhatikan juga bahwa menyetel flag --strip Bazel akan mengganti --linkopt=-Wl,--strip-all, sehingga Anda hanya boleh menetapkan salah satunya.

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

`--stripopt=strip-option`

Ini adalah opsi tambahan untuk 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 masukan) saat biner C/C++ yang dibuat dijalankan. Untuk GCC, argumen yang diberikan digunakan sebagai awalan direktori untuk hierarki 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 dengan FDO.

Untuk compiler LLVM, argumen juga merupakan direktori tempat file data profil LLVM mentah dibuang. 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 masukan) saat melakukan kompilasi. Untuk GCC, argumen yang diberikan adalah file zip yang berisi hierarki file yang dibuat sebelumnya dari file .gcda 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 yang diindeks dan 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 8. --> Nilai yang memungkinkan adalah: 8, 9, 10, 11, 14, 15, dan 21 serta dapat diperluas dengan mendaftarkan toolchain Java kustom menggunakan default_java_toolchain.

`--tool_java_language_version=version`

Versi bahasa Java yang digunakan untuk membangun alat yang dieksekusi selama build. Nilai defaultnya adalah 8.

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

mengunduh JDK 11 dari repositori jarak jauh dan menjalankan aplikasi Java menggunakannya.

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

`--tool_java_runtime_version=version`

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

`--jvmopt=jvm-option`

Opsi ini memungkinkan argumen opsi diteruskan ke VM Java. Class 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 ke 256 MB.

`--javacopt=javac-option`

Opsi ini memungkinkan argumen opsi diteruskan ke javac. Class 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 agar javac 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 adanya dependensi langsung yang hilang. Target Java harus secara eksplisit mendeklarasikan semua target yang digunakan secara langsung sebagai dependensi. Flag ini memerintahkan javac untuk menentukan jar yang benar-benar digunakan untuk pemeriksaan jenis setiap file java, dan memberikan peringatan/error jika bukan merupakan output dari dependensi langsung target saat ini.

off berarti pemeriksaan dinonaktifkan.
warn berarti javac akan menghasilkan peringatan java standar jenis [strict] untuk setiap dependensi langsung yang tidak ada.
default, strict, dan error semuanya berarti javac akan menghasilkan error, bukan peringatan, yang menyebabkan target saat ini gagal dibangun jika ada dependensi langsung yang hilang ditemukan. Hal ini juga merupakan perilaku default jika flag 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 antarmode tanpa perlu melakukan build ulang penuh setiap waktu.

fastbuild berarti mem-build secepat mungkin: menghasilkan informasi proses debug minimal (-gmlt -Wl,-S), dan tidak mengoptimalkan. Ini adalah defaultnya. Catatan: -DNDEBUG tidak akan ditetapkan.
dbg berarti build yang mengaktifkan proses debug (-g), sehingga Anda dapat menggunakan nullable (atau debugger lainnya).
opt berarti build dengan pengoptimalan diaktifkan dan dengan panggilan assert() dinonaktifkan (-O2 -DNDEBUG). Informasi proses debug tidak akan dihasilkan 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 proses build.

`--action_env=VAR=VALUE`

Menentukan kumpulan variabel lingkungan yang tersedia selama eksekusi semua tindakan. Variabel dapat ditentukan menurut nama, yang dalam hal ini nilai akan diambil dari lingkungan pemanggilan, atau oleh pasangan name=value yang menetapkan nilai yang tidak bergantung pada lingkungan pemanggilan.

Flag --action_env ini dapat ditentukan beberapa kali. Jika sebuah nilai ditetapkan ke variabel yang sama di beberapa flag --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 disetel ke benar (true), tindakan tambahan yang ditentukan oleh opsi command line --experimental_action_listener hanya akan dijadwalkan untuk target level teratas.

`--experimental_extra_action_filter=regex`

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

Flag ini hanya berlaku jika digunakan bersama dengan flag --experimental_action_listener.

Secara default, semua extra_actions dalam penutupan transitif target-untuk-build yang diminta akan 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 diterapkan pada 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 membangun alat host.

`--android_platforms=platform[,platform]*`

Platform untuk membangun deps transitif aturan android_binary (khususnya untuk dependensi native seperti C++). Misalnya, jika cc_library muncul dalam deps transitif aturan android_binary, cc_library akan dibuat 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. Awalan nama file .so akan menjadi nama aturan android_binary dengan "lib". Misalnya, jika nama android_binary adalah "foo", maka file-nya adalah libfoo.so.

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

Jika ada, semua file C++ dengan label atau jalur eksekusi yang cocok dengan salah satu ekspresi ekspresi reguler penyertaan dan tidak cocok dengan ekspresi pengecualian mana pun akan dibuat 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++. Kode 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, regexp tidak boleh diawali dengan '//' karena tidak cocok dengan jalur eksekusi mana pun. Nama paket dapat digunakan seperti ini: --per_file_copt=base/.*\.pb\.cc@-g0. Ini akan cocok dengan setiap file .pb.cc pada 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 pengoptimalan dinonaktifkan.

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

Sintaksis: [+-]regex[,[+-]regex]...@option[,option]... Dengan regex adalah singkatan dari ekspresi reguler yang dapat diawali dengan + untuk mengidentifikasi pola penyertaan, dan dengan - untuk mengidentifikasi pola pengecualian. option adalah singkatan dari opsi arbitrer yang diteruskan ke compiler C++. Jika opsi berisi ,, opsi tersebut harus dikutip seperti itu \,. 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:

auto: Menerjemahkan ke mode yang bergantung pada platform; default untuk linux dan off untuk cygwin.
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 linkopt, target akan berubah menjadi statis sepenuhnya.

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

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

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

`--force_ignore_dash_static`

Jika tanda ini disetel, opsi -static apa pun di linkopt aturan cc_* file BUILD akan diabaikan. Langkah ini hanya dimaksudkan sebagai solusi untuk build hardening C++.

`--[no]force_pic`

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

`--android_resource_shrinking`

Memilih apakah akan melakukan penyingkatan resource untuk aturan android_binary. Menetapkan nilai default untuk atribut shrink_resources pada aturan android_binary; lihat dokumentasi aturan tersebut untuk detail lebih lanjut. Nilai defaultnya adalah nonaktif.

`--custom_malloc=malloc-library-target`

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

`--crosstool_top=label`

Opsi ini menentukan lokasi suite 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 exec, seperti alat yang dijalankan selama build. Tujuan utama dari flag ini adalah untuk mengaktifkan kompilasi silang.

`--apple_crosstool_top=label`

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

`--compiler=version`

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

`--android_sdk=label`

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

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

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

`--java_toolchain=label`

Opsi ini menentukan label java_ toolchain yang digunakan untuk mengompilasi file sumber Java.

`--host_java_toolchain=label`

Jika tidak ditentukan, bazel akan menggunakan nilai --java_toolchain untuk mengompilasi kode dalam konfigurasi exec, misalnya untuk alat yang dijalankan selama build. Tujuan utama dari flag ini adalah untuk mengaktifkan kompilasi silang.

`--javabase=(label)`

Opsi ini menetapkan label penginstalan Java dasar yang akan digunakan untuk bazel run, bazel test, dan untuk biner Java yang dibuat oleh aturan java_binary dan java_test. Variabel"Make" JAVABASE dan JAVA berasal dari opsi ini.

`--host_javabase=label`

Opsi ini menetapkan label penginstalan Java dasar yang akan digunakan dalam konfigurasi eksekusi, misalnya untuk fitur build host termasuk JavaBuilder dan Singlejar.

Tindakan ini tidak memilih compiler Java yang digunakan untuk mengompilasi file sumber Java. Compiler dapat dipilih berdasarkan setelan opsi --java_toolchain.

Strategi eksekusi

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

`--spawn_strategy=strategy`

Opsi ini mengontrol di mana dan bagaimana perintah dieksekusi.

standalone menyebabkan perintah dieksekusi sebagai subproses lokal. Nilai ini tidak digunakan lagi. Sebagai gantinya, gunakan local.
sandboxed menyebabkan perintah dijalankan di dalam sandbox pada 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 dalam sandbox.
local menyebabkan perintah dieksekusi sebagai subproses lokal.
worker menyebabkan perintah dijalankan menggunakan pekerja persisten, jika tersedia.
docker menyebabkan perintah dieksekusi di dalam sandbox Docker di mesin lokal. Proses ini memerlukan penginstalan Docker.
remote menyebabkan perintah dijalankan dari jarak jauh; ini hanya tersedia jika eksekutor jarak jauh telah dikonfigurasi secara terpisah.

`--strategy mnemonic=strategy`

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

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

Opsi ini menentukan strategi 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 tanda 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 'Mengompilasi //foo/bar/baz' dengan strategi sandboxed, tetapi membalik urutan akan menjalankannya dengan local.
Contoh: --strategy_regexp='Compiling.*/bar=local,sandboxed' menjalankan 'Mengompilasi //foo/bar/baz' dengan strategi local dan kembali ke sandboxed jika gagal.

`--genrule_strategy=strategy`

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

`--jobs=n` (-j)

Opsi ini, yang menggunakan argumen bilangan bulat, menentukan batas jumlah tugas yang harus dieksekusi 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.

Defaultnya adalah 0, yang berarti algoritma inkremental: laporan pertama akan dicetak setelah 10 detik, lalu 30 detik, dan setelah itu progres tersebut dilaporkan sekali 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. Keduanya mengambil bilangan bulat, atau kata kunci (HOST_RAM atau HOST_CPUS) yang dapat diikuti oleh [-|*float] (misalnya, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). Flag bersifat independen; salah satu atau keduanya dapat ditetapkan. Secara default, Bazel memperkirakan jumlah RAM dan jumlah inti CPU langsung dari konfigurasi sistem lokal.

`--[no]build_runfile_links`

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

Saat pengujian (atau aplikasi) dijalankan, dependensi data run-time-nya dikumpulkan di satu tempat. Dalam hierarki output Bazel, hierarki "runfiles" ini biasanya di-root sebagai seinduk dari biner atau pengujian terkait. Selama eksekusi uji, runfile dapat diakses menggunakan jalur berformat $TEST_SRCDIR/workspace/packagename/filename. Hierarki runfiles memastikan bahwa pengujian memiliki akses ke semua file di atas file tersebut memiliki dependensi yang dideklarasikan, dan tidak lebih. Secara default, hierarki runfiles diimplementasikan dengan membuat sekumpulan link simbolis ke file yang diperlukan. Seiring bertambahnya kumpulan link, biaya operasi ini juga bertambah, dan untuk beberapa build besar, link ini dapat berkontribusi secara signifikan terhadap waktu build keseluruhan, terutama karena setiap pengujian (atau aplikasi) memerlukan hierarki runfile-nya sendiri.

`--[no]build_runfile_manifests`

Opsi yang diaktifkan secara default ini menentukan apakah manifes runfile harus ditulis ke hierarki output. Menonaktifkannya akan menunjukkan --nobuild_runfile_links.

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

`--[no]discard_analysis_cache`

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

`--[no]keep_going` (-k)

Seperti pada GNU Make, fase eksekusi build akan berhenti saat error pertama ditemukan. Terkadang ada baiknya untuk mencoba membuat sebanyak mungkin bahkan saat menghadapi error. Opsi ini memungkinkan perilaku tersebut, dan jika ditentukan, build akan mencoba membangun setiap target yang prasyaratnya berhasil dibuat, tetapi akan mengabaikan error.

Meskipun opsi ini biasanya dikaitkan dengan fase eksekusi build, opsi ini juga memengaruhi fase analisis: jika beberapa target ditentukan dalam perintah build, tetapi hanya beberapa target yang berhasil dianalisis, 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 (kolom dan metode akses publik, terlindungi, dan default) dan menggunakan jar antarmuka untuk mengompilasi target dependen. Hal ini memungkinkan untuk menghindari kompilasi ulang jika perubahan hanya dilakukan pada isi metode atau anggota pribadi class.

`--[no]interface_shared_objects`

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

Pilihan output

Opsi ini menentukan apa yang akan dibangun atau diuji.

`--[no]build`

Opsi ini menyebabkan fase eksekusi build terjadi; fitur ini aktif secara default. Saat dinonaktifkan, fase eksekusi akan dilewati, dan hanya dua fase pertama, yaitu pemuatan dan analisis, yang akan 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 mem-build hal 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 pada command line. Secara default, opsi ini dinonaktifkan dan Bazel akan membuat semua yang diminta, termasuk aturan *_test dan test_suite yang dikecualikan dari pengujian. Hal ini berguna karena menjalankan bazel test --build_tests_only foo/... mungkin tidak mendeteksi semua kerusakan build di hierarki foo.

`--[no]check_up_to_date`

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

Lihat juga --check_tests_up_to_date.

`--[no]compile_one_dependency`

Mengompilasi satu dependensi dari file argumen. Hal ini berguna untuk pemeriksaan sintaksis file sumber di IDE, misalnya, dengan membangun ulang satu target yang bergantung pada file sumber untuk mendeteksi error sedini mungkin dalam siklus edit/build/pengujian. Argumen ini memengaruhi penafsiran semua argumen non-tanda: setiap argumen harus berupa label target file atau nama file biasa yang terkait dengan direktori kerja saat ini, dan dibuat satu aturan yang bergantung pada setiap nama file sumber. 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 BANGUN akan dipilih. Pola target bernama eksplisit yang tidak mereferensikan file sumber akan menghasilkan error.

`--save_temps`

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

Tanda --save_temps saat ini hanya berfungsi untuk aturan cc_*.

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

`--build_tag_filters=tag[,tag]*`

Jika ditentukan, Bazel hanya akan membuat 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, secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan mungkin juga memiliki tanda '+' sebelumnya.

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

`--test_size_filters=size[,size]*`

Jika ditentukan, Bazel akan menguji (atau mem-build jika --build_tests_only juga ditentukan) hanya menguji target dengan ukuran yang ditentukan. Filter ukuran pengujian ditentukan sebagai daftar nilai ukuran pengujian yang diizinkan yang dipisahkan koma (kecil, sedang, besar, atau sangat besar), secara opsional didahului 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

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

Secara default, pemfilteran ukuran pengujian tidak diterapkan.

`--test_timeout_filters=timeout[,timeout]*`

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

Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.

`--test_tag_filters=tag[,tag]*`

Jika ditentukan, Bazel hanya akan menguji (atau mem-build jika --build_tests_only juga ditentukan) hanya menguji target 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, secara opsional diawali dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan mungkin juga memiliki tanda '+' sebelumnya.

Misalnya,

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

akan menguji target yang diberi tag dengan 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 mem-build jika --build_tests_only juga ditentukan) hanya target dari class aturan yang direferensikan. 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 untuk instance foo_test dan bar_test.

`--test_filter=filter-expression`

Menentukan filter yang dapat digunakan runner pengujian untuk memilih subset pengujian untuk dijalankan. Semua target yang ditentukan dalam pemanggilan akan dibangun, tetapi bergantung pada ekspresi, hanya beberapa di antaranya 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. Data ini dapat berupa glob, substring, atau regexp. --test_filter adalah cara yang lebih praktis untuk meneruskan argumen filter --test_arg yang berbeda, tetapi tidak semua framework mendukungnya.

Panjang

Opsi ini mengontrol panjang output Bazel, baik ke terminal maupun ke file log tambahan.

`--explain=logfile`

Opsi yang memerlukan argumen nama file ini menyebabkan pemeriksa dependensi dalam fase eksekusi bazel build menjelaskan untuk setiap langkah build, alasan eksekusinya, atau versi terbaru. Penjelasan ditulis ke logfile.

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

`--verbose_explanations`

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

Khususnya, jika penjelasan panjang diaktifkan, dan file output dibuat ulang karena perintah yang digunakan untuk mem-build-nya telah berubah, output dalam file penjelasan akan menyertakan detail lengkap perintah baru (setidaknya untuk sebagian besar perintah).

Menggunakan opsi ini dapat secara signifikan menambah durasi file penjelasan yang dihasilkan dan konsekuensi performa dari penggunaan --explain.

Jika --explain tidak diaktifkan, --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 diurai 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 menghasilkan output pesan progres pemuatan paket. Jika dinonaktifkan, pesan tidak akan ditampilkan.

`--[no]show_progress`

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

`--show_progress_rate_limit=n`

Opsi ini menyebabkan bazel menampilkan maksimal satu pesan progres per n detik, dengan n adalah bilangan riil. Nilai default untuk opsi ini adalah 0,02, yang berarti bazel akan membatasi pesan progres menjadi satu per 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 diperbarui atau tidak, dan jika ya, daftar file output yang dibuat target. Jika beberapa target ditentukan, informasi hasil tidak akan ditampilkan.

Meskipun informasi hasilnya mungkin berguna untuk build dari satu target atau beberapa target, untuk build besar (seperti seluruh hierarki project level atas), informasi ini bisa sangat berlebihan dan mengganggu; opsi ini memungkinkannya untuk dikontrol. --show_result menggunakan argumen bilangan bulat, yang merupakan jumlah maksimum target yang informasi hasil lengkapnya harus dicetak. Secara {i>default<i}, nilainya adalah 1. Di atas batas 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 dapat memilih nilai di antara keduanya jika mereka secara rutin bergantian antara membangun 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, kurang begitu bermanfaat. Seperti semua opsi, informasi ini dapat ditentukan secara implisit melalui file .bazelrc.

File ini dicetak untuk memudahkan Anda menyalin dan menempelkan nama file ke shell, untuk menjalankan file yang dapat dieksekusi yang sudah dibangun. Pesan "terbaru" atau "gagal" untuk setiap target dapat diurai dengan mudah 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 menjalankannya.

  >>>>> # //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 akan dicetak dalam sintaksis yang kompatibel dengan shell Bourne, sehingga dapat dengan mudah disalin dan ditempelkan ke command prompt shell. (Tanda kurung di sekitarnya disediakan untuk melindungi shell dari panggilan cd dan exec; pastikan untuk menyalinnya.) Namun, beberapa perintah diimplementasikan secara internal dalam Bazel, seperti membuat hierarki symlink. Tidak ada command line untuk ditampilkan.

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

Lihat juga --verbose_failures, di bawah.

Untuk mencatat subperintah ke file dalam format yang mudah digunakan, 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 sangat berharga untuk men-debug build yang gagal.

Perintah yang gagal akan dicetak dalam sintaksis yang kompatibel dengan Bourne shell, yang cocok untuk menyalin dan menempel ke perintah shell.

Status ruang kerja

Gunakan opsi berikut untuk "menstempel" 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`

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

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

Program akan mencetak nol atau beberapa key-value pair ke output standar, satu entri di setiap baris, lalu keluar dengan nol (jika tidak, build akan gagal). Nama kunci bisa apa saja tetapi hanya boleh menggunakan huruf besar dan garis bawah. Spasi pertama setelah nama kunci memisahkannya dari nilai. Nilainya adalah sisa baris (termasuk spasi kosong tambahan). Kunci maupun nilai tidak boleh menjangkau beberapa baris. Kunci tidak boleh diduplikasi.

Bazel membagi kunci menjadi dua bucket: "stabil" dan "volatil". (Nama "stabil" dan "volatil" sedikit kontra-intuitif, jadi jangan terlalu dipikirkan.)

Bazel kemudian 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" akan jarang berubah, jika memungkinkan. Jika konten bazel-out/stable-status.txt berubah, Bazel akan membatalkan tindakan yang bergantung padanya. Dengan kata lain, jika nilai kunci yang stabil berubah, Bazel akan menjalankan kembali tindakan yang telah diberi stempel. Oleh karena itu, status stabil tidak boleh berisi hal-hal seperti stempel waktu, karena status tersebut selalu berubah, dan akan membuat Bazel menjalankan kembali tindakan yang telah diberi stempel dengan setiap build.

Bazel selalu menghasilkan output kunci stabil berikut:
- BUILD_EMBED_LABEL: nilai --embed_label
- BUILD_HOST: nama mesin host yang dijalankan Bazel
- BUILD_USER: nama pengguna yang dijalankan Bazel
nilai kunci "volatil" mungkin sering berubah. Bazel mengharapkannya berubah sepanjang waktu, seperti stempel waktu, dan memperbarui file bazel-out/volatile-status.txt secara berkala. Untuk menghindari menjalankan kembali tindakan berstempel setiap saat, Bazel berpura-pura bahwa file yang tidak stabil tidak pernah berubah. Dengan kata lain, jika file status volatil adalah satu-satunya file yang isinya telah berubah, Bazel tidak akan membatalkan tindakan yang bergantung padanya. Jika input lain untuk tindakan telah berubah, Bazel akan menjalankan kembali tindakan tersebut, dan tindakan akan melihat status volatil terbaru, tetapi hanya perubahan status volatil saja yang tidak akan membatalkan tindakan.

Bazel selalu menghasilkan kunci volatil berikut:
- BUILD_TIMESTAMP: waktu build dalam detik sejak Unix Epoch (nilai System.currentTimeMillis() dibagi seribu)
- FORMATTED_DATE: waktu build Diformat sebagai yyyy MMM d HH mm ss EEE(misalnya, 2 Juni 2023 01 44 29 Jum) 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 efek yang sama.

Jika perintah status workspace gagal (keluar bukan 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 STABLE, sedangkan file status volatil akan menyertakan baris lainnya.

`--[no]stamp`

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

Stempel dapat diaktifkan atau dinonaktifkan secara eksplisit per aturan menggunakan atribut stamp. Silakan baca Build Encyclopedia untuk mengetahui detailnya. Saat aturan menetapkan stamp = -1 (default untuk aturan *_binary), opsi ini menentukan apakah stempel diaktifkan atau tidak.

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

Menyetel --nostamp umumnya diinginkan untuk performa build, karena mengurangi volatilitas input dan memaksimalkan cache 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 mendeskripsikan 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 WORKSPACE oleh register_execution_platforms(). Opsi ini menerima daftar platform yang dipisahkan koma berdasarkan urutan prioritas. Jika tanda tersebut diteruskan beberapa kali, maka penggantian terbaru.

`--extra_toolchains=labels`

Aturan toolchain yang akan dipertimbangkan selama resolusi toolchain. Toolchain dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Toolchain ini akan dipertimbangkan sebelum yang dideklarasikan dalam file WORKSPACE oleh register_toolchains().

`--toolchain_resolution_debug=regex`

Mencetak informasi debug saat mencari toolchain jika jenis toolchain cocok dengan ekspresi reguler. Beberapa regex dapat dipisahkan dengan koma. Ekspresi reguler dapat diabaikan dengan menggunakan - di awal. Hal ini dapat membantu developer aturan Bazel atau Starlark menangani kegagalan proses debug karena toolchain 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 symlink 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 masih dianggap berhasil. Secara khusus, hal ini memungkinkan Anda membangun di direktori yang bersifat hanya baca atau direktori yang izin penulisannya tidak Anda miliki. Setiap jalur yang dicetak dalam pesan informasi pada akhir build hanya akan menggunakan bentuk pendek relatif symlink jika symlink mengarah ke lokasi yang diharapkan; dengan kata lain, Anda dapat mengandalkan ketepatan jalur tersebut, meskipun Anda tidak dapat mengandalkan symlink yang dibuat.

Beberapa nilai umum opsi ini:

Hentikan 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 menyembunyikan pembuatan symlink sepenuhnya.
Mengurangi kekacauan: --symlink_prefix=.bazel/ akan menyebabkan Bazel membuat symlink yang disebut 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 cache ditemukan untuk build yang jika tidak saling merusak file yang dihasilkan, atau untuk mempertahankan file output untuk dibandingkan.

`--default_visibility=(private|public)`

Tanda sementara untuk menguji perubahan visibilitas default bazel. Tidak dimaksudkan untuk penggunaan umum tetapi didokumentasikan demi kelengkapan.

`--starlark_cpu_profile=_file_`

Flag 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 yang diberi nama.

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 berbagai tampilan data yang sama, coba perintah pprof svg, web, dan list.

Menggunakan Bazel untuk rilis

Bazel digunakan oleh software engineer 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 akan muncul seperti skrip lainnya yang menjalankan build. Untuk detail selengkapnya, lihat Memanggil Bazel dari skrip. Secara khusus, opsi berikut sangat direkomendasikan:

Opsi berikut 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 symlink bazel-bin (dll.).

Menjalankan pengujian

Untuk membuat dan menjalankan pengujian dengan bazel, ketik bazel test diikuti dengan nama target pengujian.

Secara default, perintah ini menjalankan aktivitas build dan pengujian secara bersamaan, dengan membangun semua target yang ditentukan (termasuk target non-pengujian yang ditentukan pada command line) serta menguji target *_test dan test_suite segera setelah prasyarat dibuat, yang berarti eksekusi uji akan disisipkan dengan build. Melakukan hal tersebut biasanya akan meningkatkan kecepatan yang signifikan.

Opsi untuk `bazel test`

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

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

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

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

Jika 'ya', perilaku caching akan sama seperti otomatis kecuali bahwa perilaku ini dapat meng-cache kegagalan uji dan pengujian berjalan dengan --runs_per_test.

Pengguna yang telah mengaktifkan opsi ini secara default dalam file .bazelrc mereka mungkin merasa singkatan -t (aktif) atau -t- (nonaktif) 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 dibuat dan dijalankan sebelumnya, atau yang hasil pengujiannya sudah usang (misalnya, karena kode sumber atau opsi build telah berubah), Bazel akan melaporkan pesan error ("hasil pengujian bukan yang terbaru"), akan mencatat status pengujian sebagai "NO STATUS" (berwarna merah, jika output warna diaktifkan), dan akan menampilkan kode keluar yang bukan nol.

Opsi ini juga menyiratkan perilaku [--check_up_to_date](#check-up-to-date).

Opsi ini mungkin berguna untuk pemeriksaan pra-pengiriman.

`--test_verbose_timeout_warnings`

Opsi ini memberi tahu Bazel untuk secara eksplisit memperingatkan pengguna jika waktu tunggu pengujian jauh lebih lama daripada waktu eksekusi pengujian yang sebenarnya. Meskipun waktu tunggu pengujian harus diatur sedemikian rupa agar tidak mudah berubah, pengujian yang memiliki waktu tunggu yang sangat banyak dapat menyembunyikan masalah nyata yang muncul secara tidak terduga.

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

Opsi ini berguna untuk membantu pengguna menentukan 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 flag ini dinonaktifkan, build akan dibatalkan pada pengujian yang tidak lulus. Langkah build selanjutnya dan pemanggilan pengujian tidak akan dijalankan, dan pemanggilan yang sedang berlangsung akan dibatalkan. Jangan menentukan --notest_keep_going dan --keep_going.

`--flaky_test_attempts=attempts`

Opsi ini menentukan jumlah maksimum pengujian yang harus dicoba jika gagal karena alasan apa pun. Pengujian yang awalnya gagal, tetapi akhirnya berhasil dilaporkan sebagai FLAKY pada ringkasan pengujian. Namun, nilai ini dianggap diteruskan dalam hal mengidentifikasi kode keluar Bazel atau jumlah total pengujian yang lulus. Pengujian yang gagal dari semua percobaan yang diizinkan akan 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 atribut flaky yang ditetapkan. Anda dapat menentukan nilai bilangan bulat untuk mengganti batas maksimum percobaan pengujian. Bazel mengizinkan maksimal 10 upaya pengujian untuk mencegah penyalahgunaan sistem.

`--runs_per_test=[regex@]number`

Opsi ini menentukan berapa kali setiap pengujian harus dijalankan. Semua eksekusi uji diperlakukan sebagai pengujian terpisah (fungsi penggantian akan berlaku untuk setiap eksekusi secara independen).

Status target dengan operasi yang gagal bergantung pada nilai flag --runs_per_test_detects_flakes:

Jika tidak ada, kegagalan operasi akan menyebabkan seluruh pengujian gagal.
Jika ada dan dua sesi dari shard yang sama menampilkan PASS dan FAIL yang sama, pengujian akan menerima status tidak stabil (kecuali jika operasi gagal lainnya menyebabkannya gagal).

Jika satu angka ditentukan, semua pengujian akan dijalankan berkali-kali. Atau, ekspresi reguler dapat ditentukan menggunakan sintaksis regex@number. Hal ini membatasi efek --runs_per_test ke target yang cocok dengan ekspresi reguler (--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 operasi untuk satu shard gagal dan satu atau beberapa operasi untuk shard yang sama berjalan, target akan dianggap tidak stabil dengan flag tersebut. Jika tidak ditentukan, target akan melaporkan status gagal.

`--test_summary=output_style`

Menentukan cara ringkasan hasil pengujian akan ditampilkan.

short mencetak hasil setiap pengujian beserta nama file yang berisi output pengujian jika pengujian gagal. Nilai ini adalah defaultnya.
terse seperti short, tetapi lebih pendek lagi: hanya mencetak informasi tentang pengujian yang tidak lulus.
detailed mencetak setiap kasus pengujian individual yang gagal, bukan hanya setiap pengujian. Nama file output pengujian dihilangkan.
none tidak mencetak ringkasan pengujian.

`--test_output=output_style`

Menentukan cara output pengujian akan ditampilkan:

summary menunjukkan ringkasan apakah setiap pengujian lulus atau gagal. Bagian ini juga menampilkan nama file log output untuk pengujian yang gagal. Ringkasan akan dicetak di akhir build (selama build, pengguna 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 memastikan bahwa output pengujian dari pengujian simultan tidak disisipi satu sama lain. Mencetak ringkasan pada build sesuai output ringkasan di atas.
all mirip dengan errors tetapi mencetak output untuk semua pengujian, termasuk yang lulus.
streamed melakukan streaming output stdout/stderr dari setiap pengujian secara real time.

`--java_debug`

Opsi ini menyebabkan mesin virtual Java pada pengujian java menunggu koneksi dari debugger yang sesuai dengan JDK sebelum memulai pengujian. Opsi ini menyiratkan --test_output=streamed.

`--[no]verbose_test_summary`

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

`--test_tmpdir=path`

Menentukan direktori sementara untuk pengujian yang dijalankan secara lokal. Setiap pengujian akan dijalankan di subdirektori terpisah di dalam direktori ini. Direktori akan dibersihkan pada awal setiap perintah bazel test. Secara default, bazel akan menempatkan direktori ini pada 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 singkat, sedang, panjang, dan abadi (dalam urutan tersebut). Dalam kedua bentuk tersebut, nilai nol atau negatif untuk ukuran pengujian akan diganti dengan waktu tunggu default untuk kategori waktu tunggu yang ditentukan seperti yang ditetapkan oleh halaman Writing Tests. Secara default, Bazel akan menggunakan waktu tunggu ini untuk semua pengujian dengan menyimpulkan batas waktu tunggu dari ukuran pengujian, baik ukuran ditetapkan secara implisit maupun eksplisit.

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

`--test_arg=arg`

Meneruskan opsi/tanda/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.

Perlu diketahui bahwa tidak seperti perintah bazel run, Anda tidak dapat meneruskan argumen pengujian secara langsung seperti di bazel test -- target --logtostderr --v=3. Hal ini karena argumen yang tidak relevan 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 --, flag tidak akan diproses oleh Bazel tetapi diteruskan kata demi kata 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, kode tersebut akan diwarisi dari lingkungan shell yang digunakan untuk memulai perintah bazel test.

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

`--run_under=command-prefix`

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

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

Beberapa peringatan berlaku:

PATH yang digunakan untuk menjalankan pengujian mungkin berbeda dengan PATH di lingkungan Anda, jadi Anda mungkin perlu menggunakan jalur absolut untuk perintah --run_under (kata pertama di 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'

Menguji pilihan

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 sama persis seperti bazel build.

Menjalankan {i>executable<i}

Perintah bazel run mirip dengan bazel build, tetapi digunakan untuk membuat dan menjalankan satu target. Berikut ini adalah sesi yang umum:

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

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

bazel run mirip, tetapi tidak identik, dengan memanggil langsung biner yang dibuat oleh Bazel dan perilakunya berbeda, bergantung pada apakah biner yang akan dipanggil adalah pengujian atau bukan.

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

Jika biner adalah pengujian, direktori kerja saat ini adalah root eksekusi dan upaya dengan niat baik akan dilakukan untuk mereplikasi lingkungan tempat pengujian biasanya dijalankan. Namun, emulasi tersebut belum sempurna dan pengujian yang memiliki beberapa shard tidak dapat dijalankan dengan cara ini (opsi command line --test_sharding_strategy=disabled dapat digunakan untuk mengatasi hal 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.

Atribut ini dapat digunakan, misalnya, untuk menafsirkan nama file pada command line dengan cara yang mudah digunakan.

Opsi untuk `bazel run`

`--run_under=command-prefix`

Hal ini memiliki efek yang sama dengan opsi --run_under untuk bazel test (lihat di atas), kecuali bahwa hal ini berlaku untuk perintah yang sedang 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 akan mencetak output logging dari Bazel sendiri dan biner yang sedang dipanggil. Untuk membuat log tidak terlalu berisik, Anda dapat menyembunyikan output dari Bazel itu sendiri dengan flag --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 memiliki efek menjalankan pengujian dalam pendekatan yang mendekati lingkungan yang dijelaskan dalam Pengujian Menulis. Perlu diperhatikan 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 perintah Make. Ini akan menghapus direktori output untuk semua konfigurasi build yang dijalankan oleh instance Bazel ini, atau seluruh hierarki kerja yang dibuat oleh instance Bazel ini, dan mereset cache internal. Jika dijalankan tanpa opsi command line, direktori output untuk semua konfigurasi akan dibersihkan.

Ingat 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 sepenuhnya menghapus seluruh hierarki kerja yang dibuat oleh instance Bazel, Anda dapat menentukan opsi --expunge. Saat dijalankan dengan --expunge, perintah clean hanya akan 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, 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 permanen di latar belakang dengan menggunakan --expunge_async. Perintah Bazel dapat dipanggil di klien yang sama saat penghapusan permanen asinkron terus berjalan.

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

Dalam desain Bazel, masalah ini dapat diperbaiki dan bug ini merupakan prioritas tinggi untuk diperbaiki. Jika Anda menemukan build inkremental yang salah, laporkan bug dan laporkan bug di alat tersebut, bukan 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: {i>query<i} dan {i>cquery<i}. Perbedaan utama antara kedua perintah tersebut adalah kueri berjalan setelah fase pemuatan dan cquery berjalan setelah fase analisis. Alat-alat ini adalah bantuan yang sangat berharga untuk banyak tugas rekayasa perangkat lunak.

Bahasa kueri didasarkan pada gagasan tentang operasi aljabar daripada grafik; bahasa kueri ini didokumentasikan secara detail

Referensi Kueri Bazel. Lihat dokumen tersebut untuk referensi, untuk mengetahui contoh, dan untuk 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 jika 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 yang digunakan oleh kueri.

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

Contoh: "Tampilkan lokasi definisi (dalam file BUILD) semua genrules yang diperlukan untuk membuat semua pengujian di 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. Solusi ini beroperasi pada grafik target yang dikonfigurasi pasca-analisis dan menampilkan 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. Secara khusus, perintah aquery berjalan di atas build Bazel biasa dan mewarisi serangkaian opsi yang tersedia selama build.

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

Untuk detail selengkapnya, lihat Kueri Grafik Tindakan.

Perintah dan opsi lain-lain

`help`

Perintah help menyediakan bantuan online. Secara default, panel ini menampilkan ringkasan perintah yang tersedia dan topik bantuan, seperti yang ditunjukkan dalam Membangun aplikasi 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 begitu tidak ada aktivitas (misalnya, setelah penyelesaian build atau perintah lain yang sedang berlangsung). Untuk mengetahui detail selengkapnya, lihat Implementasi klien/server.

Server Bazel berhenti sendiri setelah waktu tunggu tidak ada aktivitas, sehingga perintah ini jarang diperlukan; tetapi dapat berguna dalam skrip jika sudah 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, penonaktifan ini akan menyesuaikan jumlah memori yang sudah dipakai. Hal ini berguna untuk skrip yang memulai banyak build, karena kebocoran memori di server Bazel dapat menyebabkan error secara tidak sengaja pada suatu acara. Dengan melakukan mulai ulang bersyarat, kondisi ini akan di-preempt.

`info`

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

Perintah info juga mengizinkan argumen tunggal (opsional), yang merupakan 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 menghindari kebutuhan untuk menyalurkan hasil melalui sed -ne /key:/s/key://p:

Data yang tidak bergantung pada 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 menyimpan semua hasil awal dan membuat output di bawah direktori ini.
execution_root: jalur absolut ke direktori root eksekusi di bawah 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, symlink bernama bazel-<workspace> akan ditempatkan di sana yang mengarah ke direktori ini.
output_path: jalur absolut ke direktori output di bawah root eksekusi yang digunakan untuk semua file yang sebenarnya dihasilkan sebagai hasil dari perintah build. Jika direktori ruang kerja dapat ditulis, symlink bernama bazel-out akan ditempatkan di sana yang mengarah ke direktori ini.
server_pid: ID proses 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 konsumsi manusia oleh developer Bazel dan pengguna super.
command_log: jalur absolut ke file log perintah; ini berisi stream stdout dan stderr yang disisipkan dari perintah Bazel terbaru. Perlu diperhatikan bahwa menjalankan bazel info akan menimpa konten file ini, karena konten tersebut akan 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 sedang digunakan, memori yang saat ini dijamin tersedia untuk JVM dari sistem, alokasi maksimum yang memungkinkan.
gc-count, gc-time: Jumlah kumulatif pembersihan sampah memori sejak dimulainya server Bazel ini dan waktu yang dihabiskan untuk melakukannya. Perhatikan bahwa nilai ini tidak direset pada awal setiap build.
package_path: Daftar jalur yang dipisahkan titik dua yang akan ditelusuri untuk paket 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 di antaranya 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. Meskipun tidak selalu, proses ini biasanya sama dengan symlink bazel-* yang dibuat di direktori ruang kerja dasar setelah build yang berhasil. Namun, jika direktori ruang kerja bersifat hanya baca, tidak ada symlink bazel-* yang dapat dibuat. Skrip yang menggunakan nilai yang dilaporkan oleh bazel info, alih-alih berasumsi bahwa keberadaan symlink, akan lebih tangguh.
Lingkungan"Make" yang lengkap. Jika flag --show_make_env ditentukan, semua variabel dalam lingkungan "Make" konfigurasi saat ini juga akan ditampilkan (seperti CC, GLIBC_VERSION, dll.). Ini adalah variabel yang 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", sehingga flag --show_make_env diperlukan.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Contoh: direktori output bazel-bin untuk konfigurasi saat ini. Hal ini dijamin akan benar meskipun jika symlink bazel-bin tidak dapat dibuat karena beberapa alasan (misalnya jika Anda mem-build 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 dibangun, termasuk daftar perubahan tempatnya dibuat dan tanggalnya. Hal ini sangat berguna dalam menentukan apakah Anda memiliki Bazel terbaru atau apakah Anda melaporkan bug. Beberapa nilai yang menarik adalah:

changelist: daftar perubahan tempat 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 memunculkan output yang sama seperti bazel version --gnu_format, kecuali tanpa efek samping berupa kemungkinan memulai server Bazel atau mengekstrak arsip server. bazel --version dapat dijalankan dari mana saja dan 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 instal seluler bazel untuk informasi selengkapnya.

Opsi berikut didukung:

`--incremental`

Jika disetel, Bazel akan mencoba menginstal aplikasi secara bertahap, yaitu hanya bagian yang telah berubah sejak build terakhir. Tindakan ini tidak dapat mengupdate 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. Berlawanan dengan semangat Bazel dan karena keterbatasan platform Android, bertanggung jawab pengguna untuk mengetahui kapan perintah ini sudah cukup baik dan kapan diperlukan penginstalan penuh.

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

`--split_apks`

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

`--start_app`

Memulai aplikasi dalam keadaan bersih setelah diinstal. Setara dengan --start=COLD.

`--debug_app`

Menunggu hingga debugger dipasangkan sebelum memulai aplikasi dalam status bersih setelah diinstal. Setara dengan --start=DEBUG.

`--start=_start_type_`

Bagaimana aplikasi harus dimulai setelah diinstal. _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 saat penginstalan inkremental.
DEBUG Menunggu debugger sebelum memulai aplikasi dalam status bersih setelah diinstal.

`--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 ke adb. Ini muncul sebelum subperintah dalam 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`

Panjang untuk penginstalan inkremental. Tetapkan ke 1 agar logging debug akan dicetak ke konsol.

`dump`

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

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

Opsi berikut didukung:

--action_cache membuang konten cache tindakan.
--packages membuat konten cache paket dump.
--skyframe menghapus status grafik dependensi Bazel internal.
--rules akan membuang ringkasan aturan dump 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 mengeluarkan file .gz yang kompatibel dengan pprof ke jalur yang ditentukan. Anda harus mengaktifkan pelacakan memori agar pelacakan 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.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1

java-agent diperiksa ke Bazel di third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, jadi pastikan Anda menyesuaikan $BAZEL untuk tempat Anda menyimpan repositori Bazel.

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.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

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

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

`analyze-profile`

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 dikanonikalisasi 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 yang ditentukan 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 ada server Bazel yang sudah 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. Basis output juga merupakan kunci yang digunakan klien untuk menemukan server Bazel. Dengan mengubah basis output, Anda mengubah server yang akan menangani perintah.

Secara default, basis output berasal dari nama login pengguna, dan nama direktori ruang kerja (sebenarnya, ringkasan MD5-nya), sehingga nilai standar 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, kedua perintah Bazel berjalan bersamaan (karena operator & shell), masing-masing menggunakan instance server Bazel yang berbeda (karena basis output yang berbeda). Sebaliknya, jika basis output default digunakan di kedua perintah, kedua permintaan akan dikirim ke server yang sama, yang akan menanganinya secara berurutan: membuat //foo terlebih dahulu, diikuti dengan build //bar inkremental.

`--output_user_root=dir`

Mengarah ke direktori utama tempat output dan basis penginstalan dibuat. Direktori tersebut tidak boleh ada atau dimiliki oleh pengguna yang melakukan panggilan. Sebelumnya, baris ini diizinkan untuk mengarah ke direktori yang dibagikan dengan berbagai pengguna, tetapi tidak diizinkan lagi. Hal ini mungkin diizinkan setelah masalah #11100 ditangani.

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

Lokasi basis penginstalan dihitung berdasarkan --output_user_root, ditambah identitas MD5 dari biner tersemat Bazel.

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

`--server_javabase=dir`

Menentukan virtual machine Java tempat Bazel sendiri dijalankan. Nilai harus berupa jalur ke direktori yang berisi JDK atau JRE. Label tidak boleh berupa label. Opsi ini akan muncul sebelum perintah Bazel apa pun, misalnya:

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 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.

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

`--host_jvm_args=string`

Menentukan opsi startup yang akan diteruskan ke virtual machine Java tempat Bazel itu sendiri berjalan. Ini dapat digunakan untuk menyetel ukuran tumpukan, misalnya:

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

Opsi ini dapat digunakan beberapa kali dengan argumen individual. Perhatikan bahwa penetapan tanda ini biasanya jarang diperlukan. Anda juga dapat meneruskan daftar string yang dipisahkan spasi, yang masing-masing akan ditafsirkan sebagai argumen JVM terpisah, tetapi fitur ini tidak akan digunakan lagi dalam waktu dekat.

Hal ini tidak akan memengaruhi JVM apa pun 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 atau 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 sesuai dengan JDWP sebelum memanggil metode utama Bazel itu sendiri. Fungsi ini utamanya dimaksudkan untuk digunakan oleh developer Bazel.

`--autodetect_server_javabase`

Opsi ini menyebabkan Bazel otomatis menelusuri JDK yang terinstal saat sistem dimulai, dan kembali ke JRE yang terinstal jika JRE tersemat 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, melainkan menjalankan proses java bazel untuk satu perintah, yang telah digunakan untuk semantik yang lebih dapat diprediksi terkait penanganan sinyal, kontrol tugas, dan pewarisan variabel lingkungan, serta diperlukan untuk menjalankan bazel dalam jail chroot.

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

Bazel akan berjalan lebih lambat dalam mode batch, atau dengan alternatif yang dijelaskan di atas. Ini karena, antara lain, cache file build adalah memori yang tersimpan, sehingga tidak dipertahankan di antara pemanggilan batch yang berurutan. Oleh karena itu, menggunakan mode batch sering kali lebih cocok jika performa tidak terlalu 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 bertahan tanpa batas.

Opsi ini dapat digunakan oleh skrip yang memanggil Bazel untuk memastikan bahwa skrip tersebut tidak meninggalkan proses server Bazel di komputer pengguna jika tidak akan berjalan jika tidak ada langkah. Misalnya, skrip pra-pengiriman mungkin ingin memanggil bazel query untuk memastikan bahwa perubahan yang tertunda milik pengguna tidak menimbulkan dependensi yang tidak diinginkan. Namun, jika pengguna belum melakukan build terbaru di ruang kerja tersebut, skrip pra-pengiriman tidak akan diinginkan untuk memulai server Bazel agar tetap tidak ada aktivitas sepanjang hari itu. Dengan menentukan nilai kecil --max_idle_secs dalam permintaan kueri, skrip dapat memastikan bahwa if menyebabkan server baru dimulai, server tersebut akan segera keluar. Namun, 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 ada aktivitas selama beberapa waktu, matikan server saat sistem kehabisan memori. 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 lainnya yang menahan kunci server agar selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan keluar secara error jika tidak dapat langsung mendapatkan kunci dan melanjutkan.

Developer dapat menggunakannya dalam pemeriksaan pra-pengiriman untuk menghindari waktu tunggu lama yang disebabkan oleh perintah Bazel lain di klien yang sama.

`--io_nice_level=n`

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

`--batch_cpu_scheduling`

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

Opsi lain

`--[no]announce_rc`

Mengontrol apakah Bazel akan 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 menyoroti output-nya 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 akan dinonaktifkan, terlepas dari apakah output menuju ke terminal atau tidak, dan terlepas dari setelan variabel lingkungan TERM.

`--config=name`

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

`--curses (yes|no|auto)`

Opsi ini menentukan apakah Bazel akan menggunakan kontrol kursor dalam output layarnya atau tidak. Ini menghasilkan data yang lebih sedikit yang dapat di-scroll, dan aliran output yang lebih ringkas dan mudah dibaca dari Bazel. Ini berfungsi 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 saat pesan ditampilkan.

Perintah dan Opsi

Sintaksis target

Opsi

Lokasi paket

--package_path

--deleted_packages

Pemeriksaan error

--[no]check_visibility

--output_filter=regex

Tanda alat

--copt=cc-option

--host_copt=cc-option

--host_conlyopt=cc-option

--host_cxxopt=cc-option

--host_linkopt=linker-option

--conlyopt=cc-option

--cxxopt=cc-option

--linkopt=linker-option

--strip (always|never|sometimes)

--stripopt=strip-option

--fdo_instrument=profile-output-dir

--fdo_optimize=profile-zip

--java_language_version=version

--tool_java_language_version=version

--java_runtime_version=version

--tool_java_runtime_version=version

--jvmopt=jvm-option

--javacopt=javac-option

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

Membangun semantik

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

--cpu=cpu

--action_env=VAR=VALUE

--experimental_action_listener=label

--[no]experimental_extra_action_top_level_only

--experimental_extra_action_filter=regex

--host_cpu=cpu

--android_platforms=platform[,platform]*

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

--dynamic_mode=mode

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

--force_ignore_dash_static

--[no]force_pic

--android_resource_shrinking

--custom_malloc=malloc-library-target

--crosstool_top=label

--host_crosstool_top=label

--apple_crosstool_top=label

--compiler=version

--android_sdk=label

--java_toolchain=label

--host_java_toolchain=label

--javabase=(label)

--host_javabase=label

Strategi eksekusi

--spawn_strategy=strategy

--strategy mnemonic=strategy

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

--genrule_strategy=strategy

--jobs=n (-j)

--progress_report_interval=n

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

--[no]build_runfile_links

--[no]build_runfile_manifests

--[no]discard_analysis_cache

--[no]keep_going (-k)

--[no]use_ijars

--[no]interface_shared_objects

Pilihan output

--[no]build

--[no]build_tests_only

--[no]check_up_to_date

--[no]compile_one_dependency

--save_temps

--build_tag_filters=tag[,tag]*

--test_size_filters=size[,size]*

--test_timeout_filters=timeout[,timeout]*

--test_tag_filters=tag[,tag]*

--test_lang_filters=string[,string]*

--test_filter=filter-expression

`--package_path`

`--deleted_packages`

`--[no]check_visibility`

`--output_filter=regex`

`--copt=cc-option`

`--host_copt=cc-option`

`--host_conlyopt=cc-option`

`--host_cxxopt=cc-option`

`--host_linkopt=linker-option`

`--conlyopt=cc-option`

`--cxxopt=cc-option`

`--linkopt=linker-option`

`--strip (always|never|sometimes)`

`--stripopt=strip-option`

`--fdo_instrument=profile-output-dir`

`--fdo_optimize=profile-zip`

`--java_language_version=version`

`--tool_java_language_version=version`

`--java_runtime_version=version`

`--tool_java_runtime_version=version`

`--jvmopt=jvm-option`

`--javacopt=javac-option`

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

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

`--cpu=cpu`

`--action_env=VAR=VALUE`

`--experimental_action_listener=label`

`--[no]experimental_extra_action_top_level_only`

`--experimental_extra_action_filter=regex`

`--host_cpu=cpu`

`--android_platforms=platform[,platform]*`

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

`--dynamic_mode=mode`

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

`--force_ignore_dash_static`

`--[no]force_pic`

`--android_resource_shrinking`

`--custom_malloc=malloc-library-target`

`--crosstool_top=label`

`--host_crosstool_top=label`

`--apple_crosstool_top=label`

`--compiler=version`

`--android_sdk=label`

`--java_toolchain=label`

`--host_java_toolchain=label`

`--javabase=(label)`

`--host_javabase=label`

`--spawn_strategy=strategy`

`--strategy mnemonic=strategy`

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

`--genrule_strategy=strategy`

`--jobs=n` (-j)

`--progress_report_interval=n`

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

`--[no]build_runfile_links`

`--[no]build_runfile_manifests`

`--[no]discard_analysis_cache`

`--[no]keep_going` (-k)

`--[no]use_ijars`

`--[no]interface_shared_objects`

`--[no]build`

`--[no]build_tests_only`

`--[no]check_up_to_date`

`--[no]compile_one_dependency`

`--save_temps`

`--build_tag_filters=tag[,tag]*`

`--test_size_filters=size[,size]*`

`--test_timeout_filters=timeout[,timeout]*`

`--test_tag_filters=tag[,tag]*`

`--test_lang_filters=string[,string]*`

`--test_filter=filter-expression`

`--explain=logfile`

`--verbose_explanations`

`--profile=file`

`--[no]show_loading_progress`

`--[no]show_progress`

`--show_progress_rate_limit=n`

`--show_result=n`

`--sandbox_debug`

`--subcommands` (`-s`)