BazelCon 2022 akan hadir pada 16-17 November ke New York dan online.
Daftar sekarang.

Perintah dan Opsi

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

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

Sintaksis target

Beberapa perintah, seperti build atau test, dapat beroperasi di daftar target. Label tersebut menggunakan sintaksis yang lebih fleksibel daripada label, yang didokumentasikan dalam Menentukan target yang akan di-build.

Opsi

Bagian berikut ini menjelaskan opsi yang tersedia selama 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 yang akan menang. Opsi yang dapat ditentukan beberapa kali diidentifikasi dalam bantuan online dengan teks 'dapat digunakan beberapa kali'.

Lokasi paket

--package_path

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

Bazel menemukan paketnya dengan menelusuri jalur paket. Ini adalah daftar direktori bazel yang diurutkan dengan titik dua, masing-masing menjadi root dari hierarki sumber parsial.

Untuk menentukan jalur paket kustom menggunakan opsi --package_path:

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

Elemen jalur paket dapat ditentukan dalam tiga format:

  1. Jika karakter pertama adalah /, jalurnya bersifat absolut.
  2. Jika jalur dimulai dengan %workspace%, jalur tersebut akan diambil relatif terhadap direktori bazel penutup terdekat. Misalnya, jika direktori kerja Anda adalah /home/bob/clients/bob_client/bazel/foo, string %workspace% dalam jalur paket akan diperluas ke /home/bob/clients/bob_client/bazel.
  3. Hal lain akan diambil sehubungan dengan direktori kerja. Ini biasanya tidak dimaksudkan untuk Anda lakukan, dan mungkin berperilaku secara tidak terduga jika Anda menggunakan Bazel dari direktori di bawah ruang kerja bazel. Misalnya, jika Anda menggunakan elemen jalur paket ., lalu melakukan cd ke dalam direktori /home/bob/clients/bob_client/bazel/foo, paket akan diselesaikan dari direktori /home/bob/clients/bob_client/bazel/foo Domain.

Jika Anda menggunakan jalur paket non-default, tentukan jalur tersebut dalam file konfigurasi Bazel agar lebih mudah.

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

Contoh: Membuat 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 dipertimbangkan oleh Bazel, dan tidak mencoba dimuat dari direktori apa pun di jalur paket. Ini dapat digunakan untuk menyimulasikan penghapusan paket tanpa benar-benar menghapusnya.

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 true, sehingga pemeriksaan visibilitas secara default 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 ditentukan dan eksekusinya berhasil, output standar dan error standarnya akan dihapus.

Berikut beberapa nilai umum untuk opsi ini:

`--output_filter='^//(pertama/project|detik/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_ANYThings` Tidak menampilkan apa pun.

Flag alat

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

--copt=cc-option

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

Opsi ini dapat digunakan beberapa kali. Contoh:

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

akan mengompilasi library foo tanpa tabel debug, sehingga menghasilkan kode yang tidak bergantung pada posisi.

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

--cxxopt=cc-option

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

Ini mirip dengan --copt, tetapi hanya berlaku untuk kompilasi C++, bukan untuk kompilasi C atau penautan. 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 untuk kompilasi. Jadi, Anda dapat meneruskan opsi compiler yang hanya masuk akal pada waktu penautan (seperti -lssp atau -Wl,--wrap,abort) menggunakan --linkopt. Contoh:

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

Aturan build juga dapat menentukan opsi link di atributnya. Setelan opsi ini selalu diutamakan. 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 dengan 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: hanya menghapus informasi proses debug. Jika karena alasan tertentu Anda ingin menghapus semua simbol, bukan hanya simbol debug, Anda harus menggunakan opsi --strip-all, yang Anda dapat dilakukan dengan meneruskan --linkopt=-Wl,--strip-all ke Bazel. Selain itu, perhatikan bahwa menetapkan tanda --strip Bazel akan menggantikan --linkopt=-Wl,--strip-all, sehingga Anda hanya perlu menetapkan salah satu tindakan tersebut.

Jika Anda hanya membuat satu biner dan ingin semua simbol dihilangkan, Anda juga dapat meneruskan --stripopt=--strip-all dan secara eksplisit mem-build versi //foo:bar.stripped target. Seperti yang dijelaskan di bagian --stripopt, ini akan 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. Nilai default-nya adalah -S -p. Opsi ini dapat digunakan beberapa kali.

--fdo_instrument=profile-output-dir

Opsi --fdo_instrument memungkinkan pembuatan output profil FDO (masukan yang diarahkan) saat biner C/C++ bawaan 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 dihasilkan, hierarki profil harus di-zip, dan disediakan ke opsi --fdo_optimize=profile-zip Bazel untuk mengaktifkan kompilasi yang dioptimalkan untuk 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 (pengoptimalan terarah masukan) FDO saat mengompilasi. Untuk GCC, argumen yang diberikan adalah file zip yang berisi hierarki file file .gcda yang dihasilkan sebelumnya yang berisi informasi profil untuk setiap file .o.

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

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

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

--[no]output_symbol_counts

Jika diaktifkan, setiap link yang dipanggil emas dari biner executable C++ akan menampilkan file jumlah simbol (melalui opsi emas --print-symbol-counts). Untuk setiap input linker, file mencatat jumlah simbol yang ditentukan dan jumlah simbol yang digunakan dalam biner. Informasi ini dapat digunakan untuk melacak dependensi link yang tidak diperlukan. File jumlah simbol ditulis ke jalur output biner dengan nama [targetname].sc.

Opsi ini dinonaktifkan secara default.

--java_language_version=version

Opsi ini menentukan versi sumber Java. Contoh:

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

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

--tool_java_language_version=version

Versi bahasa Java yang digunakan untuk membuat alat yang dijalankan selama proses build. Nilai defaultnya adalah 11.

--java_runtime_version=version

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

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

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

Nilai defaultnya adalah localjdk. Nilai yang memungkinkan adalah: localjdk, localjdk_version, remotejdk_11, dan remote_jdk17. Anda dapat memperluas nilai dengan mendaftarkan JVM kustom menggunakan aturan repositori local_java_repository atau remote_java_repostory.

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

akan membuat 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 setiap opsi yang menang Java. Opsi default untuk Java adalah:

  -source 8 -target 8 -encoding UTF-8
-extra_checks[:(off|on)]

