Perintah dan Opsi

Laporkan masalah Lihat sumber Per malam · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

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

Sintaksis target

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

Opsi

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

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

Lokasi paket

--package_path

PERINGATAN: Opsi --package_path tidak digunakan lagi. Bazel lebih menyukai paket di repositori utama agar berada di bawah root workspace.

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 dan dipisahkan titik dua, yang masing-masing merupakan 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 /, jalur tersebut bersifat absolut.
2. Jika jalur dimulai dengan %workspace%, jalur akan diambil secara relatif ke direktori {i>bazel<i} yang berdekatan. Misalnya, jika direktori kerja Anda adalah /home/bob/clients/bob_client/bazel/foo, string %workspace% di jalur paket akan diperluas ke /home/bob/clients/bob_client/bazel.
3. Semua yang lain diambil relatif terhadap direktori kerja. Biasanya ini bukanlah yang Anda maksud, dan mungkin berperilaku tidak terduga jika Anda menggunakan Bazel dari direktori di bawah ruang kerja bazel. Misalnya, jika Anda menggunakan elemen jalur paket ., lalu cd ke direktori /home/bob/clients/bob_client/bazel/foo, paket akan di-resolve dari direktori /home/bob/clients/bob_client/bazel/foo.

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

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

Contoh: Membangun dari klien kosong

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

--deleted_packages

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

Terjadi error saat memeriksa

Opsi ini mengontrol pemeriksaan error dan/atau peringatan Bazel.

--[no]check_visibility

Jika opsi ini ditetapkan ke salah (false), pemeriksaan visibilitas akan diturunkan menjadi peringatan. Nilai default opsi ini adalah true, sehingga secara default, pemeriksaan visibilitas dilakukan.

--output_filter=regex

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

Berikut beberapa nilai standar untuk opsi ini:

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

Flag alat

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

--copt=cc-option

Opsi ini menggunakan argumen yang akan diteruskan ke compiler. Argumen akan diteruskan ke compiler setiap kali dipanggil untuk prapemrosesan, mengompilasi, dan/atau menyusun C, C++, atau kode assembler. ID ini tidak akan diteruskan saat ditautkan.

Opsi ini dapat digunakan beberapa kali. Contoh:

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

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

Catatan: Mengubah setelan --copt akan memaksa kompilasi ulang dari semua file objek yang terpengaruh. Perhatikan juga bahwa kopt yang tercantum dalam Aturan build cc_library atau cc_binary akan ditempatkan di command line compiler setelah opsi ini.

Peringatan: Opsi khusus C++ (seperti -fno-implicit-templates) harus ditentukan dalam --cxxopt, bukan dalam --copt. Demikian pula, opsi khusus C (seperti -Wstrict-prototypes) harus ditentukan di --conlyopt, bukan di copt. Demikian pula, opsi compiler yang hanya memiliki pada waktu penautan (seperti -l) harus ditentukan di --linkopt, tidak di --copt.

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

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

--host_linkopt=linker-option

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

--conlyopt=cc-option

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

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

Catatan: menggunakan parameter yang tercantum dalam aturan build cc_library atau cc_binary tertentu ditempatkan di command line compiler setelah opsi ini.

--cxxopt=cc-option

Opsi ini mengambil argumen yang akan diteruskan ke kompiler ketika mengompilasi file sumber C++.

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

Contoh:

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

Catatan: memilih parameter yang tercantum dalam aturan build cc_library atau cc_binary tertentu ditempatkan pada command line compiler setelah opsi ini.

--linkopt=linker-option

Opsi ini menggunakan argumen yang akan diteruskan ke compiler saat penautan.

Hal ini mirip dengan --copt, tetapi hanya berlaku untuk penautan, bukan ke 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 penaut 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 sekaligus menghapus informasi proses debug dari semua biner yang dihasilkan.

Catatan: Jika Anda menginginkan informasi proses debug, menonaktifkan penghapusan tidak cukup; Anda juga harus memastikan bahwa informasi proses debug dihasilkan oleh compiler, yang dapat Anda lakukan dengan menggunakan -c dbg atau --copt -g.

Opsi --strip Bazel sesuai dengan opsi --strip-debug ld: perintah itu hanya menghilangkan informasi {i>debugging<i}. Jika karena alasan tertentu Anda ingin menghilangkan semua simbol, tidak hanya simbol debug, Anda harus menggunakan opsi --strip-all ld, yang dapat Anda lakukan dengan meneruskan --linkopt=-Wl,--strip-all ke Bazel. Juga menjadi perlu diketahui bahwa menyetel flag --strip Bazel akan mengganti --linkopt=-Wl,--strip-all, jadi sebaiknya hanya tetapkan salah satunya.

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

--stripopt=strip-option

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

