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 dalam Build with Bazel.
Sintaksis target
Beberapa perintah, seperti build
atau test
, dapat beroperasi pada daftar target. Metode tersebut menggunakan sintaksis yang lebih fleksibel daripada label, yang didokumentasikan dalam Menentukan target yang akan di-build.
Opsi
Bagian berikut menjelaskan opsi yang tersedia selama build. Saat --long
digunakan pada perintah bantuan, pesan bantuan
online akan memberikan informasi ringkasan tentang arti, jenis, dan
nilai default untuk setiap opsi.
Sebagian besar opsi hanya dapat ditentukan sekali. Jika ditentukan beberapa kali, instance terakhir akan menang. Opsi yang dapat ditentukan beberapa kali diidentifikasi dalam bantuan online dengan teks 'dapat digunakan beberapa kali'.
Lokasi paket
--package_path
Opsi ini menentukan kumpulan direktori yang ditelusuri guna menemukan file BUILD untuk paket tertentu.
Bazel menemukan paketnya dengan mencari jalur paket. Ini adalah daftar direktori bazel berurutan yang dipisahkan titik dua, 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:
- Jika karakter pertamanya adalah
/
, jalurnya bersifat absolut. - Jika jalur dimulai dengan
%workspace%
, jalur akan diambil secara relatif ke direktori bazel yang terdekat. Misalnya, jika direktori kerja Anda adalah/home/bob/clients/bob_client/bazel/foo
, string%workspace%
di jalur paket akan diperluas ke/home/bob/clients/bob_client/bazel
. - Semua yang lain diambil relatif terhadap direktori kerja.
Ini biasanya bukanlah hal yang Anda lakukan,
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 diselesaikan dari direktori/home/bob/clients/bob_client/bazel/foo
.
Jika Anda menggunakan jalur paket non-default, tentukan 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: Mem-build dari klien kosong
% mkdir -p foo/bazel % cd foo/bazel % touch WORKSPACE % bazel build --package_path /some/other/path //foo
--deleted_packages
Opsi ini menentukan daftar paket yang dipisahkan koma yang sebaiknya dianggap oleh Bazel untuk dihapus, dan tidak dicoba untuk dimuat dari direktori mana pun di jalur paket tersebut. Ini dapat digunakan untuk menyimulasikan penghapusan paket tanpa benar-benar menghapusnya.
Pemeriksaan error
Opsi ini mengontrol pemeriksaan kesalahan dan/atau peringatan Bazel.
--[no]check_visibility
Jika opsi ini disetel ke salah (false), pemeriksaan visibilitas akan didemosikan menjadi peringatan. Nilai default opsi ini adalah true, sehingga secara default, pemeriksaan visibilitas dilakukan.
--output_filter=regex
Opsi --output_filter
hanya akan menampilkan peringatan build dan
kompilasi untuk target yang cocok dengan ekspresi reguler. Jika target tidak cocok dengan ekspresi reguler yang diberikan dan 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):).)*$'` | Jangan tampilkan 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, kompilasi, dan/atau perakitan kode C, C++, atau assembler. Nilai ini tidak akan diteruskan saat penautan.
Opsi ini dapat digunakan beberapa kali. Contoh:
% bazel build --copt="-g0" --copt="-fpic" //foo
akan mengompilasi library foo
tanpa tabel debug, yang menghasilkan
kode yang tidak bergantung pada posisi.
--host_copt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber
yang dikompilasi dalam konfigurasi host. Hal ini analog dengan
opsi --copt
, tetapi hanya berlaku untuk
konfigurasi host.
--host_conlyopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber C
yang dikompilasi dalam konfigurasi host. Hal ini analog dengan
opsi --conlyopt
, tetapi hanya berlaku
untuk konfigurasi host.
--host_cxxopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber C++
yang dikompilasi dalam konfigurasi host. Hal ini analog dengan
opsi --cxxopt
, tetapi hanya berlaku untuk
konfigurasi host.
--host_linkopt=linker-option
Opsi ini menggunakan argumen yang akan diteruskan ke penaut untuk file sumber
yang dikompilasi dalam konfigurasi host. Hal ini analog dengan
opsi --linkopt
, tetapi hanya berlaku untuk
konfigurasi host.
--conlyopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler saat mengompilasi file sumber C.
Ini mirip dengan --copt
, tetapi hanya berlaku untuk kompilasi C,
bukan untuk kompilasi atau penautan C++. Jadi, Anda dapat meneruskan opsi khusus C
(seperti -Wno-pointer-sign
) menggunakan --conlyopt
.
--cxxopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler saat mengompilasi file sumber C++.
Ini mirip dengan --copt
, tetapi hanya berlaku untuk kompilasi C++,
bukan untuk kompilasi atau penautan C. Jadi, Anda dapat meneruskan opsi khusus C++
(seperti -fpermissive
atau -fno-implicit-templates
) menggunakan --cxxopt
.
Contoh:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler saat menautkan.
Hal ini mirip dengan --copt
, tetapi hanya berlaku untuk penautan,
bukan kompilasi. Jadi, Anda dapat meneruskan opsi compiler yang hanya masuk akal
pada waktu penautan (seperti -lssp
atau -Wl,--wrap,abort
)
menggunakan --linkopt
. Contoh:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
Aturan build juga dapat menentukan opsi link dalam atributnya. Setelan opsi ini selalu 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.
Opsi --strip
Bazel sesuai dengan opsi --strip-debug
ld:
hanya menghapus informasi proses debug. Jika karena alasan tertentu Anda ingin menghapus semua simbol,
bukan hanya simbol debug, Anda harus menggunakan opsi --strip-all
ld,
yang dapat Anda lakukan dengan meneruskan --linkopt=-Wl,--strip-all
ke Bazel. Perlu diketahui juga bahwa menyetel tanda --strip
Bazel akan mengganti --linkopt=-Wl,--strip-all
, sehingga Anda hanya boleh menetapkan salah satunya.
Jika hanya membangun satu biner dan ingin semua simbol dihapus, Anda juga dapat meneruskan --stripopt=--strip-all
dan secara eksplisit membangun versi //foo:bar.stripped
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.
--fdo_instrument=profile-output-dir
Opsi --fdo_instrument
memungkinkan pembuatan
output profil FDO (pengoptimalan masukan yang diarahkan) saat
biner C/C++ yang dibangun 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 diekstrak, dan diberikan ke
opsi Bazel
--fdo_optimize=profile-zip
untuk mengaktifkan kompilasi yang dioptimalkan FDO.
Untuk compiler LLVM, argumen juga merupakan direktori tempat file data profil
LLVM mentah di-dump. Contoh: --fdo_instrument=/path/to/rawprof/dir/
Opsi --fdo_instrument
dan --fdo_optimize
tidak dapat digunakan secara bersamaan.
--fdo_optimize=profile-zip
Opsi --fdo_optimize
memungkinkan penggunaan
informasi profil file per objek untuk melakukan pengoptimalan FDO (pengoptimalan masukan)
saat melakukan kompilasi. 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 oleh ekstensi .afdo.
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.
--[no]output_symbol_counts
Jika diaktifkan, setiap link yang dipanggil emas dari biner yang dapat dieksekusi C++ akan menghasilkan
file jumlah simbol (melalui opsi emas
--print-symbol-counts
). Untuk setiap input penaut, file mencatat jumlah simbol yang ditentukan dan jumlah simbol yang digunakan dalam biner.
Informasi ini dapat digunakan untuk melacak dependensi link yang tidak perlu.
File jumlah simbol ditulis ke jalur output biner dengan nama
[targetname].sc
.
Opsi ini dinonaktifkan secara default.
--java_language_version=version
Opsi ini menentukan versi sumber Java. Contoh:
% bazel build --java_language_version=8 java/com/example/common/foo:all
mengompilasi dan hanya mengizinkan konstruksi yang kompatibel dengan spesifikasi Java 8.
Nilai defaultnya adalah 11. -->
Kemungkinan nilainya adalah: 8, 9, 10, 11, 14, dan 15, serta dapat diperluas dengan
mendaftarkan toolchain Java kustom menggunakan default_java_toolchain
.
--tool_java_language_version=version
Versi bahasa Java yang digunakan untuk membangun alat yang dijalankan selama pembangunan. Nilai defaultnya adalah 11.
--java_runtime_version=version
Opsi ini menentukan versi JVM yang akan digunakan untuk mengeksekusi kode dan menjalankan pengujian. Contoh:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
mendownload JDK 11 dari repositori jarak jauh dan menjalankan aplikasi Java menggunakan JDK tersebut.
Nilai defaultnya adalah localjdk
.
Nilai yang mungkin adalah: localjdk
, localjdk_version
,
remotejdk_11
, dan remote_jdk17
.
Anda dapat memperluas nilai dengan mendaftarkan JVM kustom menggunakan
aturan repositori local_java_repository
atau remote_java_repostory
.
--tool_java_runtime_version=version
Versi JVM yang digunakan untuk menjalankan alat yang diperlukan selama build.
Nilai defaultnya adalah remotejdk_11
.
--jvmopt=jvm-option
Opsi ini memungkinkan argumen opsi diteruskan ke VM Java. Fungsi ini dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
akan menggunakan VM server untuk meluncurkan semua biner Java dan menetapkan ukuran heap startup untuk VM menjadi 256 MB.
--javacopt=javac-option
Opsi ini memungkinkan argumen opsi diteruskan ke javac. Fungsi ini dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
akan membuat ulang java_binary dengan info debug default javac (bukan default bazel).
Opsi diteruskan ke javac setelah opsi default 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
--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 sebenarnya digunakan untuk memeriksa jenis setiap file java, dan memperingatkan/menampilkan error jika bukan output dari dependensi langsung target saat ini.
off
berarti pemeriksaan dinonaktifkan.warn
berarti javac akan menghasilkan peringatan java standar berjenis[strict]
untuk setiap dependensi langsung yang hilang.default
,strict
, danerror
semuanya berarti javac akan menghasilkan error, bukan peringatan, sehingga target saat ini gagal di-build jika dependensi langsung yang hilang ditemukan. Ini juga merupakan perilaku default jika flag tidak ditentukan.
Semantik build
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 mem-build secepat mungkin: menghasilkan informasi proses debug minimal (-gmlt -Wl,-S
), dan tidak mengoptimalkan. Ini adalah defaultnya. Catatan:-DNDEBUG
tidak akan ditetapkan.dbg
berarti build dengan proses debug diaktifkan (-g
), sehingga Anda dapat menggunakan gdb (atau debugger lain).opt
berarti build dengan pengoptimalan diaktifkan dan dengan panggilanassert()
dinonaktifkan (-O2 -DNDEBUG
). Informasi proses debug tidak akan dibuat dalam modeopt
kecuali jika Anda juga meneruskan--copt -g
.
--cpu=cpu
Opsi ini menentukan arsitektur CPU target yang akan digunakan untuk kompilasi biner selama build.
--action_env=VAR=VALUE
Menentukan kumpulan variabel lingkungan yang tersedia selama eksekusi semua tindakan.
Variabel dapat ditentukan berdasarkan nama, dalam hal ini nilai akan diambil dari
lingkungan pemanggilan, atau oleh pasangan name=value
yang menetapkan nilai secara independen dari
lingkungan pemanggilan.
Flag --action_env
ini dapat ditentukan beberapa kali. Jika nilai ditetapkan ke variabel
yang sama di beberapa flag --action_env
, penetapan terbaru akan menang.
--experimental_action_listener=label
Opsi experimental_action_listener
menginstruksikan Bazel untuk menggunakan
detail dari aturan action_listener
yang ditentukan oleh label untuk
menyisipkan extra_actions
ke dalam grafik build.
--[no]experimental_extra_action_top_level_only
Jika opsi ini ditetapkan ke true, tindakan tambahan yang ditentukan oleh opsi command line --experimental_action_listener
hanya akan dijadwalkan untuk target tingkat teratas.
--experimental_extra_action_filter=regex
Opsi experimental_extra_action_filter
menginstruksikan Bazel untuk memfilter kumpulan target yang akan dijadwalkan untuk extra_actions
.
Flag ini hanya berlaku jika digunakan bersama dengan
flag --experimental_action_listener
.
Secara default, semua extra_actions
dalam penutupan transitif
target-to-build yang diminta akan dijadwalkan untuk dieksekusi.
--experimental_extra_action_filter
akan membatasi penjadwalan ke
extra_actions
yang label pemiliknya cocok dengan ekspresi reguler
yang ditentukan.
Contoh berikut akan membatasi penjadwalan extra_actions
agar hanya 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.
--fat_apk_cpu=cpu[,cpu]*
CPU untuk mem-build library C/C++ dalam deps
transitif dari
aturan android_binary
. Aturan C/C++ lainnya tidak terpengaruh. Misalnya, jika
cc_library
muncul dalam deps
transitif dari aturan android_binary
dan
aturan cc_binary
, cc_library
akan dibuat minimal dua kali:
sekali untuk setiap CPU yang ditentukan dengan --fat_apk_cpu
untuk
aturan android_binary
, dan sekali untuk CPU yang ditentukan dengan
--cpu
untuk aturan cc_binary
.
Defaultnya adalah armeabi-v7a
.
Satu file .so
dibuat dan dikemas dalam APK untuk
setiap CPU yang ditentukan dengan --fat_apk_cpu
. Nama file .so
menambahkan awalan nama aturan android_binary
dengan "lib". Misalnya, jika nama
android_binary
adalah "foo", file-nya 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++. Ini juga mencakup awalan yang bergantung pada platform.
Untuk mencocokkan file yang dihasilkan (seperti output genrule),
Bazel hanya dapat menggunakan jalur eksekusi. Dalam hal ini, regexp tidak boleh diawali dengan '//'
karena tidak cocok dengan jalur eksekusi mana pun. Nama paket dapat digunakan seperti ini:
--per_file_copt=base/.*\.pb\.cc@-g0
. 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 menetapkan
--strip=never
.
Sintaksis: [+-]regex[,[+-]regex]...@option[,option]...
Dengan
regex
adalah singkatan dari ekspresi reguler yang dapat diawali dengan
+
untuk mengidentifikasi pola yang disertakan dan dengan -
untuk mengidentifikasi
pola yang dikecualikan. option
adalah singkatan dari opsi arbitrer yang diteruskan
ke compiler C++. Jika opsi berisi ,
, opsi tersebut harus diapit tanda kutip seperti
\,
. Opsi juga dapat berisi @
, karena hanya @
pertama yang digunakan untuk memisahkan ekspresi reguler dari opsi.
Contoh:
--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
menambahkan opsi -O0
dan -fprofile-arcs
ke command line
compiler C++ untuk semua file .cc
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:
auto
: Menerjemahkan ke mode yang bergantung pada platform;default
untuk Linux danoff
untuk cygwin.default
: Memungkinkan bazel memilih apakah akan menautkan secara dinamis. Lihat linkstatic untuk mengetahui informasi selengkapnya.fully
: Menautkan semua target secara dinamis. Tindakan ini akan mempercepat waktu penautan dan mengurangi ukuran biner yang dihasilkan.off
: Menautkan semua target dalam mode sebagian besar statis. Jika-static
ditetapkan di linkopts, target akan berubah menjadi sepenuhnya statis.
--fission (yes|no|[dbg][,opt][,fastbuild])
Mengaktifkan Fission, yang menulis informasi debug C++ ke file .dwo khusus, bukan file .o, tempat file tersebut akan ditempatkan. Hal ini secara substansial mengurangi ukuran input ke link dan dapat mengurangi waktu link.
Jika disetel ke [dbg][,opt][,fastbuild]
(contoh:
--fission=dbg,fastbuild
), Fission hanya diaktifkan
untuk kumpulan mode kompilasi yang ditentukan. Ini berguna untuk setelan bazelrc. Jika ditetapkan ke yes
, Fission akan diaktifkan
secara universal. Jika ditetapkan ke no
, Fission akan dinonaktifkan
secara universal. Defaultnya adalah no
.
--force_ignore_dash_static
Jika tanda ini ditetapkan, -static
opsi apa pun pada linkopt cc_*
file BUILD aturan akan diabaikan. Hal ini hanya dimaksudkan sebagai
solusi untuk build hardening C++.
--[no]force_pic
Jika diaktifkan, semua kompilasi C++ akan menghasilkan kode yang tidak bergantung pada posisi ("-fPIC"), link lebih memilih library bawaan PIC daripada library non-PIC, dan link menghasilkan file yang dapat dieksekusi yang tidak bergantung pada posisi ("-pie"). Default-nya adalah dinonaktifkan.
--android_resource_shrinking
Memilih apakah akan melakukan penyingkatan resource untuk aturan android_binary. Menetapkan default untuk atribut shrink_resources pada aturan android_binary; lihat dokumentasi untuk aturan tersebut guna mengetahui detail lebih lanjut. Nilai defaultnya adalah nonaktif.
--custom_malloc=malloc-library-target
Jika ditentukan, selalu gunakan implementasi malloc yang diberikan, yang mengganti semua
atribut malloc="target"
, termasuk dalam target yang menggunakan
default (dengan tidak menentukan malloc
apa pun).
--crosstool_top=label
Opsi ini menentukan lokasi suite compiler crosstool
yang akan digunakan untuk semua kompilasi C++ selama build. Di lokasi tersebut, Bazel akan mencari file CROSSTOOL dan menggunakannya untuk menentukan setelan --compiler
secara otomatis.
--host_crosstool_top=label
Jika tidak ditentukan, Bazel akan menggunakan nilai --crosstool_top
untuk mengompilasi
kode dalam konfigurasi host, seperti alat yang 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
.
--android_crosstool_top=label
Crosstool yang akan digunakan untuk mengompilasi aturan C/C++ dalam deps
transitif dari
aturan android_binary
. Hal ini berguna jika target lain dalam
build memerlukan crosstool yang berbeda. Secara default, gunakan crosstool
yang dihasilkan oleh aturan android_ndk_repository
dalam file WORKSPACE.
Lihat juga --fat_apk_cpu
.
--compiler=version
Opsi ini menentukan versi compiler C/C++ (seperti gcc-4.1.0
)
yang akan digunakan untuk kompilasi biner selama build. Jika ingin
mem-build dengan alat silang kustom, Anda harus menggunakan file CROSSTOOL, bukan
menentukan tanda ini.
--android_sdk=label
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
Opsi ini menentukan label java_toolchain yang digunakan untuk mengompilasi file sumber Java.
--host_java_toolchain=label
Jika tidak ditentukan, bazel akan menggunakan nilai --java_toolchain
untuk mengompilasi
kode dalam konfigurasi host, seperti untuk alat yang dijalankan selama build. Tujuan utama flag ini
adalah untuk mengaktifkan kompilasi silang.
--javabase=(label)
Opsi ini menetapkan label penginstalan Java dasar yang akan digunakan untuk bazel run,
bazel test, dan untuk biner Java yang di-build oleh aturan java_binary
dan
java_test
. Variabel"Make" JAVABASE
dan JAVA
berasal dari opsi ini.
--host_javabase=label
Opsi ini menetapkan label penginstalan Java dasar yang akan digunakan dalam konfigurasi host, misalnya untuk alat build host termasuk JavaBuilder dan Singlejar.
Tindakan ini tidak memilih compiler Java yang digunakan untuk mengompilasi file
sumber Java. Compiler dapat dipilih dengan menetapkan
opsi --java_toolchain
.
Strategi eksekusi
Opsi ini memengaruhi cara Bazel menjalankan build. Hal ini tidak akan berdampak signifikan pada file output yang dihasilkan oleh build. Biasanya, efek utamanya adalah pada kecepatan build.
--spawn_strategy=strategy
Opsi ini mengontrol tempat dan cara perintah dieksekusi.
standalone
menyebabkan perintah dieksekusi sebagai subproses lokal. Nilai ini tidak digunakan lagi. Sebagai gantinya, gunakanlocal
.sandboxed
menyebabkan perintah dieksekusi di dalam sandbox di komputer lokal. Hal ini mengharuskan semua file input, dependensi data, dan alat dicantumkan sebagai dependensi langsung dalam atributsrcs
,data
, dantools
. Bazel mengaktifkan sandbox lokal secara default, pada sistem yang mendukung eksekusi dengan sandbox.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 tempat dan cara perintah dijalankan, yang menggantikan --spawn_strategy (dan --genrule_strategy dengan mnemonic Genrule) berdasarkan per-mnemonik. Lihat --spawn_strategy untuk strategi yang didukung dan efeknya.
--strategy_regexp=<filter,filter,...>=<strategy>
Opsi ini menentukan strategi yang harus digunakan untuk mengeksekusi perintah yang memiliki deskripsi
yang cocok dengan regex_filter
tertentu. Lihat
--per_file_copt untuk mengetahui detail tentang
pencocokan regex_filter. Lihat
--spawn_strategy untuk strategi
yang didukung dan efeknya.
regex_filter
terakhir yang cocok dengan deskripsi digunakan. Opsi ini menggantikan tanda lain untuk menentukan strategi.
- Contoh:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
berarti menjalankan tindakan menggunakan strategilocal
jika deskripsinya cocok dengan //foo.*.cc, tetapi tidak cocok dengan //foo/bar. - Contoh:
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed
menjalankan 'Mengompilasi //foo/bar/baz' dengan strategisandboxed
, tetapi membalikkan urutan akan menjalankannya denganlocal
. - Contoh:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
menjalankan 'Compiling //foo/bar/baz' dengan strategilocal
dan kembali kesandboxed
jika gagal.
--genrule_strategy=strategy
Ini adalah singkatan yang tidak digunakan lagi untuk --strategy=Genrule=strategy
.
--jobs=n
(-j)
Opsi ini, yang menggunakan argumen bilangan bulat, menentukan batas jumlah tugas yang harus dijalankan secara serentak selama fase eksekusi build.
--progress_report_interval=n
Bazel secara berkala mencetak laporan progres pada tugas yang belum
selesai (seperti pengujian yang berjalan lama). Opsi ini menetapkan
frekuensi pelaporan, progres akan dicetak setiap n
detik.
Nilai defaultnya adalah 0, yang berarti algoritma inkremental: laporan pertama akan dicetak setelah 10 detik, lalu 30 detik, dan setelah progres tersebut dilaporkan sekali setiap menit.
Saat bazel menggunakan kontrol kursor, seperti yang ditentukan oleh
--curses
, progres dilaporkan setiap detik.
--local_{ram,cpu}_resources resources or resource expression
Opsi ini menentukan jumlah resource lokal (RAM dalam MB dan jumlah core logis CPU)
yang dapat dipertimbangkan Bazel saat menjadwalkan aktivitas build dan pengujian untuk dijalankan secara lokal. Flag ini
menggunakan bilangan bulat, atau kata kunci (HOST_RAM atau HOST_CPUS) secara opsional, diikuti dengan [-|*
float]
(misalnya, --local_cpu_resources=2
, --local_ram_resources=HOST_RAM*.5
,
--local_cpu_resources=HOST_CPUS-1
).
Flag bersifat independen; salah satu atau keduanya dapat ditetapkan. Secara default, Bazel memperkirakan
jumlah RAM dan jumlah core CPU langsung dari konfigurasi sistem lokal.
--[no]build_runfile_links
Opsi ini, yang diaktifkan secara default, menentukan apakah symlink
runfile untuk pengujian dan biner harus dibuat di direktori output.
Penggunaan --nobuild_runfile_links
dapat berguna
untuk memvalidasi apakah semua target dikompilasi tanpa menimbulkan overhead
untuk mem-build hierarki runfile.
Saat pengujian (atau aplikasi) dieksekusi, dependensi data
run-time-nya dikumpulkan di satu tempat. Dalam hierarki output
Bazel, hierarki "runfiles" ini biasanya di-root sebagai saudara dari
biner atau pengujian yang sesuai.
Selama eksekusi uji, runfile dapat diakses menggunakan jalur formulir
$TEST_SRCDIR/workspace/packagename/filename
.
Hierarki runfile memastikan bahwa pengujian memiliki akses ke semua file
yang memiliki dependensi yang dideklarasikan, dan tidak lebih. Secara
default, hierarki runfile diterapkan dengan membuat kumpulan
link simbolis ke file yang diperlukan. 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 yang diaktifkan secara default ini menentukan apakah manifes runfile
harus ditulis ke hierarki output.
Menonaktifkannya menyiratkan --nobuild_runfile_links
.
Ini dapat dinonaktifkan saat menjalankan pengujian dari jarak jauh, karena hierarki runfile akan dibuat dari jarak jauh dari manifes dalam memori.
--[no]discard_analysis_cache
Jika opsi ini diaktifkan, Bazel akan menghapus cache analisis tepat sebelum eksekusi dimulai, sehingga 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 membuat sebanyak mungkin, bahkan saat 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.
Meskipun opsi ini biasanya dikaitkan dengan fase eksekusi
build, opsi ini juga memengaruhi fase analisis: jika beberapa target
ditentukan dalam perintah build, tetapi hanya beberapa di antaranya yang dapat
berhasil dianalisis, build akan berhenti dengan error
kecuali jika --keep_going
ditentukan, dalam hal ini
build akan melanjutkan 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 memungkinkan
penghindaran kompilasi ulang jika perubahan hanya dilakukan pada
isi metode atau anggota pribadi class.
--[no]interface_shared_objects
Opsi ini mengaktifkan antarmuka objek bersama, yang membuat biner dan library bersama lainnya bergantung pada antarmuka objek bersama, bukan implementasinya. Jika hanya implementasi yang berubah, Bazel dapat menghindari pembuatan ulang target yang bergantung pada library bersama yang diubah tanpa perlu.
Pilihan output
Opsi ini menentukan apa yang akan dibangun atau diuji.
--[no]build
Opsi ini menyebabkan fase eksekusi build terjadi; opsi ini diaktifkan 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 mem-build apa yang diperlukan untuk menjalankan aturan *_test
dan test_suite
yang tidak difilter karena
ukuran,
waktu tunggu,
tag, atau
bahasanya.
Jika ditentukan, Bazel akan mengabaikan target lain yang ditentukan di command line.
Secara default, opsi ini dinonaktifkan dan Bazel akan mem-build semua
yang diminta, termasuk aturan *_test
dan test_suite
yang difilter dari
pengujian. Hal ini berguna karena menjalankan
bazel test --build_tests_only foo/...
mungkin tidak mendeteksi semua kerusakan
build dalam 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 demikian, build akan berhasil diselesaikan, seperti biasa. Namun, jika ada file yang sudah tidak aktual, error akan dilaporkan dan build akan gagal, bukan di-build. Opsi ini mungkin berguna untuk menentukan apakah build telah dilakukan lebih baru daripada pengeditan sumber (misalnya, untuk pemeriksaan pra-pengiriman) tanpa menimbulkan biaya build.
Lihat juga --check_tests_up_to_date
.
--[no]compile_one_dependency
Mengompilasi satu dependensi 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 dipilih secara preferensial. Untuk beberapa aturan dengan preferensi yang sama, aturan yang muncul pertama kali dalam file BUILD akan dipilih. Pola target bernama eksplisit yang tidak mereferensikan file sumber akan menghasilkan error.
--save_temps
Opsi --save_temps
menyebabkan output sementara dari compiler akan
disimpan. Ini mencakup file .s (kode assembler), .i (C yang telah diproses sebelumnya), dan .ii
(C++ yang telah diproses sebelumnya). Output ini sering kali berguna untuk proses debug. Temp hanya akan
dibuat untuk kumpulan target yang ditentukan di command line.
Flag --save_temps
saat ini hanya berfungsi untuk aturan cc_*.
Untuk memastikan Bazel mencetak lokasi file output tambahan, pastikan
setelan --show_result n
Anda 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 di-build dan dijalankan meskipun tidak cocok dengan filter ini. Untuk menghindari pembuatannya, filter
target pengujian menggunakan --test_tag_filters
atau dengan mengecualikannya secara eksplisit.
--test_size_filters=size[,size]*
Jika ditentukan, Bazel hanya akan menguji (atau mem-build jika --build_tests_only
juga ditentukan) target pengujian dengan ukuran yang ditentukan. Filter ukuran pengujian
ditentukan sebagai daftar nilai ukuran pengujian yang diizinkan yang dipisahkan koma (kecil,
sedang, besar, atau sangat besar), yang secara opsional didahului dengan tanda '-' yang digunakan untuk menunjukkan
ukuran pengujian yang dikecualikan. Misalnya,
% bazel test --test_size_filters=small,medium //foo:all
% bazel test --test_size_filters=-large,-enormous //foo:all
hanya akan menguji pengujian kecil dan menengah di dalam //foo.
Secara default, pemfilteran ukuran pengujian tidak diterapkan.
--test_timeout_filters=timeout[,timeout]*
Jika ditentukan, Bazel akan menguji (atau mem-build jika --build_tests_only
juga ditentukan) hanya target pengujian dengan waktu tunggu yang diberikan. Filter waktu tunggu pengujian ditentukan sebagai daftar nilai waktu tunggu pengujian yang diizinkan (singkat, sedang, lama, atau abadi) yang dipisahkan koma, yang secara opsional didahului dengan tanda '-' yang digunakan untuk menunjukkan waktu tunggu pengujian yang dikecualikan. Lihat --test_size_filters
untuk contoh sintaksis.
Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.
--test_tag_filters=tag[,tag]*
Jika ditentukan, Bazel hanya akan menguji (atau mem-build jika --build_tests_only
juga ditentukan) target pengujian yang memiliki minimal satu tag yang diperlukan
(jika ada yang ditentukan) dan tidak memiliki tag yang dikecualikan. Filter tag pengujian ditentukan sebagai daftar kata kunci tag yang dipisahkan koma, yang secara opsional didahului dengan tanda '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan mungkin juga memiliki
tanda '+' sebelumnya.
Misalnya,
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
akan menguji target yang diberi tag dengan tag performance
atau
stress
, tetapi tidak diberi tag dengan tag flaky
.
Secara default, pemfilteran tag pengujian tidak diterapkan. Perhatikan bahwa Anda juga dapat memfilter
tag size
dan local
pengujian dengan
cara ini.
--test_lang_filters=lang[,lang]*
Menentukan daftar bahasa pengujian yang dipisahkan koma untuk bahasa dengan aturan *_test
resmi
(lihat ensiklopedi build untuk mengetahui daftar lengkapnya). Setiap
bahasa dapat secara opsional didahului dengan '-' untuk menentukan bahasa
yang dikecualikan. Nama yang digunakan untuk setiap bahasa harus sama dengan
awalan bahasa dalam aturan *_test
, misalnya,
cc
, java
, atau sh
.
Jika ditentukan, Bazel hanya akan menguji (atau mem-build jika --build_tests_only
juga ditentukan) target pengujian dari bahasa yang ditentukan.
Misalnya,
% bazel test --test_lang_filters=cc,java foo/...
hanya akan menguji pengujian C/C++ dan Java (masing-masing ditentukan menggunakan
aturan cc_test
dan java_test
)
di foo/...
, sedangkan
% bazel test --test_lang_filters=-sh,-java foo/...
akan menjalankan semua pengujian di foo/...
kecuali untuk
pengujian sh_test
dan java_test
.
Secara default, pemfilteran bahasa pengujian tidak diterapkan.
--test_filter=filter-expression
Menentukan filter yang dapat digunakan oleh runner pengujian untuk memilih subset pengujian untuk dijalankan. Semua target yang ditentukan dalam pemanggilan akan dibangun, tetapi bergantung pada ekspresi, hanya beberapa target yang dapat dieksekusi; dalam beberapa kasus, hanya metode pengujian tertentu yang 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 sehingga logging terjadi untuk semua build berikutnya, lalu periksa log saat Anda melihat langkah eksekusi yang dieksekusi secara tidak terduga. Opsi ini
mungkin menimbulkan penalti performa kecil, jadi sebaiknya Anda menghapusnya
jika tidak diperlukan lagi.
--verbose_explanations
Opsi ini meningkatkan panjang penjelasan yang dihasilkan saat opsi --explain diaktifkan.
Secara khusus, jika penjelasan panjang diaktifkan, dan file output dibuat ulang karena perintah yang digunakan untuk membuatnya 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, membuat 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 menghasilkan pesan progres pemuatan paket. Jika dinonaktifkan, pesan tidak akan ditampilkan.
--[no]show_progress
Opsi ini menyebabkan pesan progres ditampilkan; opsi ini diaktifkan secara default. Jika dinonaktifkan, pesan progres akan disembunyikan.
--show_progress_rate_limit=n
Opsi ini menyebabkan bazel menampilkan maksimal satu pesan progres per n
detik,
dengan n adalah bilangan riil.
Nilai default untuk opsi ini adalah 0,02, yang berarti bazel akan membatasi pesan
progres menjadi satu per setiap 0,02 detik.
--show_result=n
Opsi ini mengontrol pencetakan informasi hasil di akhir
perintah bazel build
. Secara default, jika satu
target build ditentukan, Bazel akan mencetak pesan yang menyatakan apakah
target berhasil 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
mengambil argumen bilangan bulat, yang merupakan jumlah maksimum target
yang informasi hasil lengkapnya harus dicetak. Secara default,
nilainya adalah 1. Di atas nilai minimum ini, tidak ada informasi hasil
yang ditampilkan untuk setiap target. Dengan demikian, nol menyebabkan informasi
hasil selalu disembunyikan, dan nilai yang sangat besar menyebabkan
hasil selalu dicetak.
Pengguna dapat memilih nilai di antaranya jika mereka secara rutin
berganti-ganti antara mem-build grup kecil target (misalnya,
selama siklus kompilasi-edit-pengujian) dan grup besar target
(misalnya, saat membuat ruang kerja baru atau menjalankan
pengujian regresi). Dalam kasus pertama, informasi hasil
sangat berguna, sedangkan dalam kasus kedua, informasi tersebut kurang berguna. Seperti semua
opsi, hal ini dapat ditentukan secara implisit melalui
file .bazelrc
.
File ini dicetak guna memudahkan Anda untuk menyalin dan menempelkan nama file ke shell, untuk menjalankan file yang dapat dieksekusi 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 eksekusi tindakan. Opsi ini juga mempertahankan direktori sandbox, sehingga file yang terlihat oleh tindakan selama eksekusi dapat diperiksa.
--subcommands
(-s
)
Opsi ini menyebabkan fase eksekusi Bazel mencetak command line lengkap untuk setiap perintah sebelum mengeksekusinya.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'] (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
Jika memungkinkan, perintah dicetak dalam sintaksis yang kompatibel dengan shell Bourne,
sehingga dapat disalin dan ditempel dengan mudah ke command prompt shell.
(Tanda kurung di sekitarnya disediakan untuk melindungi shell dari
panggilan cd
dan exec
; pastikan untuk menyalinnya.)
Namun, beberapa perintah diimplementasikan secara internal dalam Bazel, seperti
membuat hierarki symlink. Untuk jenis ini, tidak ada command line yang bisa ditampilkan.
--subcommands=pretty_print
dapat diteruskan untuk mencetak
argumen perintah sebagai daftar, bukan sebagai satu baris. Hal ini dapat
membantu membuat baris perintah yang panjang lebih mudah dibaca.
Lihat juga --verbose_failures, di bawah.
Untuk mencatat subperintah ke file dalam format yang mudah digunakan alat, lihat --execution_log_json_file dan --execution_log_binary_file.
--verbose_failures
Opsi ini menyebabkan fase eksekusi Bazel mencetak command line lengkap untuk perintah yang gagal. Hal ini sangat berharga untuk men-debug build yang gagal.
Perintah yang gagal akan dicetak dalam sintaksis yang kompatibel dengan shell Bourne, yang cocok untuk menyalin dan menempel ke perintah shell.
Status ruang kerja
Gunakan opsi ini untuk "memberi stempel" pada biner yang dibuat Bazel: untuk menyematkan informasi tambahan ke dalam
biner, seperti revisi kontrol sumber atau informasi terkait ruang kerja lainnya. Anda dapat menggunakan
mekanisme ini dengan aturan yang mendukung atribut stamp
, seperti
genrule
, cc_binary
, dan lainnya.
--workspace_status_command=program
Flag ini memungkinkan Anda menentukan biner yang dijalankan Bazel sebelum setiap build. Program ini dapat melaporkan informasi tentang status ruang kerja, seperti revisi kontrol sumber saat ini.
Nilai flag harus berupa jalur ke program native. Di Linux/macOS, 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 key-value pair 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 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 berlawanan dengan intuisi, jadi jangan terlalu memikirkannya.)
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 denganSTABLE_
bazel-out/volatile-status.txt
berisi kunci lainnya dan nilainya
Kontraknya adalah:
Nilai kunci "stabil" sebaiknya jarang berubah, jika memungkinkan. Jika konten
bazel-out/stable-status.txt
berubah, Bazel akan membatalkan tindakan yang bergantung padanya. Dengan kata lain, jika nilai tombol yang stabil berubah, Bazel akan menjalankan kembali tindakan yang diberi stempel. Oleh karena itu, status stabil tidak boleh berisi hal-hal seperti stempel waktu, karena stempel waktu selalu berubah, dan akan membuat Bazel menjalankan ulang tindakan yang dicap dengan setiap build.Bazel selalu menghasilkan tombol stabil berikut:
BUILD_EMBED_LABEL
: nilai--embed_label
BUILD_HOST
: nama mesin host tempat Bazel berjalanBUILD_USER
: nama pengguna yang digunakan Bazel untuk menjalankannya
Nilai kunci "volatil" dapat 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 (nilaiSystem.currentTimeMillis()
dibagi dengan seribu)FORMATTED_DATE
: waktu build Diformat sebagaiyyyy MMM d HH mm ss EEE
(misalnya 2023 Jun 2 01 44 29 Fri) dalam UTC.
Di Linux/macOS, Anda dapat meneruskan --workspace_status_command=/bin/true
untuk
menonaktifkan pengambilan status ruang kerja, karena true
tidak melakukan apa pun, berhasil (keluar
dengan nol) dan tidak mencetak output. Di Windows, Anda dapat meneruskan jalur true.exe
MSYS
untuk mendapatkan efek yang sama.
Jika perintah status ruang kerja gagal (keluar 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 tidak stabil akan menyertakan baris lainnya.
--[no]stamp
Opsi ini, bersama dengan atribut aturan stamp
, mengontrol apakah akan
menyematkan informasi build dalam biner.
Stempel dapat diaktifkan atau dinonaktifkan secara eksplisit berdasarkan per aturan menggunakan
atribut stamp
. Lihat Ensiklopedia Build untuk mengetahui detailnya. Saat
aturan menetapkan stamp = -1
(default untuk aturan *_binary
), opsi ini
menentukan apakah stempel diaktifkan.
Bazel tidak pernah memberi stempel pada biner yang dibuat untuk konfigurasi host,
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.
Menetapkan --nostamp
umumnya diinginkan untuk performa build, karena
mengurangi volatilitas input dan memaksimalkan caching build.
Platform
Gunakan opsi ini untuk mengontrol platform host dan target yang mengonfigurasi cara kerja build, dan untuk mengontrol platform eksekusi dan toolchain yang tersedia untuk aturan Bazel.
Lihat informasi latar belakang tentang Platform dan Toolchain.
--platforms=labels
Label aturan platform yang menjelaskan platform target untuk perintah saat ini.
--host_platform=label
Label aturan platform yang menjelaskan sistem host.
--extra_execution_platforms=labels
Platform yang tersedia sebagai platform eksekusi untuk menjalankan tindakan. Platform dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Platform ini akan dipertimbangkan sebelum platform yang dideklarasikan dalam file WORKSPACE oleh register_execution_platforms().
--extra_toolchains=labels
Aturan toolchain yang akan dipertimbangkan selama resolusi toolchain. Toolchain dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Toolchain ini akan dipertimbangkan sebelum yang dideklarasikan dalam file WORKSPACE oleh register_toolchains().
--toolchain_resolution_debug=regex
Mencetak informasi debug sambil mencari toolchain jika jenis toolchain cocok
dengan ekspresi reguler. Beberapa ekspresi reguler dapat dipisahkan dengan koma. Regex dapat
dibatalkan dengan menggunakan -
di awal. Hal ini dapat membantu developer
aturan Bazel atau Starlark dengan kegagalan proses debug karena toolchain yang tidak ada.
Lain-lain
--flag_alias=alias_name=target_path
Flag praktis yang digunakan untuk mengikat setelan build Starlark yang lebih panjang ke nama yang lebih pendek. Untuk detail selengkapnya, lihat Konfigurasi Starlark.
--symlink_prefix=string
Mengubah awalan symlink praktis yang dihasilkan. Nilai
default untuk awalan symlink adalah bazel-
yang
akan membuat symlink bazel-bin
, bazel-testlogs
, dan
bazel-genfiles
.
Jika link simbolis tidak dapat dibuat karena alasan apa pun, peringatan akan 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 informasi di akhir build hanya akan menggunakan bentuk singkat yang relatif terhadap symlink jika symlink mengarah ke lokasi yang diharapkan; dengan kata lain, Anda dapat mengandalkan kebenaran jalur tersebut, meskipun Anda tidak dapat mengandalkan symlink yang dibuat.
Beberapa nilai umum opsi ini:
Hentikan pembuatan symlink:
--symlink_prefix=/
akan menyebabkan Bazel tidak membuat atau mengupdate symlink apa pun, termasuk symlinkbazel-out
danbazel-<workspace>
. Gunakan opsi ini untuk sepenuhnya menyembunyikan pembuatan symlink.Mengurangi kekacauan:
--symlink_prefix=.bazel/
akan menyebabkan Bazel membuat symlink yang disebutbin
(dll.) di dalam direktori tersembunyi.bazel
.
--platform_suffix=string
Menambahkan akhiran ke nama singkat konfigurasi, yang digunakan untuk menentukan direktori output. Menetapkan opsi ini ke nilai yang berbeda akan menempatkan file ke dalam direktori yang berbeda, misalnya untuk meningkatkan tingkat cache ditemukan untuk build yang menyusun file output satu sama lain, atau menyimpan file output untuk dibandingkan.
--default_visibility=(private|public)
Flag sementara untuk menguji perubahan visibilitas default bazel. Tidak dimaksudkan untuk penggunaan umum, tetapi didokumentasikan demi kelengkapan.
--[no]use_action_cache
Opsi ini diaktifkan secara default. Jika dinonaktifkan, Bazel tidak akan menggunakan cache tindakan lokalnya. Menonaktifkan cache tindakan lokal akan menghemat memori dan ruang disk untuk build bersih, tetapi akan membuat build inkremental lebih lambat.
--starlark_cpu_profile=_file_
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 lambat karena komputasi yang berlebihan. Contoh:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
Untuk tampilan data yang sama yang berbeda, coba perintah pprof
svg
,
web
, dan list
.
Menggunakan Bazel untuk rilis
Bazel digunakan oleh software engineer selama siklus pengembangan, dan oleh engineer rilis saat menyiapkan biner untuk deployment ke produksi. Bagian ini memberikan daftar tips untuk engineer rilis yang menggunakan Bazel.
Opsi signifikan
Saat menggunakan Bazel untuk build rilis, masalah yang sama akan muncul seperti skrip lain yang menjalankan build. Untuk mengetahui detail selengkapnya, lihat Memanggil Bazel dari skrip. Secara khusus, opsi berikut sangat direkomendasikan:
Opsi ini juga penting:
--package_path
--symlink_prefix
: untuk mengelola build untuk beberapa konfigurasi, mungkin lebih mudah untuk membedakan setiap build dengan ID yang berbeda, seperti "64bit" vs. "32bit". Opsi ini membedakan symlinkbazel-bin
(dll.).
Menjalankan pengujian
Untuk mem-build dan menjalankan pengujian dengan bazel, ketik bazel test
, diikuti dengan nama target pengujian.
Secara default, perintah ini menjalankan aktivitas build dan pengujian
bersamaan, dengan mem-build semua target yang ditentukan (termasuk target non-pengujian
yang ditentukan di command line) serta menguji
target *_test
dan test_suite
segera setelah
prasyaratnya dibangun, yang berarti bahwa eksekusi uji
disisihkan dengan build. Melakukan hal ini biasanya menghasilkan peningkatan
kecepatan yang signifikan.
Opsi untuk bazel test
--cache_test_results=(yes|no|auto)
(-t
)
Jika opsi ini ditetapkan ke 'auto' (default), Bazel hanya akan menjalankan ulang pengujian jika salah satu kondisi 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 'yes', perilaku penyimpanan dalam cache akan sama dengan otomatis, kecuali bahwa perilaku ini dapat menyimpan kegagalan pengujian dan pengujian yang dijalankan dengan --runs_per_test
dalam cache.
Pengguna yang telah mengaktifkan opsi ini secara default di
file .bazelrc
mereka mungkin menemukan
singkatan -t
(aktif) atau -t-
(nonaktif)
yang praktis untuk mengganti default pada 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](#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 secara signifikan lebih lama dari waktu eksekusi pengujian yang sebenarnya. Meskipun waktu tunggu pengujian harus ditetapkan agar tidak bermasalah, pengujian yang memiliki waktu tunggu yang sangat lama 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 pemeriksaan keandalan nilai waktu tunggu yang ada.
--[no]test_keep_going
Secara default, semua pengujian dijalankan hingga selesai. Namun, jika tanda ini dinonaktifkan,
build akan dibatalkan pada pengujian yang tidak lulus. Langkah build berikutnya
dan pemanggilan pengujian tidak akan dijalankan, dan pemanggilan yang sedang berlangsung akan dibatalkan.
Jangan menentukan --notest_keep_going
dan --keep_going
.
--flaky_test_attempts=attempts
Opsi ini menentukan berapa kali maksimum pengujian harus dicoba jika gagal karena alasan apa pun. Pengujian yang awalnya gagal, tetapi akhirnya
berhasil dilaporkan sebagai FLAKY
pada ringkasan pengujian. Namun,
kode ini dianggap lulus jika menyangkut identifikasi kode keluar Bazel
atau jumlah total pengujian yang lulus. Pengujian yang gagal dalam semua percobaan yang diizinkan dianggap gagal.
Secara default (jika opsi ini tidak ditentukan, atau jika 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 percobaan pengujian untuk mencegah penyalahgunaan sistem.
--runs_per_test=[regex@]number
Opsi ini menentukan frekuensi 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 flag --runs_per_test_detects_flakes
:
- Jika tidak ada, kegagalan operasi akan menyebabkan seluruh pengujian gagal.
- Jika ada dan dua operasi dari shard yang sama menampilkan PASS dan FAIL, pengujian akan menerima status tidak stabil (kecuali jika operasi lain yang gagal menyebabkannya gagal).
Jika satu angka ditentukan, semua pengujian akan berjalan sebanyak itu.
Atau, ekspresi reguler dapat ditentukan menggunakan sintaksis
regex@number. Hal ini membatasi efek --runs_per_test
ke target
yang cocok dengan ekspresi reguler (--runs_per_test=^//pizza:.*@4
menjalankan semua pengujian
di bawah //pizza/
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 operasi untuk satu shard gagal dan satu atau beberapa operasi untuk shard yang sama berhasil, target akan dianggap tidak stabil dengan flag. Jika tidak ditentukan, target akan melaporkan
status gagal.
--test_summary=output_style
Menentukan cara ringkasan hasil pengujian ditampilkan.
short
mencetak hasil setiap pengujian beserta nama file yang berisi output pengujian jika pengujian gagal. Ini adalah nilai defaultnya.terse
sepertishort
, tetapi lebih singkat: hanya mencetak informasi tentang pengujian yang tidak lulus.detailed
mencetak setiap kasus pengujian individual yang gagal, bukan hanya setiap pengujian. Nama file output pengujian dihilangkan.none
tidak mencetak ringkasan pengujian.
--test_output=output_style
Menentukan cara output pengujian 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
hanya mengirimkan output stdout/stderr gabungan dari pengujian yang gagal ke stdout segera setelah pengujian selesai, memastikan bahwa output pengujian dari pengujian simultan tidak saling tumpang-tindih. Mencetak ringkasan pada build sesuai dengan output ringkasan di atas.all
mirip denganerrors
, tetapi mencetak output untuk semua pengujian, termasuk yang lulus.streamed
melakukan streaming output stdout/stderr dari setiap pengujian secara real-time.
--java_debug
Opsi ini menyebabkan virtual machine 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, serta akan
diformat agar tetap dalam 80 karakter jika memungkinkan.
--test_tmpdir=path
Menentukan direktori sementara untuk pengujian yang dijalankan secara lokal. Setiap pengujian akan
dijalankan 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.
--test_timeout=seconds
ATAU --test_timeout=seconds,seconds,seconds,seconds
Mengganti nilai waktu tunggu untuk semua pengujian dengan menggunakan jumlah detik yang ditentukan sebagai nilai waktu tunggu baru. Jika hanya satu nilai yang diberikan, nilai tersebut akan digunakan untuk semua kategori waktu tunggu pengujian.
Atau, empat nilai yang dipisahkan koma dapat diberikan, yang menentukan waktu tunggu 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 tunggunya sebagai berbeda dari ukuran akan menerima nilai yang sama seolah-olah waktu tunggu tersebut telah ditetapkan secara implisit oleh tag ukuran. Jadi, pengujian berukuran 'kecil' yang mendeklarasikan waktu tunggu 'lama' akan memiliki waktu tunggu efektif yang sama dengan pengujian 'besar' tanpa waktu tunggu eksplisit.
--test_arg=arg
Meneruskan opsi/flag/argumen command line ke setiap proses pengujian. Opsi
ini dapat digunakan beberapa kali untuk meneruskan beberapa argumen. Misalnya,
--test_arg=--logtostderr --test_arg=--v=3
.
--test_env=variable=_value_
ATAU --test_env=variable
Menentukan variabel tambahan yang harus dimasukkan ke dalam lingkungan
pengujian untuk setiap pengujian. Jika value tidak ditentukan, value akan
diwarisi dari lingkungan shell yang digunakan untuk memulai perintah
bazel test
.
Lingkungan dapat diakses dari dalam pengujian menggunakan
System.getenv("var")
(Java), getenv("var")
(C atau C++),
--run_under=command-prefix
Ini menentukan awalan yang akan disisipkan runner pengujian di depan perintah pengujian sebelum menjalankannya. command-prefix dibagi menjadi beberapa kata menggunakan aturan tokenisasi shell Bourne, 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 dengan PATH di lingkungan Anda,
sehingga Anda mungkin perlu menggunakan jalur absolut untuk perintah
--run_under
(kata pertama dalam command-prefix). stdin
tidak terhubung, sehingga--run_under
tidak dapat digunakan untuk perintah interaktif.
Contoh:
--run_under=/usr/bin/strace --run_under='/usr/bin/strace -c' --run_under=/usr/bin/valgrind --run_under='/usr/bin/valgrind --quiet --num-callers=20'
Pilihan pengujian
Seperti yang didokumentasikan di bagian Opsi pemilihan output, Anda dapat memfilter pengujian berdasarkan ukuran, waktu tunggu, tag, atau bahasa. Filter nama umum yang praktis dapat meneruskan argumen filter tertentu ke runner pengujian.
Opsi lain untuk bazel test
Sintaksis dan opsi lainnya sama persis dengan
bazel build
.
Menjalankan file yang dapat dieksekusi
Perintah bazel run
mirip dengan bazel build
, kecuali
perintah ini digunakan untuk mem-build dan menjalankan satu target. Berikut adalah sesi umumnya:
% bazel run java/myapp:myapp -- --arg1 --arg2 Welcome to Bazel INFO: Loading package: java/myapp INFO: Loading package: foo/bar INFO: Loading complete. Analyzing... INFO: Found 1 target... ... Target //java/myapp:myapp up-to-date: bazel-bin/java/myapp:myapp INFO: Elapsed time: 0.638s, Critical Path: 0.34s INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2 Hello there $EXEC_ROOT/java/myapp/myapp --arg1 --arg2
bazel run
mirip, tetapi tidak identik, dengan memanggil
biner yang di-build oleh Bazel secara langsung dan perilakunya berbeda-beda, bergantung pada apakah
biner yang akan dipanggil adalah pengujian atau bukan.
Jika biner bukan pengujian, direktori kerja saat ini akan menjadi hierarki runfile biner.
Jika biner merupakan pengujian, direktori kerja saat ini akan menjadi root exec
dan upaya dengan niat baik akan dilakukan untuk mereplikasi pengujian lingkungan biasanya
dijalankan. Namun, emulasi ini tidak sempurna, dan pengujian yang memiliki beberapa
shard tidak dapat dijalankan dengan cara ini (opsi
command line --test_sharding_strategy=disabled
dapat digunakan
untuk mengatasi hal ini)
Variabel lingkungan tambahan berikut juga tersedia untuk biner:
BUILD_WORKSPACE_DIRECTORY
: root ruang kerja tempat build dijalankan.BUILD_WORKING_DIRECTORY
: direktori kerja saat ini tempat Bazel dijalankan.
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 akan mencetak output logging dari Bazel
itu sendiri dan biner yang sedang dipanggil. 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 dalam perkiraan yang mendekati lingkungan seperti yang dijelaskan dalam Menulis Pengujian. Perhatikan bahwa tidak ada argumen --test_*
yang berpengaruh saat menjalankan pengujian dengan cara ini, kecuali --test_arg
.
Membersihkan output build
Perintah clean
Bazel memiliki perintah clean
, yang mirip dengan perintah 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 instance Bazel dikaitkan dengan satu ruang kerja, sehingga
perintah clean
akan menghapus semua output dari semua build yang telah Anda lakukan
dengan instance Bazel tersebut di ruang kerja tersebut.
Untuk sepenuhnya menghapus seluruh hierarki kerja yang dibuat oleh instance
Bazel, Anda dapat menentukan opsi --expunge
. Saat
dijalankan dengan --expunge
, perintah bersih hanya
menghapus seluruh hierarki dasar output yang, selain output
build, berisi semua file sementara yang dibuat oleh Bazel. Perintah ini juga menghentikan server Bazel setelah pembersihan, yang setara dengan perintah shutdown
. Misalnya, untuk
menghapus semua rekaman aktivitas disk dan memori dari instance Bazel, Anda dapat
menentukan:
% bazel clean --expunge
Atau, Anda dapat menghapus di latar belakang menggunakan
--expunge_async
. Anda dapat memanggil perintah Bazel di klien yang sama saat penghapusan asinkron terus berjalan.
Perintah clean
disediakan terutama sebagai cara untuk
mengambil kembali ruang disk untuk ruang kerja yang tidak lagi diperlukan.
Build ulang inkremental Bazel mungkin tidak
sempurna sehingga clean
dapat digunakan untuk memulihkan status
yang konsisten saat masalah muncul.
Desain Bazel sedemikian rupa sehingga masalah ini dapat diperbaiki dan
bug ini adalah prioritas tinggi untuk diperbaiki. Jika Anda
pernah menemukan build inkremental yang salah, ajukan laporan bug, dan laporkan bug di alat
bukan menggunakan clean
.
Membuat kueri grafik dependensi
Bazel menyertakan bahasa kueri untuk mengajukan pertanyaan tentang grafik dependensi yang digunakan selama build. Bahasa kueri digunakan oleh dua perintah: kueri dan cquery. Perbedaan utama antara kedua perintah tersebut adalah kueri berjalan setelah fase pemuatan dan cquery berjalan setelah fase analisis. Alat-alat ini adalah bantuan yang sangat berharga untuk banyak tugas software engineering.
Bahasa kueri didasarkan pada gagasan tentang operasi aljabar di atas grafik; didokumentasikan secara rinci dalam
Referensi Kueri Bazel. Lihat dokumen tersebut sebagai referensi, untuk contoh, dan opsi command line khusus kueri.
Alat kueri menerima beberapa opsi command line. --output
memilih format output.
--[no]keep_going
(dinonaktifkan secara default) menyebabkan alat kueri
terus membuat progres saat terjadi error; perilaku ini dapat
dinonaktifkan jika hasil yang tidak lengkap tidak dapat diterima jika terjadi error.
Opsi --[no]tool_deps
,
yang diaktifkan secara default, menyebabkan dependensi dalam konfigurasi non-target disertakan dalam
grafik dependensi tempat kueri beroperasi.
Opsi --[no]implicit_deps
, yang diaktifkan secara default, menyebabkan dependensi implisit disertakan dalam grafik dependensi tempat kueri beroperasi. Dependensi
implisit adalah dependensi yang tidak ditentukan secara eksplisit dalam file BUILD
tetapi ditambahkan oleh bazel.
Contoh: "Tampilkan lokasi definisi (dalam file BUILD) semua genrules yang diperlukan untuk membuat semua pengujian di hierarki PEBL."
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
Membuat kueri grafik tindakan
Perintah aquery
memungkinkan Anda membuat kueri untuk tindakan dalam grafik build.
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 kueri berjalan di atas build Bazel biasa dan mewarisi
serangkaian opsi yang tersedia selama build.
Fungsi ini mendukung kumpulan fungsi yang sama yang juga tersedia untuk
query
tradisional, tetapi siblings
, buildfiles
, dan
tests
.
Untuk mengetahui detail selengkapnya, lihat Kueri Action Graph.
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 perintah
shutdown
. 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, tindakan ini akan membuat penonaktifan
bergantung 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 wajar
terkadang; melakukan mulai ulang bersyarat akan mencegah kondisi ini.
info
Perintah info
mencetak berbagai nilai yang terkait dengan
instance server Bazel, atau dengan konfigurasi build tertentu.
(Ini dapat digunakan oleh skrip yang mendorong build.)
Perintah info
juga mengizinkan satu argumen
(opsional), yang merupakan nama salah satu kunci dalam daftar di bawah.
Dalam hal ini, bazel info key
hanya akan mencetak
nilai untuk satu kunci tersebut. (Hal ini sangat praktis saat
membuat skrip Bazel, karena tidak perlu menyalurkan hasilnya
melalui sed -ne /key:/s/key://p
:
Data yang tidak bergantung pada konfigurasi
release
: label rilis untuk instance Bazel ini, atau "versi pengembangan" jika ini bukan biner yang dirilis.workspace
jalur absolut ke direktori ruang kerja dasar.install_base
: jalur absolut ke direktori penginstalan yang digunakan oleh instance Bazel ini untuk pengguna saat ini. Bazel menginstal file yang dapat dieksekusi yang diperlukan secara internal di bawah direktori ini.output_base
: jalur absolut ke direktori output dasar yang digunakan oleh instance Bazel ini untuk kombinasi workspace dan pengguna saat ini. Bazel menempatkan semua output awal dan build di bawah direktori ini.execution_root
: jalur absolut ke direktori root eksekusi pada output_base. Direktori ini adalah root untuk semua file yang dapat diakses oleh perintah yang dieksekusi selama build, dan merupakan direktori kerja untuk perintah tersebut. Jika direktori ruang kerja dapat ditulis, symlink bernamabazel-<workspace>
akan ditempatkan di sana yang mengarah ke direktori ini.output_path
: jalur absolut ke direktori output di bawah root eksekusi yang digunakan untuk semua file yang benar-benar dibuat sebagai hasil dari perintah build. Jika direktori ruang kerja dapat ditulis, symlink bernamabazel-out
akan ditempatkan di sana yang mengarah ke direktori ini.server_pid
: ID proses proses server Bazel.server_log
: jalur absolut ke file log debug server Bazel. File ini berisi informasi proses debug untuk semua perintah selama masa pakai server Bazel, dan ditujukan untuk digunakan oleh manusia oleh developer 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 menjalankanbazel 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
.used-heap-size
,committed-heap-size
,max-heap-size
: melaporkan berbagai parameter ukuran heap JVM. Masing-masing: memori yang saat ini digunakan, memori yang saat ini dijamin tersedia untuk JVM dari sistem, alokasi maksimum yang memungkinkan.gc-count
,gc-time
: Jumlah kumulatif pembersihan sampah memori sejak dimulainya server Bazel ini dan waktu yang dihabiskan untuk menjalankannya. Perhatikan bahwa nilai ini tidak direset di awal setiap build.package_path
: Daftar jalur yang dipisahkan titik dua yang akan ditelusuri paket oleh bazel. Memiliki format yang sama 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 direktoribazel-*
tempat program yang dihasilkan oleh build berada. Hal ini biasanya, meskipun tidak selalu, sama dengan symlinkbazel-*
yang dibuat di direktori ruang kerja dasar setelah build berhasil. Namun, jika direktori ruang kerja hanya dapat dibaca, tidak ada symlinkbazel-*
yang dapat dibuat. Skrip yang menggunakan nilai yang dilaporkan olehbazel info
, bukan mengasumsikan adanya symlink, akan lebih andal.- Lingkungan "Make" lengkap. Jika flag
--show_make_env
ditentukan, semua variabel di lingkungan "Make" konfigurasi saat ini juga akan ditampilkan (sepertiCC
,GLIBC_VERSION
, dll.). Ini adalah variabel yang diakses menggunakan sintaksis$(CC)
atauvarref("CC")
di dalam file BUILD.
Contoh: compiler C++ untuk konfigurasi saat ini.
Ini adalah variabel $(CC)
di lingkungan "Make",
sehingga flag --show_make_env
diperlukan.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
Contoh: direktori output bazel-bin
untuk konfigurasi
saat ini. Hal ini dijamin 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 biner Bazel yang di-build, termasuk daftar perubahan tempat biner tersebut di-build dan tanggalnya. Hal ini sangat berguna dalam menentukan apakah Anda memiliki Bazel terbaru, atau jika Anda melaporkan bug. Beberapa nilai yang menarik adalah:
changelist
: daftar perubahan tempat versi Bazel ini dirilis.label
: label rilis untuk instance Bazel ini, atau "versi pengembangan" jika ini bukan biner yang dirilis. Sangat berguna saat melaporkan bug.
bazel --version
, tanpa argumen lain, akan menghasilkan output yang sama dengan
bazel version --gnu_format
, kecuali tanpa efek samping yang berpotensi memulai
server Bazel atau mengekstrak arsip server. bazel --version
dapat dijalankan dari mana saja, dan tidak memerlukan direktori ruang kerja.
mobile-install
Perintah mobile-install
menginstal aplikasi ke perangkat seluler.
Saat ini, hanya perangkat Android yang menjalankan ART yang didukung.
Lihat bazel mobile-install untuk informasi selengkapnya.
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
yang direferensikan dari AndroidManifest.xml
, kode native, atau resource
Java (seperti yang direferensikan oleh Class.getResource()
). Jika hal
ini berubah, opsi ini harus dihilangkan. Berbeda dengan semangat Bazel
dan karena keterbatasan platform Android, pengguna bertanggung jawab
untuk mengetahui kapan perintah ini 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 status bersih setelah menginstal. Setara dengan --start=COLD
.
--debug_app
Menunggu debugger dilampirkan sebelum memulai aplikasi dalam status bersih setelah menginstal.
Setara dengan --start=DEBUG
.
--start=_start_type_
Cara aplikasi harus dimulai setelah diinstal. _start_type_ yang didukung adalah:
NO
Tidak memulai aplikasi. Ini adalah setelan default.COLD
Memulai aplikasi dari status bersih setelah penginstalan.WARM
Mempertahankan dan memulihkan status aplikasi pada penginstalan inkremental.DEBUG
Menunggu debugger sebelum memulai aplikasi dalam status bersih setelah diinstal.
--adb=path
Menunjukkan biner adb
yang akan digunakan.
Defaultnya adalah menggunakan adb di Android SDK yang ditentukan oleh
--android_sdk
.
--adb_arg=serial
Argumen tambahan untuk adb
. Perintah ini muncul sebelum subperintah di
command line dan biasanya digunakan untuk menentukan perangkat yang akan diinstal.
Misalnya, untuk memilih perangkat Android atau emulator yang akan digunakan:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
memanggil adb
sebagai
adb -s deadbeef install ...
--incremental_install_verbosity=number
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 default, perintah hanya akan mencetak pesan bantuan yang menguraikan kemungkinan opsi untuk membuang area tertentu dari status Bazel. Untuk membuang status internal, setidaknya salah satu opsi harus ditentukan.
Opsi berikut didukung:
--action_cache
membuang konten cache tindakan.--packages
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, penggunaan memori aturan juga akan dicetak.--skylark_memory
membuang file .gz yang kompatibel dengan pprof ke jalur yang ditentukan. Anda harus mengaktifkan pelacakan memori agar fitur ini berfungsi.
Pelacakan memori
Beberapa perintah dump
memerlukan pelacakan memori. Untuk mengaktifkannya, Anda harus meneruskan
flag startup ke Bazel:
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.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 dimulai ulang.
Contoh:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
Perintah analyze-profile
menganalisis data yang sebelumnya dikumpulkan
selama build menggunakan opsi --profile
. Alat ini menyediakan beberapa
opsi untuk melakukan analisis eksekusi build atau mengekspor data dalam
format yang ditentukan.
Opsi berikut ini didukung:
--dump
menampilkan semua data yang dikumpulkan dalam format yang dapat dibaca manusia. Namun, format ini belum mendukung format lain.
Untuk mengetahui detail format dan bantuan penggunaan, lihat Memecahkan masalah performa dengan pembuatan profil.
canonicalize-flags
Perintah canonicalize-flags
, yang mengambil daftar opsi untuk perintah Bazel dan menampilkan daftar
opsi dengan efek yang 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 akan menyebabkan error.
Sebagai contoh:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
Opsi startup
Opsi yang dijelaskan di bagian ini memengaruhi pengaktifan mesin virtual Java yang digunakan oleh proses server Bazel dan berlaku untuk semua perintah berikutnya yang ditangani oleh server tersebut. Jika ada server Bazel yang sudah berjalan dan opsi pengaktifan tidak cocok, server tersebut akan dimulai ulang.
Semua opsi yang dijelaskan di bagian ini harus ditentukan menggunakan sintaksis --key=value
atau --key value
. Selain itu, opsi ini harus muncul sebelum nama perintah
Bazel. Gunakan startup --key=value
untuk mencantumkannya dalam file .bazelrc
.
--output_base=dir
Opsi ini memerlukan argumen jalur, yang harus menentukan direktori yang dapat ditulis. Bazel akan menggunakan lokasi ini untuk menulis semua output-nya. Basis output juga merupakan kunci yang digunakan klien untuk menemukan server Bazel. Dengan mengubah basis output, Anda mengubah server yang akan menangani perintah.
Secara default, basis output berasal dari nama login pengguna,
dan nama direktori ruang kerja (sebenarnya, ringkasan MD5-nya),
sehingga nilai tipikal terlihat seperti:
/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
.
Contoh:
OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base % bazel --output_base ${OUTPUT_BASE}1 build //foo & bazel --output_base ${OUTPUT_BASE}2 build //bar
Dalam perintah ini, kedua perintah Bazel berjalan secara serentak (karena
operator &
shell), masing-masing menggunakan instance server
Bazel yang berbeda (karena basis output yang berbeda).
Sebaliknya, jika basis output default digunakan di kedua perintah,
kedua permintaan akan dikirim ke server yang sama, yang akan
menanganinya secara berurutan: mem-build //foo
terlebih dahulu, diikuti
dengan build inkremental //bar
.
--output_user_root=dir
Menunjuk ke direktori utama tempat output dan basis penginstalan dibuat. Direktori tidak boleh ada atau dimiliki oleh pengguna yang memanggil. Sebelumnya, hal ini diizinkan untuk mengarah ke direktori yang dibagikan di antara berbagai pengguna, tetapi tidak lagi diizinkan. Hal ini dapat diizinkan setelah masalah #11100 diatasi.
Jika ditentukan, opsi --output_base
akan menggantikan
opsi --output_user_root
untuk menghitung basis output.
Lokasi basis penginstalan dihitung berdasarkan
--output_user_root
, ditambah identitas MD5 dari biner yang disematkan
Bazel.
Anda dapat menggunakan opsi --output_user_root
untuk memilih
lokasi dasar alternatif untuk semua output Bazel (dasar penginstalan dan basis
output) jika ada lokasi yang lebih baik dalam tata letak sistem file.
--server_javabase=dir
Menentukan virtual machine Java tempat Bazel itu sendiri berjalan. Nilai harus berupa jalur ke direktori yang berisi JDK atau JRE. Tidak boleh berupa label. Opsi ini harus muncul sebelum perintah Bazel apa pun, misalnya:
% bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
Tanda ini tidak memengaruhi JVM yang digunakan oleh subproses Bazel seperti aplikasi, pengujian, alat, dan sebagainya. Gunakan opsi build --javabase atau --host_javabase sebagai gantinya.
Flag ini sebelumnya bernama --host_javabase
(terkadang disebut sebagai
--host_javabase
'sisi kiri'), tetapi diganti namanya untuk menghindari kebingungan dengan
flag build --host_javabase (terkadang disebut sebagai
--host_javabase
'sisi kanan').
--host_jvm_args=string
Menentukan opsi startup yang akan diteruskan ke virtual machine Java tempat Bazel itu sendiri berjalan. Ini dapat digunakan untuk menyetel ukuran tumpukan, misalnya:
% bazel --host_jvm_args="-Xss256K" build //foo
Opsi ini dapat digunakan beberapa kali dengan argumen individual. Perhatikan bahwa menetapkan tanda ini 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.
Hal ini tidak memengaruhi JVM apa pun yang digunakan oleh
subproses Bazel: aplikasi, pengujian, alat, dan sebagainya. Untuk meneruskan
opsi JVM ke program Java yang dapat dieksekusi, baik yang dijalankan oleh bazel
run
maupun di command line, Anda harus menggunakan
argumen --jvm_flags
yang
didukung oleh semua program
java_binary
dan java_test
. Atau untuk pengujian, gunakan bazel test --test_arg=--jvm_flags=foo ...
.
--host_jvm_debug
Opsi ini menyebabkan virtual machine Java menunggu koneksi dari debugger yang kompatibel dengan JDWP sebelum memanggil metode utama Bazel itu sendiri. Hal ini terutama dimaksudkan untuk digunakan oleh developer Bazel.
--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 proses java bazel untuk satu perintah, yang telah digunakan untuk semantik yang lebih dapat diprediksi sehubungan dengan penanganan sinyal, kontrol tugas, dan warisan variabel lingkungan, 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. Hal ini karena, di antara hal lainnya, cache file build berada di memori, sehingga tidak 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.
--max_idle_secs=n
Opsi ini menentukan berapa lama, dalam detik, proses server Bazel
harus menunggu setelah permintaan klien terakhir, sebelum keluar. Nilai
defaultnya adalah 10800 (3 jam). --max_idle_secs=0
akan menyebabkan
proses server Bazel tetap ada tanpa batas waktu.
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
memanggil bazel query
untuk memastikan bahwa perubahan pending
pengguna tidak menyebabkan 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 diaktifkan dan --max_idle_secs
disetel ke durasi positif,
setelah server build tidak ada aktivitas selama beberapa saat, matikan server saat sistem
kekurangan memori. Khusus Linux.
Selain menjalankan pemeriksaan tidak ada aktivitas yang sesuai dengan max_idle_secs, server build akan mulai memantau memori sistem yang tersedia setelah server tidak ada aktivitas selama beberapa waktu. Jika memori sistem yang tersedia menjadi sangat rendah, server akan keluar.
--[no]block_for_lock
Jika diaktifkan, Bazel akan menunggu perintah Bazel lain yang memegang kunci server selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan keluar dengan error jika tidak dapat segera memperoleh kunci dan melanjutkan.
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 tingkat dari 0-7 untuk penjadwalan IO upaya terbaik. 0 adalah prioritas tertinggi, 7 adalah prioritas terendah. Penjadwal antisipatif hanya dapat memenuhi hingga prioritas 4. Nilai negatif akan diabaikan.
--batch_cpu_scheduling
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 interaktivitas sistem
yang lebih baik dengan mengorbankan throughput Bazel.
Opsi lainnya
--[no]announce_rc
Mengontrol apakah Bazel mengumumkan opsi perintah yang dibaca dari file bazelrc saat memulai. (Opsi startup diumumkan tanpa syarat.)
--color (yes|no|auto)
Opsi ini menentukan apakah Bazel akan menggunakan warna untuk menyoroti outputnya 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 merujuk ke
definisi lain (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. Hal ini berfungsi dengan baik dengan
--color
.
Jika opsi ini disetel ke yes
, penggunaan kontrol kursor akan diaktifkan.
Jika opsi ini disetel ke no
, penggunaan kontrol kursor akan dinonaktifkan.
Jika opsi ini ditetapkan ke auto
, penggunaan kontrol kursor akan
diaktifkan dalam kondisi yang sama seperti untuk --color=auto
.
--[no]show_timestamps
Jika ditentukan, stempel waktu akan ditambahkan ke setiap pesan yang dihasilkan oleh Bazel yang menentukan waktu saat pesan ditampilkan.