Opsi javac ini memungkinkan pemeriksaan ketepatan tambahan. Masalah apa pun yang ditemukan akan ditampilkan sebagai error. -extra_checks atau -extra_checks:on dapat digunakan untuk memaksa pemeriksaan diaktifkan. -extra_checks:off sepenuhnya menonaktifkan analisis. Jika opsi ini tidak ditentukan, perilaku default akan digunakan.

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

Opsi ini mengontrol apakah javac memeriksa dependensi langsung yang tidak ada. Target Java harus secara eksplisit mendeklarasikan semua target yang digunakan secara langsung sebagai dependensi. Flag ini menginstruksikan javac untuk menentukan jar yang benar-benar digunakan untuk memeriksa jenis setiap file java, dan memperingatkan/error jika bukan merupakan output 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, sehingga menyebabkan target saat ini gagal di-build jika dependensi langsung yang hilang ditemukan. Ini juga merupakan perilaku default jika flag tidak ditentukan.

Membuat 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) memerlukan argumen fastbuild, dbg atau opt, dan memengaruhi berbagai C Opsi pembuatan kode/C++, seperti tingkat pengoptimalan dan kelengkapan tabel debug. Bazel menggunakan direktori output yang berbeda untuk setiap mode kompilasi yang berbeda, sehingga Anda dapat beralih antar-mode tanpa perlu melakukan build ulang penuh setiap kali.

  • fastbuild berarti membuat 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 dengan proses debug yang diaktifkan (-g), sehingga Anda dapat menggunakan gdb (atau debugger lain).
  • opt berarti build dengan pengoptimalan yang diaktifkan dan dengan panggilan assert() dinonaktifkan (-O2 -DNDEBUG). Informasi 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 berdasarkan nama, dalam hal ini nilai akan diambil dari lingkungan pemanggilan, atau dengan pasangan name=value yang menetapkan nilai secara independen dari lingkungan pemanggilan.

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

--experimental_action_listener=label

Opsi experimental_action_listener memerintahkan 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 guna menjadwalkan extra_actions.

Tanda ini hanya berlaku bersama tanda --experimental_action_listener.

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

Contoh berikut akan membatasi penjadwalan extra_actions agar hanya berlaku untuk tindakan yang labelnya 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 mem-build alat host.

--fat_apk_cpu=cpu[,cpu]*

CPU yang akan digunakan untuk mem-build library C/C++ dalam deps aturan android_binary transitif. Aturan C/C++ lainnya tidak terpengaruh. Misalnya, jika cc_library muncul dalam deps transitif dari aturan android_binary dan aturan cc_binary, cc_library akan dibuat setidaknya dua kali: satu kali untuk setiap CPU yang ditentukan dengan --fat_apk_cpu untuk aturan android_binary, dan sekali untuk CPU yang ditentukan dengan --cpu untuk aturan cc_binary.

Defaultnya adalah armeabi-v7a.

Satu file .so dibuat dan dikemas dalam APK untuk setiap CPU yang ditentukan dengan --fat_apk_cpu. Halaman.so nama file akan menjadi awalan nama fileandroid_binary menggunakan "lib". Misalnya, jika nama android_binary adalah "foo", maka nama filenya adalah libfoo.so.

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

Jika ada, setiap file C++ dengan label atau jalur eksekusi yang cocok dengan salah satu ekspresi ekspresi reguler penyertaan dan tidak cocok dengan ekspresi pengecualian apa 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++. Ini juga mencakup awalan dependen platform.

Untuk mencocokkan file yang dihasilkan (seperti output genrule) Bazel hanya dapat menggunakan jalur eksekusi. Dalam hal ini, regexp tidak boleh dimulai dengan '//' karena tidak cocok dengan jalur eksekusi apa pun. Nama paket dapat digunakan seperti ini: --per_file_copt=base/.*\.pb\.cc@-g0. Jenis ini akan cocok dengan setiap file .pb.cc dalam direktori yang disebut 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 menonaktifkan pengoptimalan.

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

Sintaks: [+-]regex[,[+-]regex]...@option[,option]... Di mana 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 ,, maka harus dikutip seperti \,. 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 dalam //foo/ kecuali file.cc.

--dynamic_mode=mode

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

Mode:

  • auto: Diterjemahkan ke mode yang bergantung pada platform; default untuk linux dan off untuk cygwin.
  • default: Memungkinkan bazel memilih apakah akan menautkan secara dinamis atau tidak. Lihat linkstatic untuk mengetahui informasi selengkapnya.
  • fully: Menautkan semua target secara dinamis. Hal ini akan mempercepat waktu penautan, dan mengurangi ukuran biner yang dihasilkan.
  • off: Menautkan semua target dalam sebagian besar statis. Jika -static disetel dalam linklink, target akan berubah menjadi sepenuhnya statis.

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

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

Jika ditetapkan ke [dbg][,opt][,fastbuild] (contoh: --fission=dbg,fastbuild), fisi diaktifkan hanya untuk kumpulan mode kompilasi yang ditentukan. Ini berguna untuk setelan bazelrc. Jika ditetapkan ke yes, Fisi diaktifkan secara universal. Jika ditetapkan ke no, Fisi dinonaktifkan secara universal. Nilai defaultnya adalah no.

--force_ignore_dash_static

Jika tanda ini ditetapkan, setiap opsi -static dalam link dari aturan cc_* file BUILD akan diabaikan. Hal ini hanya ditujukan sebagai solusi untuk build hardening C++.

--[no]force_pic

Jika diaktifkan, semua kompilasi C++ menghasilkan kode yang tidak bergantung posisi ("-fPIC"), link lebih memilih library bawaan PIC daripada library non-PIC, dan link menghasilkan eksekusi yang tidak bergantung posisi ("-pie") Domain . Default dinonaktifkan.

--android_resource_shrinking

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

--custom_malloc=malloc-library-target

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

--crosstool_top=label

Opsi ini menentukan lokasi suite compiler crosstool yang akan digunakan untuk semua kompilasi C++ selama proses build. Bazel akan mencari lokasi tersebut untuk file CROSS Tool 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 host, seperti alat yang berjalan selama proses build. Tujuan utama flag ini adalah mengaktifkan kompilasi silang.

--apple_crosstool_top=label

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

--android_crosstool_top=label

Crosstool yang akan digunakan untuk mengompilasi aturan C/C++ dalam deps android_binary aturan transitif. Ini berguna jika target lain dalam build memerlukan crosstool yang berbeda. Defaultnya adalah menggunakan crosstool yang dihasilkan oleh aturan android_ndk_repository dalam file WORKSPACE. Lihat juga --fat_apk_cpu.