Catatan: --stripopt tidak berlaku untuk penghapusan biner utama dengan [--strip](#flag--strip)=(always|sometimes).

--fdo_instrument=profile-output-dir

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

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

Untuk compiler LLVM, argumennya juga merupakan direktori tempat profil LLVM mentah file data 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 FDO (umpan balik pengoptimalan terarah) saat mengompilasi. Untuk GCC, argumen yang diberikan adalah file zip yang berisi hierarki file file .gcda yang dibuat sebelumnya yang berisi informasi profil untuk setiap file .o.

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

Catatan: Opsi ini juga menerima label yang me-resolve ke file sumber. Anda mungkin perlu menambahkan perintah exports_files ke paket yang sesuai untuk membuat file tersebut terlihat oleh Bazel.

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

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

--java_language_version=version

Opsi ini menentukan versi sumber Java. Contoh:

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

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

--tool_java_language_version=version

Versi bahasa Java yang digunakan untuk membangun alat yang dijalankan selama pembangunan. Nilai defaultnya adalah 8.

--java_runtime_version=version

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

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

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

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

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

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

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

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

--javacopt=javac-option

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

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

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

Opsi diteruskan ke javac setelah opsi {i>default<i} bawaan Bazel untuk javac dan sebelum opsi per aturan. Spesifikasi terakhir opsi apa pun untuk javac akan menang. Opsi default untuk javac adalah:

  -source 8 -target 8 -encoding UTF-8

Catatan: Mengubah setelan --javacopt akan memaksa kompilasi ulang dari semua kelas yang terpengaruh. Perhatikan juga bahwa parameter javacopts yang tercantum dalam aturan build java_library atau java_binary tertentu akan ditempatkan di command line javac setelah opsi ini.

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

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

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

Membangun semantik

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

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

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

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

--cpu=cpu

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

Catatan: Kombinasi tertentu dari versi crosstool, versi compiler, dan CPU target hanya diizinkan jika telah ditentukan dalam file CROSSTOOL yang saat ini digunakan.

--action_env=VAR=VALUE

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

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

--experimental_action_listener=label

Peringatan: Tindakan tambahan tidak digunakan lagi. Sebagai gantinya, gunakan aspek.

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

--[no]experimental_extra_action_top_level_only

Peringatan: Tindakan tambahan tidak digunakan lagi. Gunakan aspek.

Jika opsi ini disetel ke benar (true), tindakan tambahan akan ditentukan oleh Perintah --experimental_action_listener hanya akan dijadwalkan untuk target tingkat atas.

--experimental_extra_action_filter=regex

Peringatan: Tindakan tambahan tidak digunakan lagi. Gunakan aspek.

Opsi experimental_extra_action_filter menginstruksikan Bazel untuk filter kumpulan target untuk menjadwalkan extra_actions.

Tanda ini hanya berlaku jika digunakan bersama Flag --experimental_action_listener.

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

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

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

--host_cpu=cpu

Opsi ini menentukan nama arsitektur CPU yang harus digunakan untuk mem-build alat host.

--android_platforms=platform[,platform]*

Platform untuk membangun deps transitif dari Aturan android_binary (khusus untuk dependensi native seperti C++). Sebagai contoh, jika cc_library muncul dalam deps transitif dari android_binary, dibuat sekali untuk setiap platform yang ditentukan dengan --android_platforms untuk aturan android_binary, dan disertakan dalam {i>output<i} tersebut.

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

Satu file .so dibuat dan dikemas dalam APK untuk setiap platform yang ditentukan dengan --android_platforms. Nama file .so memberi awalan pada nama aturan android_binary dengan "lib". Misalnya, jika nama android_binary adalah "foo", maka 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 regex penyertaan dan tidak cocok dengan ekspresi pengecualian apa pun akan di-build dengan opsi yang diberikan. Pencocokan label menggunakan bentuk kanonis label (yaitu //package:label_name).

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

Catatan: Jika hanya satu label atau jalur eksekusi yang cocok, opsi yang akan digunakan.

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

Opsi ini dapat digunakan beberapa kali.

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

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

Sintaksis: [+-]regex[,[+-]regex]...@option[,option]... Tempat regex adalah singkatan dari ekspresi reguler yang dapat diawali dengan + untuk mengidentifikasi pola penyertaan, dan - untuk mengidentifikasi mengecualikan pola. option adalah singkatan dari opsi arbitrer yang diteruskan ke compiler C++. Jika opsi berisi ,, opsi tersebut harus dikutip seperti itu \,. Opsi juga dapat berisi @, karena hanya yang pertama @ digunakan untuk memisahkan ekspresi reguler dari opsi.

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

--dynamic_mode=mode

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

Mode:

• default: Memungkinkan Bazel memilih apakah akan menautkan secara dinamis atau tidak. Lihat linkstatic untuk mengetahui informasi selengkapnya.
• fully: Menautkan semua target secara dinamis. Tindakan ini akan mempercepat waktu penautan, dan mengurangi ukuran biner yang dihasilkan.
• off: Menautkan semua target di mode sebagian besar statis. Jika -static ditetapkan di linkopt, 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, tempat file tersebut akan ditempatkan. Hal ini secara substansial mengurangi ukuran input ke link dan dapat mengurangi waktu link.

Jika ditetapkan ke [dbg][,opt][,fastbuild] (contoh: --fission=dbg,fastbuild), Fisi diaktifkan hanya untuk set mode kompilasi yang ditentukan. Ini berguna untuk {i>bazelrc<i} setelan. Jika ditetapkan ke yes, Fission akan diaktifkan secara universal. Jika ditetapkan ke no, Fission akan dinonaktifkan secara universal. Defaultnya adalah no.

--force_ignore_dash_static

Jika flag ini disetel, opsi -static apa pun di penautan File BUILD aturan cc_* diabaikan. Hal ini hanya dimaksudkan sebagai untuk build hardening C++.

--[no]force_pic

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

Catatan: Biner yang ditautkan secara dinamis (misalnya --dynamic_mode fully) akan menghasilkan kode PIC, terlepas dari setelan tanda ini. Penanda ini digunakan untuk kasus jika pengguna menginginkan kode PIC yang dibuat secara eksplisit untuk link statis.

--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 guna mengetahui detail lebih lanjut. Setelan defaultnya adalah nonaktif.

--custom_malloc=malloc-library-target

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

--crosstool_top=label

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

--host_crosstool_top=label

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

--apple_crosstool_top=label

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

--compiler=version

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

Catatan: Hanya kombinasi tertentu dari versi crosstool, versi compiler, dan CPU target yang diizinkan.

--android_sdk=label

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

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

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

--java_toolchain=label

Tanpa pengoperasian. Hanya untuk kompatibilitas mundur.

--host_java_toolchain=label

Tidak ada operasi. Hanya dipertahankan untuk kompatibilitas mundur.

--javabase=(label)

Tidak ada operasi. Hanya dipertahankan untuk kompatibilitas mundur.

--host_javabase=label

Tidak ada operasi. Hanya dipertahankan untuk kompatibilitas mundur.

Strategi eksekusi

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

--spawn_strategy=strategy

Opsi ini mengontrol tempat dan cara perintah dieksekusi.

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

--strategy mnemonic=strategy

Opsi ini mengontrol di mana dan bagaimana perintah dieksekusi, menggantikan --spawn_strategy (dan --genrule_strategy dengan mnemonik Genrule) berdasarkan per-mnemonik. 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 cocok dengan regex_filter tertentu. Lihat --per_file_copt untuk mengetahui detail tentang pencocokan regex_filter. Lihat --spawn_strategy untuk platform yang didukung strategi dan efeknya.

regex_filter terakhir yang cocok dengan deskripsi digunakan. Opsi ini mengganti penanda lain untuk menentukan strategi.

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

--genrule_strategy=strategy

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

--jobs=n (-j)

Opsi ini, yang menggunakan argumen integer, menentukan batas jumlah tugas yang harus dieksekusi secara serentak selama fase eksekusi build.

Catatan: Jumlah tugas serentak yang akan dijalankan Bazel tidak hanya ditentukan oleh setelan --jobs, tetapi juga oleh penjadwal Bazel, yang mencoba menghindari menjalankan tugas serentak yang akan menggunakan lebih banyak resource (RAM atau CPU) daripada yang tersedia, berdasarkan beberapa estimasi (sangat kasar) konsumsi resource dari setiap tugas. Perilaku penjadwal dapat dikontrol oleh opsi --local_ram_resources.

--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, artinya algoritma inkremental: yang pertama laporan akan dicetak setelah 10 detik, lalu 30 detik dan setelah kemajuan tersebut dilaporkan sekali setiap menit.

Bila bazel menggunakan kontrol kursor, sebagaimana ditentukan oleh --curses, progres dilaporkan setiap detik.

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

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

--[no]build_runfile_links

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

Ketika pengujian (atau aplikasi) dijalankan, data runtime-nya dependensi dikumpulkan di satu tempat. Dalam hierarki output Bazel, hierarki "runfiles" ini biasanya di-root sebagai saudara dari biner atau pengujian yang sesuai. Selama eksekusi pengujian, runfile dapat diakses menggunakan jalur dalam bentuk $TEST_SRCDIR/canonical_repo_name/packagename/filename. Hierarki runfiles memastikan bahwa pengujian memiliki akses ke semua file di mana mereka memiliki ketergantungan yang nyata, tidak lebih dari itu. Menurut {i>default<i}, pohon {i>runfiles<i} diimplementasikan dengan membuat serangkaian tautan simbolis ke file yang dibutuhkan. Seiring bertambahnya kumpulan link, begitu pula biaya operasi ini, dan untuk beberapa build besar, hal ini dapat berkontribusi secara signifikan terhadap waktu build secara keseluruhan, terutama karena setiap pengujian (atau aplikasi) memerlukan hierarki runfile-nya sendiri.

--[no]build_runfile_manifests

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

Hal ini dapat dinonaktifkan ketika menjalankan pengujian dari jarak jauh, karena pohon runfiles akan dibuat secara jarak jauh dari manifes dalam memori.

--[no]discard_analysis_cache

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

--[no]keep_going (-k)

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

Sementara opsi ini biasanya dikaitkan dengan fase eksekusi build, hal itu juga mempengaruhi fase analisis: jika beberapa target ditentukan dalam perintah {i>build<i}, tetapi hanya beberapa yang bisa berhasil dianalisis, build akan berhenti dengan error kecuali jika --keep_going ditentukan, dalam hal ini build akan dilanjutkan ke fase eksekusi, tetapi hanya untuk target yang berhasil dianalisis.

--[no]use_ijars

Opsi ini mengubah cara target java_library dikompilasi oleh Bazel. Daripada menggunakan output java_library untuk mengompilasi target java_library dependen, Bazel akan membuat jar antarmuka yang hanya berisi tanda tangan anggota non-pribadi (metode dan kolom akses publik, dilindungi, dan default (paket)) dan menggunakan jar antarmuka untuk mengompilasi target dependen. Hal ini membuatnya mungkin untuk menghindari rekompilasi ketika perubahan hanya dilakukan pada isi metode atau anggota pribadi class.

Catatan: Menggunakan --use_ijars mungkin akan memberikan pesan error saat Anda secara tidak sengaja merujuk ke file yang tidak terlihat anggota kelas lain: Alih-alih menampilkan pesan error tidak terlihat, Anda akan mendapatkan pesan {i>error<i} bahwa anggota tersebut tidak ada. Mengubah setelan --use_ijars akan memaksa kompilasi ulang semua item yang terpengaruh class.

--[no]interface_shared_objects

Opsi ini mengaktifkan antarmuka objek bersama, yang membuat biner dan library bersama lainnya bergantung pada antarmuka objek bersama, dan bukan implementasinya. Ketika hanya implementasi yang berubah, Bazel dapat menghindari membangun ulang target yang bergantung pada pustaka bersama yang diubah jika tidak diperlukan.

Pilihan output

Opsi ini menentukan apa yang akan dibangun atau diuji.

--[no]build

Opsi ini menyebabkan fase eksekusi build terjadi; ini aktif secara default. Jika dinonaktifkan, fase eksekusi akan dilewatkan, dan hanya dua fase pertama, pemuatan dan analisis, yang 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 membangun apa yang diperlukan untuk menjalankan *_test dan test_suite aturan yang tidak difilter karena size (ukuran), waktu tunggu, tag, atau bahasa. Jika ditentukan, Bazel akan mengabaikan target lain yang ditentukan pada command line. Secara {i>default<i}, opsi ini dinonaktifkan dan Bazel akan membangun semuanya 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 build kerusakan di hierarki foo.

--[no]check_up_to_date

Opsi ini menyebabkan Bazel tidak melakukan build, tetapi hanya memeriksa apakah semua target yang ditentukan sudah yang terbaru. Jika ya, build berhasil diselesaikan, seperti biasa. Namun, jika ada file yang sudah tidak aktual, error akan dilaporkan dan build akan gagal, bukan di-build. Opsi ini berguna untuk menentukan apakah build memiliki dilakukan lebih baru daripada pengeditan sumber (misalnya, untuk pra-pengiriman check) tanpa menimbulkan biaya build.

Lihat juga --check_tests_up_to_date.

--[no]compile_one_dependency

Mengompilasi satu dependensi file argumen. Hal ini berguna untuk memeriksa sintaksis file sumber di IDE, misalnya, dengan mem-build 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-flag ditafsirkan: setiap argumen harus berupa label target file atau nama file biasa yang relatif terhadap direktori kerja saat ini, dan satu aturan yang bergantung pada setiap nama file sumber akan dibuat. Untuk sumber C++ dan Java, aturan dalam ruang bahasa yang sama akan dipilih secara preferensial. Sebagai beberapa aturan dengan preferensi yang sama, aturan yang akan muncul pertama kali File BUILD dipilih. Pola target yang dinamai secara eksplisit dan tidak mereferensikan file sumber akan menyebabkan error.

--save_temps

Opsi --save_temps menyebabkan output sementara dari compiler menjadi disimpan. File ini mencakup file .s (kode assembler), .i (C yang diproses sebelumnya), dan file .ii (C++ yang diproses sebelumnya). Output ini sering kali berguna untuk proses debug. Suhu hanya akan yang dihasilkan untuk serangkaian target yang ditentukan pada baris perintah.

Catatan: Implementasi --save_temps tidak menggunakan -save-temps. Sebagai gantinya, ada dua kartu, satu dengan -S dan satu dengan -E. Konsekuensinya adalah jika build Anda gagal, Bazel mungkin belum menghasilkan file ".i" atau ".ii" dan ".s". Jika Anda mencoba menggunakan --save_temps untuk men-debug kompilasi yang gagal, Anda mungkin juga perlu menggunakan --keep_going agar Bazel tetap mencoba membuat file yang telah diproses sebelumnya setelah kompilasi gagal.

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

Untuk memastikan bahwa Bazel bisa mencetak lokasi file {i>output<i} tambahan, pastikan --show_result n Anda sudah cukup tinggi.

--build_tag_filters=tag[,tag]*

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

Saat menjalankan pengujian, Bazel mengabaikan --build_tag_filters untuk target pengujian, yang dibuat dan dijalankan meskipun mereka tidak sesuai 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 hanya akan menguji (atau mem-build jika --build_tests_only juga ditentukan) target pengujian dengan ukuran yang ditentukan. Uji filter ukuran ditetapkan sebagai daftar yang dibatasi koma dari nilai ukuran pengujian yang diizinkan (kecil, sedang, besar, atau sangat besar), serta boleh diawali dengan '-' tanda yang digunakan untuk menunjukkan dan 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 membangun jika --build_tests_only ditentukan) hanya target pengujian dengan waktu tunggu yang diberikan. Uji filter waktu tunggu ditetapkan sebagai daftar nilai batas waktu pengujian yang dibatasi koma (singkat, sedang, panjang, atau abadi), dapat juga diawali dengan '-' tanda yang digunakan untuk menunjukkan waktu tunggu pengujian yang dikecualikan. Lihat --test_size_filters untuk contoh sintaksis.

Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.

--test_tag_filters=tag[,tag]*

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

Misalnya,

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

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

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

--test_lang_filters=string[,string]*

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

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

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

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

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

Tips: Anda dapat menggunakan bazel query --output=label_kind "//p:t" untuk mempelajari nama class aturan //p:t target. Selain itu, Anda dapat melihat pasangan stack pembuatan instance dalam output bazel query --output=build "//p:t" untuk mempelajari alasan target tersebut adalah instance dari class aturan tersebut.

Peringatan: Nama opsi "--test_lang_filter" adalah vestigial dan sayangnya misleading; jangan membuat asumsi tentang semantik berdasarkan nama.

--test_filter=filter-expression

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

Penafsiran tertentu dari filter-expression bergantung pada framework pengujian yang bertanggung jawab untuk menjalankan pengujian. Ini dapat berupa glob, substring, atau regexp. --test_filter adalah kemudahan dalam meneruskan argumen filter --test_arg yang berbeda, tetapi tidak semua framework mendukungnya.

Panjang

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

--explain=logfile

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

Jika Anda mengalami rebuild yang tidak terduga, opsi ini dapat membantu memahami alasannya. Tambahkan ke .bazelrc Anda agar logging terjadi untuk semua build berikutnya, lalu memeriksa log saat melihat langkah eksekusi yang dieksekusi secara tidak terduga. Opsi ini mungkin membawa penalti kinerja kecil, jadi Anda mungkin ingin menghapus saat tidak dibutuhkan 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 (setidaknya untuk sebagian besar perintah).

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

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

--profile=file

Opsi ini, yang menggunakan argumen nama file, menyebabkan Bazel menulis data pembuatan profil ke dalam file. Data 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 progres pemuatan paket membuat pesan teks. Jika dinonaktifkan, pesan tidak akan ditampilkan.

--[no]show_progress

Opsi ini menyebabkan pesan progres ditampilkan; nyala oleh secara default. Jika dinonaktifkan, pesan progres akan disembunyikan.

--show_progress_rate_limit=n

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

--show_result=n

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

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

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

File-file tersebut dicetak untuk memudahkan Anda untuk menyalin dan menempelkan ({i>paste<i}) nama file ke {i>shell<i}, untuk menjalankan file {i>executable<i} yang dibangun. Pesan "terbaru" atau "gagal" untuk setiap target dapat dengan mudah diuraikan oleh skrip yang mendorong build.

--sandbox_debug

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

--subcommands (-s)

Opsi ini menyebabkan fase eksekusi Bazel mencetak baris perintah 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 dicetak dalam sintaksis yang kompatibel dengan shell Bourne, sehingga dapat disalin dan ditempel dengan mudah ke command prompt shell. (Tanda kurung di sekitarnya disediakan untuk melindungi {i>shell<i} Anda dari cd dan exec panggilan; pastikan untuk menyalinnya.) Namun, beberapa perintah diterapkan secara internal dalam Bazel, seperti membuat hierarki symlink. Untuk ini, tidak ada command line yang akan ditampilkan.

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

Lihat juga --verbose_failures, di bawah.

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

--verbose_failures

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

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

Status ruang kerja

Gunakan opsi berikut untuk "memberi stempel" Biner yang dibuat Bazel: untuk menyematkan informasi tambahan ke dalam direktori 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, file ini mungkin dapat dieksekusi. Di Windows, file ini harus berupa biner native, biasanya file ".exe", ".bat", atau ".cmd".

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

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

Bazel kemudian menulis key-value pair ke dalam 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

Kontraknya adalah:

• Nilai kunci "stabil" sebaiknya jarang berubah, jika memungkinkan. Jika isi dari bazel-out/stable-status.txt berubah, Bazel membatalkan tindakan yang bergantung padanya. Dengan kata lain, jika nilai kunci stabil berubah, Bazel akan menjalankan ulang tindakan yang dicap. Oleh karena itu, status stabil tidak boleh berisi hal-hal seperti stempel waktu, karena mereka mengubah semua waktu, dan akan membuat Bazel mengulangi tindakan bercap pada setiap bangunan.

  Bazel selalu menghasilkan tombol stabil berikut:

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

• "volatil" key nilainya mungkin sering berubah. Bazel mengharapkannya berubah setiap saat, seperti stempel waktu, dan memperbarui file bazel-out/volatile-status.txt sebagaimana mestinya. Namun, untuk menghindari menjalankan ulang tindakan yang dicap setiap saat, Bazel berpura-pura bahwa file yang tidak stabil tidak pernah berubah. Dengan kata lain, jika file status yang tidak stabil 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 ulang tindakan tersebut, dan tindakan akan melihat status volatile yang diperbarui, tetapi perubahan status volatile saja tidak akan membatalkan tindakan.

  Bazel selalu menghasilkan kunci tidak stabil berikut:

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

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

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

Contoh program di Linux menggunakan Git:

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

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

--[no]stamp

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

Stempel waktu dapat diaktifkan atau dinonaktifkan secara eksplisit per aturan menggunakan Atribut stamp. Lihat Ensiklopedia Build untuk mengetahui detailnya. Kapan aturan menetapkan stamp = -1 (default untuk *_binary aturan), opsi ini menentukan apakah penandaan diaktifkan atau tidak.

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

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

Platform

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

Lihat informasi latar belakang tentang Platform dan Toolchain.

--platforms=labels

Label aturan platform yang menjelaskan platform target untuk perintah {i>current<i}.

--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. Ini platform akan dipertimbangkan sebelum yang dideklarasikan dalam file MODULE.bazel oleh register_execution_platforms(). Opsi ini menerima daftar platform yang dipisahkan koma sesuai urutan prioritas. Jika flag diteruskan beberapa kali, flag terbaru akan menggantikan flag sebelumnya.

--extra_toolchains=labels

Aturan toolchain yang akan dipertimbangkan selama resolusi toolchain. Rantai Alat dapat ditentukan menurut target yang tepat, atau sebagai pola target. Toolchain ini akan dipertimbangkan sebelum yang dinyatakan dalam file MODULE.bazel dengan register_toolchains().

--toolchain_resolution_debug=regex

Mencetak informasi debug sambil mencari toolchain jika jenis toolchain cocok ekspresi reguler. Beberapa ekspresi reguler dapat dipisahkan dengan koma. Ekspresi reguler dapat berupa 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 yang lebih panjang ke nama yang lebih pendek. Untuk detail selengkapnya, lihat Konfigurasi Starlark.

--symlink_prefix=string

Mengubah awalan symlink praktis yang dibuat. Tujuan 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 diterbitkan, tetapi build masih dianggap berhasil. Secara khusus, hal ini memungkinkan Anda mem-build dalam direktori hanya baca atau direktori yang tidak memiliki izin untuk ditulis. Setiap jalur yang dicetak dalam pesan pada akhir build hanya akan menggunakan bentuk pendek relatif symlink jika symlink menunjuk ke lokasi; dengan kata lain, Anda dapat mengandalkan ketepatan walaupun Anda tidak bisa mengandalkan {i>symlink<i} yang dibuat.

Beberapa nilai umum opsi ini:

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

• Mengurangi kekacauan: --symlink_prefix=.bazel/ akan membuat Bazel membuat symlink yang disebut bin (dll.) di dalam direktori tersembunyi .bazel.

--platform_suffix=string

Menambahkan akhiran ke nama pendek konfigurasi, yang digunakan untuk menentukan {i>output <i}yang ada. Menyetel opsi ini ke nilai yang berbeda akan menempatkan file ke dalam direktori yang berbeda, misalnya untuk meningkatkan tingkat kecocokan cache untuk build yang jika tidak melakukan clobber file {i>output<i} satu sama lain, atau untuk menyimpan file {i>output<i} untuk perbandingan.

--default_visibility=(private|public)

Flag sementara untuk menguji perubahan visibilitas default bazel. Tidak dimaksudkan untuk penggunaan umum tetapi didokumentasikan untuk kelengkapan sake.

--starlark_cpu_profile=_file_

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

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

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

Untuk melihat berbagai tampilan data yang sama, coba perintah pprof seperti svg, web, dan list.

Menggunakan Bazel untuk rilis

Bazel digunakan baik oleh software engineer selama pengembangan dan oleh engineer rilis saat menyiapkan biner untuk deployment ke production. Bagian ini memberikan daftar tips untuk rilis insinyur menggunakan Bazel.

Opsi signifikan

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

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

Opsi ini juga penting:

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

Menjalankan pengujian

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

Secara default, perintah ini melakukan build dan pengujian secara bersamaan aktivitas Anda, membangun semua target yang ditentukan (termasuk aktivitas non-pengujian target yang ditentukan pada baris perintah) dan menguji *_test dan test_suite menargetkan segera setelah prasyarat mereka dibangun, artinya eksekusi uji adalah disisipkan dengan bangunan. Melakukan hal tersebut biasanya akan menghasilkan peningkatan kecepatan.

Opsi untuk bazel test

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

Jika opsi ini disetel ke 'otomatis' ({i>default<i}) maka Bazel hanya akan menjalankan ulang pengujian jika salah satu ketentuan berikut berlaku:

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

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

Jika 'ya', perilaku penyimpanan dalam cache akan sama dengan perilaku penyimpanan otomatis kecuali bahwa server tersebut dapat menyimpan kegagalan uji dalam cache dan menjalankan pengujian dengan --runs_per_test.

Catatan: Hasil pengujian selalu disimpan di hierarki output Bazel, terlepas dari apakah opsi ini diaktifkan atau tidak, jadi Anda tidak perlu menggunakan --cache_test_results di operasi bazel test sebelumnya untuk mendapatkan hit cache. Opsi ini hanya memengaruhi apakah Bazel akan menggunakan sebelumnya atau tidak hasil yang disimpan, bukan apakah akan menyimpan hasil proses yang dijalankan saat ini.

Pengguna yang telah mengaktifkan opsi ini secara {i>default<i} di file .bazelrc dapat menemukan singkatan -t (aktif) atau -t- (nonaktif) nyaman untuk mengganti {i>default<i} pada suatu proses operasi tertentu.

--check_tests_up_to_date

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

Opsi ini juga menyiratkan Perilaku --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 uji yang sebenarnya. Meskipun waktu tunggu pengujian harus ditetapkan agar tidak tidak stabil, pengujian yang memiliki waktu tunggu yang sangat berlebihan dapat menyembunyikan masalah sebenarnya yang muncul secara tidak terduga.

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

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

Catatan: Setiap shard pengujian dialokasikan waktu tunggu seluruh Target XX_test. Penggunaan opsi ini tidak memengaruhi waktu tunggu pengujian default, hanya memperingatkan jika Bazel menganggap waktu tunggu dapat dibatasi lebih lanjut.

--[no]test_keep_going

Secara default, semua pengujian dijalankan hingga selesai. Jika penanda ini dinonaktifkan, namun, build dibatalkan pada pengujian yang tidak lulus. Langkah build berikutnya dan pemanggilan pengujian tidak dijalankan, dan pemanggilan yang sedang berlangsung dibatalkan. Jangan menentukan --notest_keep_going dan --keep_going.

--flaky_test_attempts=attempts

Opsi ini menentukan berapa kali maksimum pengujian harus dicoba jika gagal karena alasan apa pun. Pengujian yang awalnya gagal, tetapi akhirnya berhasil, dilaporkan sebagai FLAKY di ringkasan pengujian. Yaitu, namun, dianggap telah diteruskan untuk mengidentifikasi kode keluar Bazel atau jumlah total pengujian yang lulus. Pengujian yang gagal pada semua upaya yang diperbolehkan adalah dianggap gagal.

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

--runs_per_test=[regex@]number

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

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

• Jika tidak ada, kegagalan operasi akan menyebabkan seluruh pengujian gagal.
• Jika ada dan dua operasi dari shard yang sama akan menampilkan PASS dan GAGAL, maka pengujian akan menerima status tidak stabil (kecuali operasi gagal lainnya menyebabkan gagal).

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

--[no]runs_per_test_detects_flakes

Jika opsi ini ditentukan (secara default tidak ditentukan), Bazel akan mendeteksi fragmen pengujian yang tidak stabil melalui --runs_per_test. Jika satu atau beberapa dijalankan untuk satu shard gagal dan satu atau beberapa operasi untuk shard pass yang sama, targetnya akan dianggap tidak stabil dengan bendera tersebut. Jika tidak ditentukan, target akan melaporkan status gagal.

--test_summary=output_style

Menentukan cara ringkasan hasil pengujian ditampilkan.

• short mencetak hasil setiap pengujian bersama dengan nama file yang berisi output pengujian jika pengujian gagal. Ini adalah nilai default.
• terse seperti short, tetapi lebih singkat: hanya cetak 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 cara output pengujian harus ditampilkan:

• summary menampilkan ringkasan apakah setiap pengujian lulus atau gagal. Juga menampilkan nama file log output untuk pengujian yang gagal. Ringkasan akan dicetak di akhir build (selama build, pengguna hanya akan melihat pesan progres sederhana saat pengujian dimulai, lulus, atau gagal). Ini merupakan perilaku default.
• errors mengirimkan output stdout/stderr gabungan dari pengujian yang gagal hanya ke {i>stdout<i} segera setelah pengujian selesai, memastikan bahwa output pengujian dari pengujian simultan tidak dilakukan interaksi 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 mengalirkan output stdout/stderr dari setiap pengujian di secara real-time.

--java_debug

Opsi ini menyebabkan mesin virtual Java dari pengujian java menunggu koneksi dari Debugger yang mematuhi JDWP sebelum memulai pengujian. Opsi ini menyiratkan --test_output=streamed.

--[no]verbose_test_summary

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

--test_tmpdir=path

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

Catatan: Ini adalah direktori untuk menjalankan pengujian, bukan menyimpan hasil pengujian (hasil pengujian selalu disimpan di direktori bazel-out).

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

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

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

Pengujian yang secara eksplisit menyatakan kategori waktu tunggu yang berbeda dengan akan menerima nilai yang sama seolah-olah waktu tunggu itu telah secara implisit disetel oleh tag ukuran. Jadi tes ukuran 'small' yang menyatakan 'long' (panjang) waktu tunggu akan memiliki waktu tunggu efektif yang sama dengan pengujian secara tidak eksplisit waktu tunggu habis.

--test_arg=arg

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

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

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

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

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

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

--run_under=command-prefix

Ini menentukan awalan yang akan disisipkan oleh test runner di depan perintah {i>test<i} sebelum menjalankannya. command-prefix dibagi menjadi kata-kata menggunakan aturan tokenisasi shell Bourne, lalu daftar kata ditambahkan ke perintah yang akan dieksekusi.

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

Beberapa peringatan berlaku:

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

Contoh:

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

Pemilihan pengujian

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

Opsi lain untuk bazel test

Sintaks dan opsi yang tersisa sama persis dengan bazel build

Menjalankan file yang dapat dieksekusi

Perintah bazel run mirip dengan bazel build, kecuali digunakan untuk membangun dan menjalankan satu target. Berikut adalah sesi umumnya (//java/myapp:myapp mengucapkan halo dan menampilkan argumennya):

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

Catatan: -- diperlukan agar Bazel tidak menafsirkan --arg1 dan --arg2 sebagai opsi Bazel, melainkan sebagai bagian dari baris perintah untuk menjalankan biner. Selain itu, Bazel akan menghindari logging argumen ini ke konsol jika argumen tersebut berisi informasi sensitif.

bazel run serupa, tetapi tidak sama, dalam memanggil langsung biner yang dibuat oleh Bazel dan perilakunya berbeda tergantung pada apakah biner yang akan dipanggil adalah tes atau tidak.

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

Ketika biner adalah tes, direktori kerja saat ini akan menjadi {i>exec root<i} dan upaya dengan niat baik dilakukan untuk mereplikasi pengujian lingkungan biasanya berlari. Emulasi ini tidak sempurna, dan pengujian yang memiliki beberapa sharding tidak dapat dijalankan dengan cara ini ( Opsi command line --test_sharding_strategy=disabled dapat digunakan untuk mengatasi masalah ini)

Variabel lingkungan tambahan berikut juga tersedia untuk biner:

• BUILD_WORKSPACE_DIRECTORY: root ruang kerja tempat build dijalankan.
• BUILD_WORKING_DIRECTORY: direktori kerja saat ini tempat Bazel dijalankan.

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

Opsi untuk bazel run

--run_under=command-prefix

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

Memfilter output logging dari Bazel

Saat memanggil biner dengan bazel run, Bazel mencetak output logging dari Bazel itu sendiri dan biner di pemanggilan. Agar log tidak terlalu berisik, Anda dapat menyembunyikan output dari Bazel itu sendiri dengan flag --ui_event_filters dan --noshow_progress.

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

Menjalankan pengujian

bazel run juga dapat menjalankan biner pengujian, yang memiliki efek menjalankan pengujian pada perkiraan yang mendekati lingkungan seperti yang dijelaskan pada Ujian Menulis. Perhatikan bahwa tidak satu pun Argumen --test_* berpengaruh saat menjalankan pengujian dengan cara ini kecuali --test_arg .

Membersihkan output build

Perintah clean

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

Ingat bahwa setiap {i>instance<i} Bazel dikaitkan dengan satu ruang kerja, sehingga Perintah clean akan menghapus semua output dari semua build yang telah Anda buat dengan instance Bazel di ruang kerja tersebut.

Untuk menghapus seluruh hierarki kerja yang dibuat oleh instance Bazel, Anda dapat menentukan opsi --expunge. Saat dijalankan dengan --expunge, perintah bersih hanya menghapus seluruh hierarki dasar output yang, selain output build, berisi semua file sementara yang dibuat oleh Bazel. Anda juga menghentikan server Bazel setelah clean, yang setara dengan perintah shutdown. Misalnya, untuk membersihkan semua jejak {i>disk<i} dan memori dari instance Bazel, Anda dapat sebutkan:

  % bazel clean --expunge

Atau, Anda dapat menghapus di latar belakang menggunakan --expunge_async. Anda dapat menjalankan perintah Bazel secara aman di klien yang sama sementara penghapusan asinkron terus berjalan.

Catatan: Hal ini dapat menyebabkan pertentangan IO.

Perintah clean disediakan terutama sebagai cara ruang {i>disk<i} untuk ruang kerja yang tidak lagi diperlukan. Rebuild inkremental Bazel mungkin tidak sudah sempurna sehingga clean dapat digunakan untuk memulihkan menentukan kapan masalah muncul.

Desain Bazel sedemikian rupa sehingga masalah ini dapat diperbaiki dan {i>bug<i} ini memiliki prioritas tinggi untuk diperbaiki. Jika Anda menemukan build inkremental yang salah, ajukan laporan bug, dan laporkan bug di alat daripada menggunakan clean.

Membuat kueri grafik dependensi

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

Bahasa kueri didasarkan pada gagasan operasi aljabar di atas grafik; hal ini didokumentasikan secara rinci dalam

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

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

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

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

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

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

Membuat kueri grafik tindakan

Perhatian: Perintah kueri masih bersifat eksperimental dan API-nya akan berubah.

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

Alat ini menerima beberapa opsi command line. --output memilih format output. Format output default (text) dapat dibaca manusia, gunakan proto atau textproto untuk format yang dapat dibaca mesin. Secara khusus, perintah {i>aquery<i} berjalan di atas {i>build<i} Bazel biasa dan mewarisi seperangkat opsi yang tersedia selama proses build.

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

help

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

--[no]long (-l)

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

shutdown

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

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

shutdown menerima satu opsi, --iff_heap_size_greater_than _n_, yang memerlukan argumen bilangan bulat (dalam MB). Jika ditentukan, akan membuat penonaktifan tergantung pada jumlah memori yang telah digunakan. Hal ini berguna untuk skrip yang memulai banyak build, karena kebocoran memori di server Bazel dapat menyebabkannya error secara tidak sengaja; melakukan mulai ulang bersyarat akan mencegah kondisi ini.

info

Perintah info mencetak berbagai nilai yang terkait dengan {i>instance<i} server Bazel, atau dengan konfigurasi build khusus. (Ini dapat digunakan oleh skrip yang mendorong build.)

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

Data yang tidak bergantung pada konfigurasi

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

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

• output_base: jalur absolut ke direktori output dasar yang digunakan oleh instance Bazel ini untuk kombinasi workspace dan pengguna saat ini. Bazel bekerja dengan keras dan berkreasi di bawah direktori ini.

• execution_root: jalur absolut ke direktori root eksekusi di output_base. Direktori ini adalah root untuk semua file yang dapat diakses oleh perintah yang dieksekusi selama build, dan merupakan direktori kerja untuk perintah tersebut. Jika direktori {i>workspace<i} dapat ditulis, symlink bernama bazel-<workspace> ditempatkan di sana dan mengarahkan ke direktori ini.

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

• server_pid: ID proses server Bazel {i>checkout<i}.

• 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 pengembang dan pengguna super Bazel.

• command_log: jalur absolut ke file log perintah; jalur ini berisi aliran stdout dan stderr yang diselingi 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 jika Anda mengubah setelan opsi --output_base atau --output_user_root.

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

• gc-count, gc-time: Jumlah kumulatif dari pengumpulan sampah sejak awal server Bazel ini dan waktu yang dihabiskan untuk menjalankannya. Perlu diketahui bahwa nilai ini tidak direset di awal setiap bangun.

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

Contoh: ID proses server Bazel.

% bazel info server_pid
1285

Data khusus konfigurasi

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

• bazel-bin, bazel-testlogs, bazel-genfiles: melaporkan jalur absolut ke direktori bazel-* tempat program yang dihasilkan oleh build berada. Ini biasanya, meskipun tidak selalu, sama dengan symlink bazel-* yang dibuat di direktori ruang kerja dasar setelah berhasil dibuat. Namun, jika direktori ruang kerja hanya dapat dibaca, tidak ada symlink bazel-* yang dapat dibuat. Skrip yang menggunakan nilai yang dilaporkan oleh bazel info, bukan mengasumsikan keberadaan {i>symlink<i}, akan lebih tangguh.
• Lengkap "Buat" lingkungan fleksibel. Jika flag --show_make_env semua variabel yang ada dalam konfigurasi saat ini. lingkungan juga ditampilkan (seperti CC, GLIBC_VERSION, dll.). Ini adalah variabel yang diakses menggunakan $(CC) atau varref("CC") di dalam file BUILD.

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

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Contoh: direktori output bazel-bin untuk direktori saat ini konfigurasi Anda. Hal ini dijamin benar bahkan jika symlink bazel-bin tidak dapat dibuat karena alasan tertentu (seperti 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 Bazel yang dibuat biner, termasuk daftar perubahan tempat layanan itu dibuat dan tanggalnya. Hal ini sangat berguna dalam menentukan apakah Anda memiliki Bazel, atau jika Anda melaporkan bug. Beberapa nilai menarik adalah:

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

bazel --version, tanpa argumen lain, akan memberikan output yang sama dengan bazel version --gnu_format, kecuali tanpa efek samping dari kemungkinan memulai server Bazel atau membongkar arsip server. bazel --version dapat dijalankan dari di mana saja - tidak memerlukan direktori workspace.

mobile-install

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

Lihat bazel mobile-install untuk informasi selengkapnya.

Catatan: Perintah ini tidak menginstal hal yang sama dengan bazel build menghasilkan: Bazel menyesuaikan aplikasi sehingga dapat dibangun, diinstal, dan diinstal ulang dengan cepat. Namun, hal ini seharusnya transparan bagi aplikasi.

Opsi berikut ini didukung:

--incremental

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

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

--split_apks

Apakah akan menggunakan apk terpisah untuk menginstal dan mengupdate aplikasi di perangkat. Hanya berfungsi pada perangkat yang menjalankan 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 status bersih setelah menginstal. Setara dengan --start=DEBUG.

--start=_start_type_

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

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

Catatan: Jika lebih dari satu --start=_start_type_, --start_app, atau --debug_app ditetapkan, nilai terakhir akan digunakan.

--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. Ini ditempatkan sebelum subperintah di baris perintah dan biasanya digunakan untuk menentukan perangkat mana 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 teks untuk penginstalan inkremental. Tetapkan ke 1 agar logging debug dicetak ke konsol.

dump

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

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

Opsi berikut didukung:

• --action_cache membuang konten cache tindakan.
• --packages 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 mencakup aturan native dan Starlark. Jika pelacakan memori diaktifkan, aturan juga akan dicetak.
• --skylark_memory membuang file .gz yang kompatibel dengan pprof ke jalur yang ditentukan. Anda harus mengaktifkan pelacakan memori agar tindakan ini berfungsi.

Pelacakan memori

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

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

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 Anda menyimpan repositori Bazel.

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

Contoh:

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

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

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

analyze-profile

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

canonicalize-flags

canonicalize-flags yang mengambil daftar opsi untuk perintah Bazel dan mengembalikan daftar opsi lainnya yang memiliki efek sama. Daftar opsi baru ini bersifat kanonis. Misalnya, dua daftar opsi dengan efek yang sama akan dikanonikasikan ke daftar baru yang sama.

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

Catatan: Sejumlah kecil opsi tidak dapat diurutkan ulang, karena Bazel tidak dapat memastikan bahwa efeknya identik. Perhatikan juga bahwa perintah ini tidak memperluas flag dari --config.

Sebagai contoh:

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

Opsi startup

Opsi yang dijelaskan di bagian ini memengaruhi pengaktifan virtual machine Java yang digunakan oleh proses server Bazel, dan berlaku untuk semua perintah berikutnya yang ditangani oleh server tersebut. Jika sudah ada menjalankan server Bazel dan opsi {i>startup<i} tidak sesuai, maka akan harus dimulai ulang.

Semua opsi yang dijelaskan di bagian ini harus ditentukan menggunakan sintaksis --key=value atau --key value. Selain itu, opsi ini harus muncul sebelum nama Bazel perintah. 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 output-nya. Basis output juga merupakan kunci yang digunakan klien untuk menemukan server Bazel. Dengan mengubah basis {i>output<i}, Anda mengubah server yang akan menangani perintah tersebut.

Secara {i>default<i}, basis {i>output<i} diperoleh dari nama {i>login<i} pengguna, dan nama direktori ruang kerja (sebenarnya, ringkasan MD5-nya), sehingga nilai umumnya terlihat seperti: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

Catatan: Klien menggunakan basis output untuk menemukan instance server Bazel, jadi jika Anda menentukan basis output yang berbeda dalam perintah Bazel, server yang berbeda akan ditemukan (atau dimulai) untuk menangani permintaan. Anda dapat menjalankan dua build secara bersamaan Workspace dengan memvariasikan basis output.

Contoh:

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

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

Catatan: Sebaiknya jangan gunakan NFS atau sistem file jaringan serupa untuk direktori root, karena latensi akses yang lebih tinggi akan menyebabkan build yang jauh lebih lambat.

--output_user_root=dir

Mengarah ke direktori utama tempat output dan basis penginstalan dibuat. Direktori tidak boleh ada atau dimiliki oleh pengguna yang memanggil. Di masa lalu, ini diizinkan untuk menunjuk ke direktori yang dibagikan di antara berbagai pengguna tapi itu tidak diizinkan lagi. Ini dapat diizinkan sekali masalah #11100 telah diatasi.

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

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

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

Catatan: Sebaiknya Anda tidak menggunakan NFS atau sistem file berjaringan serupa untuk root karena latensi akses yang lebih tinggi akan menyebabkan build yang jauh lebih lambat.

--server_javabase=dir

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

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

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

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

--host_jvm_args=string

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

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

Opsi ini dapat digunakan beberapa kali dengan argumen individual. Perlu diketahui bahwa pengaturan penanda ini biasanya jarang diperlukan. Anda juga dapat meneruskan daftar string yang dipisahkan spasi, yang masing-masing akan ditafsirkan sebagai argumen JVM terpisah, tetapi fitur ini akan segera tidak digunakan lagi.

Bahwa ini tidak memengaruhi JVM apa pun yang digunakan oleh subproses Bazel: aplikasi, pengujian, alat, dan sebagainya. Untuk lulus Dari opsi JVM ke program Java yang dapat dieksekusi, baik yang dijalankan oleh bazel run maupun di command line, Anda harus menggunakan argumen --jvm_flags yang semua program java_binary dan java_test dukungan teknis IT. 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 terutama yang ditujukan untuk digunakan oleh pengembang Bazel.

Catatan: Hal ini tidak memengaruhi JVM apa pun yang digunakan oleh subproses Bazel: aplikasi, pengujian, alat, dll.

--autodetect_server_javabase

Opsi ini menyebabkan Bazel otomatis menelusuri JDK yang diinstal saat memulai, 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 bazel proses java untuk satu perintah, yang telah digunakan untuk perintah semantik yang berkaitan dengan penanganan sinyal, kontrol tugas, dan lingkungan pewarisan variabel, dan diperlukan untuk menjalankan bazel di penjara chroot.

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

Bazel akan berjalan lebih lambat dalam mode batch, atau dengan alternatif yang dijelaskan di atas. Ini karena, di antara hal-hal lain, cache file build bersifat permanen dengan memori, jadi dipertahankan di antara pemanggilan batch berurutan. Oleh karena itu, menggunakan mode batch sering kali lebih masuk akal jika performa tidak terlalu penting, seperti build berkelanjutan.

Peringatan: --batch cukup lebih lambat dari standar mode klien/server. Selain itu, server ini mungkin tidak mendukung semua fitur dan pengoptimalan yang dimungkinkan oleh server Bazel persisten. Jika menggunakan --batch untuk tujuan isolasi build, Anda harus menggunakan opsi perintah --nokeep_state_after_build, yang menjamin bahwa tidak ada status in-memory inkremental yang disimpan di antara build. Untuk memulai ulang server Bazel dan JVM setelah build, lakukan secara eksplisit menggunakan perintah "shutdown".

--max_idle_secs=n

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

Catatan: flag ini hanya dibaca jika Bazel perlu memulai server baru. Mengubah opsi ini tidak akan menyebabkan server dimulai ulang.

Opsi ini dapat digunakan oleh skrip yang memanggil Bazel untuk memastikan bahwa skrip tersebut tidak meninggalkan proses server Bazel di komputer pengguna jika skrip tersebut tidak akan berjalan. Misalnya, skrip pra-pengiriman mungkin ingin panggil bazel query untuk memastikan bahwa pengguna sedang menunggu persetujuan tidak menimbulkan dependensi yang tidak diinginkan. Namun, jika pengguna belum melakukan build terbaru di ruang kerja tersebut, sebaiknya skrip pra-pengiriman tidak memulai server Bazel hanya agar tetap tidak ada aktivitas selama sisa hari. Dengan menentukan nilai --max_idle_secs yang kecil dalam permintaan kueri, skrip dapat memastikan bahwa jika skrip tersebut menyebabkan server baru dimulai, server tersebut akan segera keluar, tetapi jika ternyata sudah ada server yang berjalan, server tersebut akan terus berjalan hingga tidak ada aktivitas selama waktu yang biasa. Tentu saja, timer tidak ada aktivitas server yang ada akan direset.

--[no]shutdown_on_low_sys_mem

Jika kebijakan ini disetel ke aktif dan --max_idle_secs disetel ke durasi positif, setelah server build tidak ada aktivitas selama beberapa waktu, matikan server saat sistem memori hampir habis. Khusus Linux.

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

--[no]block_for_lock

Jika diaktifkan, Bazel akan menunggu perintah Bazel lain yang menahan kunci server selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan keluar dengan error jika tidak bisa segera memperoleh kunci dan lanjutkan.

Developer dapat menggunakannya dalam pemeriksaan pra-pengiriman untuk menghindari waktu tunggu yang 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 terendah. Penjadwal antisipatif hanya dapat memenuhi hingga prioritas 4. Nilai negatif akan diabaikan.

--batch_cpu_scheduling

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

Opsi lain-lain

--[no]announce_rc

Mengontrol apakah Bazel mengumumkan opsi startup dan opsi perintah dibaca dari file {i>bazelrc<i} saat memulai.

--color (yes|no|auto)

Opsi ini menentukan apakah Bazel akan menggunakan warna untuk menyorot {i>outputnya<i} di layar.

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

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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