--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 membuat build dengan alat silang kustom, Anda harus menggunakan file CROSS Tool, bukan menentukan flag ini.

--android_sdk=label

Opsi ini menentukan 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 menetapkan 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 host, seperti untuk alat yang dijalankan selama proses build. Tujuan utama flag ini adalah 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 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 host, misalnya untuk alat build host termasuk JavaBuilder dan Singlejar.

Tindakan ini tidak akan memilih compiler Java yang digunakan untuk mengompilasi file sumber Java. Compiler dapat dipilih dengan menetapkan opsi --java_toolchain.

Strategi eksekusi

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

--spawn_strategy=strategy

Opsi ini mengontrol tempat dan cara perintah dieksekusi.

  • standalone menyebabkan perintah dijalankan sebagai subproses lokal. Nilai ini sudah tidak digunakan lagi. Sebagai gantinya, gunakan local.
  • sandboxed menyebabkan perintah dieksekusi di dalam sandbox pada mesin lokal. 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 dengan sandbox.
  • local menyebabkan perintah dijalankan sebagai subproses lokal.
  • worker menyebabkan perintah dijalankan menggunakan pekerja persisten, jika tersedia.
  • docker menyebabkan perintah dieksekusi di dalam sandbox docker pada komputer lokal. Hal ini mengharuskan docker dipasang.
  • 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 eksekusi perintah, yang menggantikan --spawn_strategy (dan --genrule_strategy dengan Gnrule mnemonic) per -mnemonic. Lihat --spawn_strategy untuk strategi yang didukung dan efeknya.

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

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

regex_filter terakhir yang cocok dengan deskripsi akan digunakan. Opsi ini mengganti flag lainnya 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 //foo/bar.
  • Contoh: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed menjalankan 'Mengompilasi //foo/bar/baz' dengan strategi sandboxed, tetapi membalikkan pesanan akan menjalankannya dengan local.
  • Contoh: --strategy_regexp='Compiling.*/bar=local,sandboxed' menjalankan 'Mengompilasi //foo/bar/baz' dengan strategi local dan melakukan fallback ke sandboxed jika gagal.

--genrule_strategy=strategy

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

--jobs=n (-j)

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

--progress_report_interval=n

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

Defaultnya adalah 0, yang berarti algoritme inkremental: laporan pertama akan dicetak setelah 10 detik, lalu 30 detik, dan setelah progres tersebut dilaporkan sekali setiap menit.

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

Opsi ini menentukan jumlah resource lokal (RAM dalam MB dan jumlah inti logis CPU) yang dapat dipertimbangkan oleh Bazel saat menjadwalkan aktivitas build dan pengujian untuk dijalankan secara lokal. Nilai tersebut mengambil bilangan bulat, atau kata kunci (HOST_RAM atau HOST_CPUS) yang secara opsional 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 disetel. Secara default, Bazel memperkirakan jumlah RAM dan jumlah inti CPU langsung dari konfigurasi sistem lokal.

Opsi ini, yang diaktifkan secara default, menentukan apakah symlink runfiles 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 runfiles.

Saat pengujian (atau aplikasi) dijalankan, dependensi data runtime-nya dikumpulkan di satu tempat. Dalam struktur output Bazel, pohon "runfiles" ini biasanya di-root sebagai pasangan biner atau pengujian yang sesuai. Selama eksekusi uji, runfiles dapat diakses menggunakan jalur dalam format $TEST_SRCDIR/workspace/packagename/filename. Hierarki runfiles memastikan bahwa pengujian memiliki akses ke semua file yang memiliki dependensi yang dideklarasikan, dan tidak lebih. Secara default, hierarki runfiles diimplementasikan dengan membuat serangkaian link simbolis ke file yang diperlukan. Seiring bertambahnya kumpulan link, begitu pula biaya operasi ini, dan untuk beberapa build besar, link ini dapat berkontribusi secara signifikan terhadap waktu build keseluruhan, terutama karena setiap pengujian (atau aplikasi) memerlukan hierarki file.

--[no]build_runfile_manifests

Opsi ini, yang diaktifkan secara default, menentukan apakah manifes runfiles harus ditulis dalam hierarki output. Menonaktifkannya akan menyiratkan --nobuild_runfile_links.

Library ini dapat dinonaktifkan saat menjalankan pengujian dari jarak jauh karena hierarki runfiles akan dibuat dari jarak jauh dalam manifes dalam memori.

--[no]discard_analysis_cache

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

--[no]keep_going (- ribu)

Seperti di GNU Make, fase eksekusi build berhenti saat error pertama ditemukan. Terkadang ada baiknya mencoba membuat sebanyak mungkin bahkan dalam menghadapi error. Opsi ini akan mengaktifkan perilaku tersebut, dan jika ditentukan, build akan mencoba membuat 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 yang dapat dianalisis berhasil, build akan berhenti dengan error kecuali --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. Alih-alih menggunakan output java_library untuk mengompilasi target java_library dependen, Bazel akan membuat jar antarmuka yang hanya berisi tanda tangan anggota non-pribadi (publik, metode akses dan kolom yang dilindungi, dan (paket) default, serta menggunakan jars antarmuka untuk mengompilasi target dependen. Hal ini memungkinkan dari menghindari kompilasi ulang saat perubahan hanya dilakukan pada isi metode atau anggota pribadi class.

--[no]interface_shared_objects

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

Pemilihan output

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

--[no]build

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

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

--[no]build_tests_only

Jika ditentukan, Bazel hanya akan mem-build apa yang diperlukan untuk menjalankan aturan *_test dan test_suite yang tidak difilter karena ukurannya, 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 difilter 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 yang terbaru. Jika demikian, build akan berhasil diselesaikan seperti biasa. Namun, jika ada file yang habis masa berlakunya, bukan dibuat, error akan dilaporkan dan build gagal. Opsi ini mungkin berguna untuk menentukan apakah build 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 dependensi tunggal file argumen. Hal ini berguna untuk memeriksa file sumber sintaksis di IDE, misalnya dengan membuat ulang satu target yang bergantung pada file sumber untuk mendeteksi error sedini mungkin dalam siklus edit/build/pengujian. Argumen ini memengaruhi cara semua argumen non-tanda diinterpretasikan: setiap argumen harus berupa label target file atau nama file biasa yang relatif terhadap direktori kerja saat ini, dan satu aturan yang bergantung pada setiap nama file sumber dibuat. Untuk

C++ dan Java, aturan dalam ruang bahasa yang sama akan dipilih secara preferensial. Untuk beberapa aturan dengan preferensi yang sama, aturan yang muncul pertama kali dalam file BUILD 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 ini mencakup file .s (kode assembler), file .i (C yang diproses sebelumnya), dan .ii (C++ yang telah diproses sebelumnya). Output ini sering kali berguna untuk proses debug. Temp hanya akan dibuat untuk kumpulan target yang ditentukan pada command line.

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

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

--build_tag_filters=tag[,tag]*

Jika ditentukan, Bazel hanya akan membuat target yang memiliki setidaknya satu tag wajib (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 juga mungkin memiliki tanda '+' sebelumnya.

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

--test_size_filters=size[,size]*

Jika ditentukan, Bazel akan menguji (atau membuat 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), yang diawali dengan tanda '-' yang digunakan untuk menunjukkan ukuran pengujian yang dikecualikan. Misalnya,

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

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

Secara default, pemfilteran ukuran pengujian tidak diterapkan.

--test_timeout_filters=timeout[,timeout]*

Jika ditentukan, Bazel akan menguji (atau membuat jika --build_tests_only juga ditentukan) hanya menguji target dengan waktu tunggu yang ditentukan. Filter waktu tunggu pengujian ditetapkan sebagai daftar nilai waktu tunggu pengujian yang diizinkan dengan koma (singkat, moderat, panjang, atau abadi), secara opsional didahului dengan tanda '-' yang digunakan untuk menunjukkan waktu tunggu pengujian yang dikecualikan. Lihat --test_size_filter untuk mengetahui sintaksisnya.

Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.

--test_tag_filters=tag[,tag]*

Jika ditentukan, Bazel akan menguji (atau membuat jika --build_tests_only juga ditentukan) hanya menguji target yang memiliki setidaknya satu tag wajib (jika ada yang ditentukan) dan tidak memiliki tag yang dikecualikan. Filter tag pengujian ditetapkan sebagai daftar kata kunci tag yang dipisahkan koma, secara opsional didahului dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan juga mungkin 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 dengan 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=lang[,lang]*

Menentukan daftar bahasa pengujian yang dipisahkan koma untuk bahasa dengan aturan *_test resmi (lihat ensiklopedia build untuk mengetahui daftar lengkapnya). Setiap bahasa dapat secara opsional diawali dengan '-' untuk menentukan bahasa yang dikecualikan. Nama yang digunakan untuk setiap bahasa harus sama dengan awalan bahasa dalam aturan *_test, misalnya, cc, java, atau sh.

Jika ditentukan, Bazel akan menguji (atau membuat jika --build_tests_only juga ditentukan) hanya menguji target bahasa yang ditentukan.

Misalnya,

  % bazel test --test_lang_filters=cc,java foo/...

hanya akan menguji pengujian C/C++ dan Java (masing-masing ditentukan menggunakan aturan cc_test dan java_test) di foo/..., sedangkan

  % bazel test --test_lang_filters=-sh,-java foo/...

akan menjalankan semua pengujian di foo/... kecuali untuk pengujian sh_test dan java_test.

Secara default, pemfilteran bahasa pengujian tidak diterapkan.

--test_filter=filter-expression

Menentukan filter yang dapat digunakan oleh runner pengujian untuk memilih subset pengujian yang akan dijalankan. Semua target yang ditentukan dalam pemanggilan akan di-build, tetapi bergantung pada ekspresi, hanya beberapa target yang dapat dijalankan; Dalam beberapa kasus, hanya metode pengujian tertentu yang dijalankan.

Penafsiran filter-expression tertentu bergantung pada framework pengujian yang bertanggung jawab untuk menjalankan pengujian. Mungkin berupa glob, substring, atau regexp. --test_filter lebih praktis daripada meneruskan argumen filter --test_arg yang berbeda, tetapi tidak semua framework mendukungnya.

Panjang

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

--explain=logfile

Opsi ini, yang memerlukan argumen nama file, menyebabkan pemeriksa dependensi dalam fase eksekusi bazel build menjelaskan, untuk setiap langkah build, baik alasan dijalankan, atau itu sudah diperbarui. Penjelasan ditulis untuk logfile.

Jika Anda mengalami rebuild yang tidak terduga, opsi ini dapat membantu memahami alasannya. Tambahkan peristiwa tersebut ke .bazelrc agar logging terjadi untuk semua build berikutnya, lalu periksa log saat Anda melihat langkah eksekusi yang dieksekusi secara tidak terduga. Opsi ini dapat membawa penalti performa kecil, sehingga Anda mungkin ingin menghapusnya bila tidak diperlukan lagi.

--verbose_explanations

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

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

Menggunakan opsi ini dapat meningkatkan panjang secara signifikan file penjelasan yang dihasilkan dan penalti performa menggunakan --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 diuraikan menggunakan perintah bazel analyze-profile. Profil Build dapat berguna dalam memahami tempat perintah build Bazel menghabiskan waktunya.

--[no]show_loading_progress

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

--[no]show_progress

Opsi ini menyebabkan ditampilkannya pesan progres; fitur ini aktif secara default. Jika dinonaktifkan, pesan progres akan disembunyikan.

--show_progress_rate_limit=n

Opsi ini menyebabkan bazel hanya menampilkan satu pesan progres per n detik, dengan n berupa bilangan riil. Jika n -1, semua pesan progres akan ditampilkan. Nilai default untuk opsi ini adalah 0,02, yang berarti bazel akan membatasi pesan progres menjadi satu per setiap 0,02 detik.

--show_result=n

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

Meskipun informasi hasil mungkin berguna untuk build dari satu target atau beberapa target, untuk build besar (seperti seluruh hierarki project level teratas), informasi ini dapat membingungkan dan mengganggu; opsi ini memungkinkannya dikontrol. --show_result mengambil argumen bilangan bulat, yang merupakan jumlah target maksimum yang informasi cetak lengkapnya harus dicetak. Secara default, nilainya adalah 1. Di atas ambang batas ini, tidak ada informasi hasil yang ditampilkan untuk setiap target. Jadi, nol menyebabkan informasi hasil akan selalu disembunyikan, dan nilai yang sangat besar menyebabkan hasil akan selalu dicetak.

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

File tersebut dicetak agar memudahkan penyalinan dan penempelan nama file ke shell, untuk menjalankan file yang dapat dieksekusi yang telah dibuat. 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 menyimpan 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 Bourne yang kompatibel dengan shell, sehingga perintah tersebut dapat dengan mudah disalin dan ditempelkan ke command prompt shell. (Tanda kurung yang disertakan disediakan untuk melindungi shell Anda dari panggilan cd dan exec; pastikan untuk menyalinnya.) Namun, beberapa perintah diimplementasikan secara internal dalam Bazel, seperti membuat pohon symlink. Untuk baris ini, tidak ada command line untuk ditampilkan.

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

Lihat juga --verbose_Failures, di bawah.

Untuk mencatat subperintah ke file dalam format yang kompatibel dengan alat, lihat --Execution_log_json_file dan --execution_log_binary_file.

--verbose_failures

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

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

Status ruang kerja

Gunakan opsi ini untuk "cap" biner biner 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 mungkin dapat dijalankan. Di Windows, ini harus berupa biner native, biasanya file ".exe", ".bat", atau ".cmd".

Program ini harus mencetak nol atau beberapa key-value pair ke output standar, satu entri pada setiap baris, kemudian keluar dengan nol (jika tidak, build akan gagal). Nama kunci boleh 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). Baik kunci maupun nilai tidak boleh merentangkan beberapa baris. Kunci tidak boleh diduplikasi.

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

Bazel kemudian menulis key-value pair menjadi dua file:

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

Kontrak tersebut adalah:

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

    Bazel selalu menghasilkan kunci stabil berikut:

    • BUILD_EMBED_LABEL: nilai --embed_label
    • BUILD_HOST: nama mesin host yang menjalankan Bazel
    • BUILD_USER: nama pengguna yang menjalankan Bazel
  • Nilai kunci "volatil" dapat sering berubah. Bazel mengharapkan mereka untuk berubah setiap saat, seperti stempel waktu, dan memperbarui file bazel-out/volatile-status.txt. Namun, untuk menghindari pengoperasian ulang tindakan yang diberi stempel, Bazel berpura-pura bahwa file yang tidak stabil tidak pernah berubah. Dengan kata lain, jika file status volatil adalah satu-satunya file yang kontennya telah berubah, Bazel tidak akan membatalkan tindakan yang bergantung padanya. Jika input lain dari tindakan telah berubah, Bazel akan menjalankan kembali tindakan tersebut, dan tindakan tersebut akan melihat status volatil yang diperbarui, tetapi hanya perubahan status yang berubah-ubah 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)

Pada 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 ruang kerja 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 dan file status volatil akan menyertakan baris lainnya.

--[no]stamp

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

Stempel dapat diaktifkan atau dinonaktifkan secara eksplisit per aturan menggunakan atribut stamp. Lihat Build Encyclopedia untuk detailnya. Jika aturan ditetapkan ke stamp = -1 (default untuk aturan *_binary), opsi ini akan menentukan apakah stempel diaktifkan atau tidak.

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

Setelan --nostamp umumnya cocok untuk performa build, karena mengurangi volatilitas input dan memaksimalkan caching build.

Platform

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

Lihat informasi latar belakang tentang Platform dan Toolchain.

--platforms=labels

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

--host_platform=label

Label aturan platform yang menjelaskan sistem host.

--extra_execution_platforms=labels

Platform yang tersedia sebagai platform eksekusi untuk menjalankan tindakan. Platform dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Platform ini akan dipertimbangkan sebelum dideklarasikan dalam file WORKSPACE oleh register_Execution_platforms().

--extra_toolchains=labels

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

--toolchain_resolution_debug=regex

Mencetak informasi debug saat menemukan toolchain jika jenis toolchain cocok dengan ekspresi reguler. Beberapa ekspresi reguler dapat dipisahkan dengan koma. Regex dapat diabaikan dengan menggunakan - di awal. Hal ini dapat membantu developer aturan Bazel atau Starlark dengan kegagalan proses debug karena toolchain tidak ada.

Lain-lain

--flag_alias=alias_name=target_path

Flag praktis yang digunakan untuk mengikat setelan build Starlark menjadi lebih pendek. Untuk mengetahui detail lebih lanjut, lihat Konfigurasi Starlark.

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, ini memungkinkan Anda mem-build di direktori hanya baca atau yang tidak memiliki izin untuk Anda tulis. Setiap jalur yang dicetak dalam pesan informasi di akhir build hanya akan menggunakan bentuk singkat symlink-relatif 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> Domain. Gunakan opsi ini untuk sepenuhnya menahan pembuatan symlink.

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

--platform_suffix=string

Menambahkan akhiran ke nama pendek konfigurasi, yang digunakan untuk menentukan direktori output. Menetapkan opsi ini ke nilai yang berbeda akan menempatkan file ke direktori yang berbeda, misalnya untuk meningkatkan rasio cache ditemukan untuk build yang jika tidak saling mengganggu file output, atau untuk menyimpan file output untuk perbandingan.

--default_visibility=(private|public)

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

--[no]use_action_cache

Opsi ini diaktifkan secara default. Jika dinonaktifkan, Bazel tidak akan menggunakan cache tindakan lokalnya. Menonaktifkan cache tindakan lokal akan menghemat memori dan ruang disk untuk build bersih, tetapi akan membuat build inkremental lebih lambat.

--starlark_cpu_profile=_file_

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

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

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

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

Menggunakan Bazel untuk rilis

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

Opsi signifikan

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

Opsi ini juga penting:

  • --package_path
  • --symlink_prefix: untuk mengelola build bagi beberapa konfigurasi, sebaiknya bedakan 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 bersamaan, membuat semua target yang ditentukan (termasuk target non-pengujian yang ditentukan pada command line) dan menguji target *_test dan test_suite segera setelah prasyaratnya dibuat, artinya eksekusi pengujian disisipkan dengan build. Hal ini biasanya menghasilkan peningkatan kecepatan yang signifikan.

Opsi untuk bazel test

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

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

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

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

Jika 'yes', perilaku penyimpanan di cache akan sama dengan otomatis, tetapi mungkin akan men-cache kegagalan pengujian dan menjalankan pengujian dengan --runs_per_test.

Pengguna yang telah mengaktifkan opsi ini secara default di file .bazelrc dapat merasa singkatan -t (aktif) atau -t- (nonaktif) akan mudah untuk menggantikan setelan default di eksekusi tertentu.

--check_tests_up_to_date

Opsi ini memberi tahu Bazel untuk tidak menjalankan pengujian, tetapi untuk hanya memeriksa dan melaporkan hasil pengujian yang di-cache. Jika ada pengujian yang belum dibuat dan dijalankan sebelumnya, atau yang hasil pengujiannya sudah tidak berlaku (misalnya, karena kode sumber atau opsi build telah berubah), Bazel akan melaporkan pesan kesalahan ("hasil pengujian bukan yang terbaru"), akan mencatat status pengujian sebagai "TIDAK STATUS" (merah, jika keluaran warna diaktifkan), dan akan mengembalikan kode keluar 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 memperingatkan pengguna secara eksplisit jika waktu tunggu pengujian jauh lebih lama dari waktu eksekusi pengujian yang sebenarnya. Meskipun waktu tunggu pengujian harus ditetapkan sedemikian rupa agar tidak tidak stabil, 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 PANJANG karena keduanya sangat murah hati.

Opsi ini berguna untuk membantu pengguna menentukan nilai waktu tunggu yang baik atau kecerdasan yang 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-langkah build berikutnya dan pemanggilan pengujian tidak dijalankan, dan pemanggilan dalam penerbangan akan dibatalkan. Jangan tentukan --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 berhasil dilaporkan sebagai FLAKY pada ringkasan pengujian. Namun, hal ini dianggap lulus dalam mengidentifikasi kode keluar Bazel atau jumlah total pengujian yang lulus. Pengujian yang gagal dalam semua upaya yang diizinkan dianggap gagal.

Secara default (jika opsi ini tidak ditentukan, atau jika disetel ke default), hanya satu upaya yang diizinkan untuk pengujian reguler, dan 3 untuk aturan pengujian dengan kumpulan atribut flaky. Anda dapat menentukan nilai bilangan bulat untuk mengganti batas maksimum upaya pengujian. Bazel mengizinkan maksimum 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 diterapkan secara terpisah).

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

  • Jika tidak ada, operasi yang gagal dapat menyebabkan seluruh pengujian gagal.
  • Jika ada dan dua proses dari shard yang sama menampilkan HASIL dan GAGAL, pengujian akan menerima status tidak stabil (kecuali jika proses lain yang gagal menyebabkannya gagal).

Jika satu angka ditentukan, semua pengujian akan berjalan sebanyak itu. Atau, ekspresi reguler dapat ditentukan menggunakan ekspresi reguler@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/ 4 kali). Format --runs_per_test ini dapat ditentukan lebih dari sekali.

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

Menentukan bagaimana ringkasan hasil pengujian akan ditampilkan.

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

--test_output=output_style

Menentukan bagaimana output pengujian harus ditampilkan:

  • summary menunjukkan ringkasan apakah setiap pengujian lulus atau gagal. Juga menampilkan nama file log output untuk pengujian yang gagal. Ringkasan akan dicetak di akhir build (selama build, hanya akan ada 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 dalam stdout segera setelah pengujian selesai, untuk 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 pengujian Java menunggu koneksi dari debugger yang sesuai dengan JDWP 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, serta 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 dalam subdirektori terpisah di dalam direktori ini. Direktori akan dihapus pada awal setiap perintah bazel test. Secara default, bazel akan menempatkan direktori ini di bagian 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 ada satu nilai yang diberikan, nilai ini akan digunakan untuk semua kategori waktu tunggu pengujian.

Atau, empat nilai yang dipisahkan koma dapat diberikan, yang menentukan waktu tunggu individual untuk pengujian singkat, menengah, panjang, dan abadi (dalam urutan tersebut). Dalam kedua bentuk tersebut, nol atau nilai negatif untuk salah satu ukuran pengujian akan diganti dengan waktu tunggu default untuk kategori waktu tunggu yang ditentukan sebagaimana ditetapkan oleh halaman Menulis Pengujian. Secara default, Bazel akan menggunakan waktu tunggu ini untuk semua pengujian dengan menyimpulkan batas waktu tunggu dari ukuran pengujian, baik ukurannya ditetapkan secara implisit maupun eksplisit.

Pengujian yang secara eksplisit menyatakan kategori waktu tunggu sebagai berbeda dari ukurannya akan menerima nilai yang sama seperti jika waktu tunggu tersebut telah ditetapkan secara implisit oleh tag ukuran. Jadi, pengujian ukuran 'small' yang menyatakan waktu tunggu 'long' akan memiliki waktu tunggu efektif yang sama dengan yang dimiliki oleh pengujian 'large' tanpa waktu tunggu eksplisit.

--test_arg=arg

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

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

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

Lingkungan dapat diakses dari dalam pengujian dengan 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 beberapa kata menggunakan aturan tokenisasi shell Bourne, kemudian daftar kata ditambahkan ke perintah yang akan dijalankan.

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

Beberapa peringatan berlaku:

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

Contoh:

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

Pemilihan pengujian

Seperti yang didokumentasikan dalam 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 test runner.

Opsi lain untuk bazel test

Sintaksis dan opsi lainnya persis seperti bazel build.

Dapat dijalankan

Perintah bazel run mirip dengan bazel build, tetapi digunakan untuk mem-build dan menjalankan satu target. Berikut adalah sesi standar:

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

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

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

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.

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

Opsi untuk bazel run

--run_under=command-prefix

Ini memiliki efek yang sama dengan opsi --run_under untuk bazel test (lihat di atas), kecuali untuk perintah yang dijalankan oleh bazel run, bukan dibandingkan dengan pengujian yang dijalankan oleh bazel test dan tidak dapat berjalan di bawah label.

Memfilter output logging dari Bazel

Saat memanggil biner dengan bazel run, Bazel akan mencetak output logging dari Bazel itu sendiri dan biner yang sedang dipanggil. Agar log tidak terlalu bising, Anda dapat menyembunyikan output dari Bazel 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 perkiraan mendekati lingkungan yang dijelaskan di Menulis Pengujian. Perhatikan bahwa tidak ada argumen --test_* yang berpengaruh saat menjalankan pengujian dengan cara ini, kecuali --test_arg .

Membersihkan output build

Perintah clean

Bazel memiliki perintah clean, yang serupa dengan Make. 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.

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

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

  % bazel clean --expunge

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

Perintah clean disediakan terutama sebagai sarana untuk mengklaim ulang ruang disk untuk ruang kerja yang tidak lagi diperlukan. Build ulang inkremental Bazel mungkin tidak sempurna sehingga clean dapat digunakan untuk memulihkan status yang konsisten saat muncul masalah.

Desain Bazel sedemikian rupa sehingga masalah ini dapat diperbaiki dan bug ini adalah prioritas tinggi untuk diperbaiki. Jika Anda menemukan build inkremental yang salah, ajukan laporan bug, dan laporkan bug dalam alat tersebut, bukan menggunakan clean.

Membuat kueri grafik dependensi

Bazel menyertakan bahasa kueri untuk mengajukan pertanyaan tentang grafik dependensi yang digunakan selama proses build. Bahasa kueri digunakan oleh dua perintah: query dan cquery. Perbedaan utama antara kedua perintah tersebut adalah kueri dijalankan setelah fase pemuatan dan cquery berjalan setelah fase analisis. Alat-alat ini adalah bantuan yang sangat berharga untuk banyak tugas engineering software.

Bahasa kueri didasarkan pada ide operasi aljabar di atas grafik; ini didokumentasikan secara detail dalam

Referensi Kueri Bazel. Lihat dokumen tersebut sebagai referensi, misalnya, 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 setelah terjadi error; perilaku ini dapat dinonaktifkan jika hasil yang tidak lengkap tidak dapat diterima jika terjadi error.

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

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

Contoh: "Tampilkan lokasi definisi (di file BUILD) dari semua genrules yang diperlukan untuk mem-build 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. Model ini beroperasi pada grafik target yang dikonfigurasi setelah 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. Khususnya, perintah kueri berjalan di atas build Bazel reguler dan mewarisi kumpulan opsi yang tersedia selama build.

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 memberikan bantuan online. Secara default, diagram menunjukkan ringkasan perintah yang tersedia dan topik bantuan, seperti dalam Building with Bazel. Menetapkan 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 dengan menggunakan perintah shutdown. Perintah ini menyebabkan server Bazel keluar segera setelah tidak ada aktivitas (misalnya, setelah penyelesaian build atau perintah lainnya yang sedang berlangsung). Untuk detail selengkapnya, lihat Penerapan klien/server.

Server Bazel berhenti sendiri setelah waktu tunggu tidak ada aktivitas, sehingga perintah ini jarang diperlukan; Namun, metode ini dapat berguna dalam skrip saat diketahui bahwa tidak ada build lebih lanjut yang akan dilakukan di ruang kerja yang ditentukan.

shutdown menerima satu opsi, --iff_heap_size_greater_than _n_, yang memerlukan argumen bilangan bulat (dalam MB). Jika ditentukan, tindakan ini akan membuat penonaktifan berdasarkan jumlah memori yang sudah digunakan. Ini berguna untuk skrip yang memulai banyak build, karena setiap kebocoran memori di server Bazel dapat menyebabkan error secara sengaja pada peristiwa; melakukan mulai ulang bersyarat akan mendahului kondisi ini.

info

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

Perintah info juga mengizinkan 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 penggunaan pipeline hasil melalui sed -ne /key:/s/key://p:

Data yang tidak bergantung konfigurasi

  • release: label rilis untuk instance Bazel ini, atau "versi pengembangan" jika ini bukan biner rilis.
  • 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 executable internal yang diperlukan di bawah direktori ini.

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

  • execution_root: jalur absolut ke direktori utama eksekusi di bawah output_base. Direktori ini adalah root untuk semua file yang dapat diakses oleh perintah yang dijalankan selama proses build, dan merupakan direktori kerja untuk perintah-perintah tersebut. Jika direktori ruang kerja dapat ditulisi, symlink bernama bazel-<workspace> 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 ditulisi, symlink bernama bazel-out akan ditempatkan di sana dan menunjuk ke direktori ini.

  • server_pid: ID proses dari proses server Bazel.

  • server_log: jalur absolut ke file log debug server Bazel. File ini berisi informasi proses debug untuk semua perintah selama masa pakai server Bazel, dan ditujukan untuk konsumsi manusia oleh developer dan pengguna super Bazel.

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

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

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

  • package_path: Daftar jalur yang dipisahkan titik dua yang akan ditelusuri paket oleh bazel. Memiliki format yang sama seperti --package_path mem-build argumen command line.

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 biasanya tidak sama, symlink bazel-* ini dibuat di direktori ruang kerja dasar setelah build berhasil dilakukan. 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 mengasumsikan keberadaan symlink, akan lebih stabil.
  • Lingkungan"Make" lengkap. Jika flag --show_make_env ditentukan, semua variabel di lingkungan "Make" konfigurasi saat ini juga ditampilkan (seperti CC, GLIBC_VERSION, dll). Ini adalah variabel yang diakses menggunakan sintaks $(CC) atau varref("CC") 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 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 dibuat, termasuk daftar perubahan tempat build 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 rilis. Sangat berguna saat melaporkan bug.

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

mobile-install

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

Lihat instal seluler Bazel untuk informasi selengkapnya.

Opsi berikut ini didukung:

--incremental

Jika ditetapkan, Bazel mencoba menginstal aplikasi secara bertahap, yaitu, hanya bagian yang telah berubah sejak build terakhir. Tindakan ini tidak dapat mengupdate resource yang direferensikan dari AndroidManifest.xml, kode native, atau resource Java (misalnya yang direferensikan oleh Class.getResource()). Jika hal-hal ini berubah, opsi ini harus dihilangkan. Bertentangan dengan semangat Bazel dan karena keterbatasan platform Android, tanggung jawab pengguna adalah mengetahui kapan perintah ini cukup baik dan kapan pun penuh penginstalan diperlukan.

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

--split_apks

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

--start_app

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

--debug_app

Menunggu debugger dilampirkan sebelum memulai aplikasi dalam keadaan bersih setelah penginstalan. Setara dengan --start=DEBUG.

--start=_start_type_

Bagaimana aplikasi harus dimulai setelah menginstalnya. _start_type_s yang didukung:

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

--adb=path

Menunjukkan biner adb yang akan digunakan.

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

--adb_arg=serial

Argumen tambahan untuk adb. Hal ini terjadi sebelum sub-perintah 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. Setel ke 1 untuk logging debug yang akan dicetak ke konsol.

dump

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

Secara default, perintah hanya akan mencetak pesan bantuan yang menjelaskan 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 membuang konten cache paket.
  • --skyframe membuang status grafik dependensi Bazel internal.
  • --rules membuang ringkasan aturan untuk setiap aturan dan class aspek, termasuk jumlah dan jumlah tindakan. Ini termasuk aturan native dan Starlark. Jika pelacakan memori diaktifkan, konsumsi memori aturan juga akan dicetak.
  • --skylark_memory membuang file .gz yang kompatibel dengan pprof ke jalur yang ditetapkan. Anda harus mengaktifkan pelacakan memori agar fitur ini dapat 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

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

Jangan lupa untuk meneruskan opsi ini ke Bazel untuk setiap perintah; jika tidak, 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 data yang sebelumnya dikumpulkan selama build menggunakan opsi --profile. Ini memberikan beberapa opsi untuk menjalankan analisis eksekusi build atau mengekspor data dalam format yang ditentukan.

Opsi berikut ini didukung:

  • --dump menampilkan semua data yang dikumpulkan dalam format yang dapat dibaca manusia. Namun, ini belum mendukung format lain.

Untuk mengetahui detail format dan bantuan penggunaan, baca Memecahkan masalah performa dengan membuat profil.

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 dikanonikalisasi ke daftar baru yang sama.

Opsi --for_command dapat digunakan untuk memilih di antara perintah yang berbeda. Saat ini, hanya build dan test yang didukung. Opsi yang tidak didukung oleh perintah yang diberikan 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 dalam 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 sintaks --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 tersebut.

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

--output_user_root=dir

Mengarah ke direktori utama tempat output dan penginstalan basis dibuat. Direktori tidak boleh ada atau dimiliki oleh pengguna yang menelepon. Sebelumnya, kode ini diizinkan untuk mengarah ke direktori yang dibagikan ke berbagai pengguna tetapi tidak diizinkan lagi. Ini dapat diizinkan setelah masalah #11100 diatasi.

Jika opsi --output_base ditentukan, maka akan diganti menggunakan --output_user_root untuk menghitung basis output.

Lokasi dasar penginstalan dihitung berdasarkan --output_user_root, ditambah identitas MD5 biner biner Bazel.

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

--server_javabase=dir

Menentukan mesin virtual Java tempat Bazel itu sendiri berjalan. Nilainya harus berupa jalur ke direktori yang berisi JDK atau JRE. Tidak boleh berupa label. Opsi ini akan muncul sebelum perintah Bazel, 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.

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

--host_jvm_args=string

Menentukan opsi startup yang akan diteruskan ke mesin virtual Java tempat Bazel dijalankan. Ini dapat digunakan untuk menyetel ukuran tumpukan, misalnya:

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

Opsi ini dapat digunakan beberapa kali dengan masing-masing argumen. Perhatikan bahwa penanganan tanda ini jarang diperlukan. Anda juga dapat meneruskan daftar string yang dipisahkan spasi, yang masing-masing akan diinterpretasikan sebagai argumen JVM terpisah, tetapi fitur ini akan segera tidak digunakan lagi.

Bahwa ini tidak memengaruhi JVM yang digunakan oleh subproses Bazel: aplikasi, pengujian, alat, dan sebagainya. Untuk meneruskan opsi JVM ke program Java yang dapat dijalankan, baik dijalankan oleh bazel run atau pada command line, Anda harus menggunakan argumen --jvm_flags yang semuanya 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 diinstal saat startup, dan kembali ke JRE yang diinstal 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, tetapi menjalankan proses java bazel untuk satu perintah, yang telah digunakan untuk semantik yang lebih dapat diprediksi sehubungan dengan penanganan sinyal, kontrol tugas, dan turunan variabel lingkungan, dan diperlukan untuk menjalankan bazel di jail jail.

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

Bazel akan berjalan lebih lambat dalam mode batch, atau dengan alternatif yang dijelaskan di atas. Hal ini karena, di antara hal lainnya, cache file build adalah memori-penduduk, sehingga tidak disimpan di antara pemanggilan batch yang berurutan. Oleh karena itu, penggunaan mode batch sering kali lebih logis jika performa kurang penting, seperti build berkelanjutan.

--max_idle_secs=n

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

Opsi ini dapat digunakan oleh skrip yang memanggil Bazel untuk memastikan bahwa skrip tersebut tidak meninggalkan proses server Bazel di mesin pengguna saat tidak berjalan. Misalnya, skrip pra-pengiriman mungkin ingin memanggil bazel query untuk memastikan bahwa perubahan tertunda 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 selama sisa hari itu. Dengan menentukan nilai --max_idle_secs kecil dalam permintaan kueri, skrip dapat memastikan bahwa jika server baru dimulai, server akan segera keluar, tetapi jika jika sudah ada server yang berjalan, server tersebut akan terus berjalan hingga tidak ada aktivitas selama biasanya. Tentu saja, timer nonaktif 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 memori rendah. Khusus Linux.

Selain menjalankan pemeriksaan tidak ada aktivitas yang terkait 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 hampir habis, server akan keluar.

--[no]block_for_lock

Jika diaktifkan, Bazel akan menunggu perintah Bazel lainnya yang menahan kunci server selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan error karena error jika tidak dapat segera memperoleh kunci dan melanjutkan.

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

--io_nice_level=n

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

--batch_cpu_scheduling

Gunakan penjadwalan CPU batch untuk Bazel. Kebijakan ini berguna untuk beban kerja noninteraktif, tetapi tidak ingin menurunkan nilainya yang bagus. Lihat 'man 2 sced_setscheduler'. Kebijakan ini dapat memberikan interaktivitas sistem yang lebih baik dengan mengorbankan throughput Bazel.

Opsi lain-lain

--[no]announce_rc

Mengontrol apakah Bazel mengumumkan opsi perintah yang dibaca dari file bazelrc saat memulai. (Opsi startup diumumkan tanpa syarat.)

--color (yes|no|auto)

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

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

--config=name

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

--curses (yes|no|auto)

Opsi ini menentukan apakah Bazel akan menggunakan kontrol kursor dalam output layarnya. Metode ini akan menghasilkan data scroll yang lebih sedikit, dan aliran output dari Bazel yang lebih ringkas dan mudah dibaca. 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 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 ditambahkan ke setiap pesan yang dihasilkan oleh Bazel, yang menentukan waktu saat pesan ditampilkan.