Halaman ini membahas opsi yang tersedia
dengan berbagai perintah Bazel,
seperti bazel build
, bazel run
, dan bazel test
. Halaman ini merupakan pengiring
ke daftar perintah Bazel di Build with Bazel.
Sintaksis target
Beberapa perintah, seperti build
atau test
, dapat beroperasi pada daftar target. Mereka
menggunakan sintaks yang lebih fleksibel
daripada label, yang didokumentasikan dalam
Menentukan target yang akan di-build.
Opsi
Bagian berikut menjelaskan opsi yang tersedia selama proses
buat. Saat --long
digunakan pada perintah bantuan, jenis server tersebut
pesan bantuan memberikan informasi ringkasan
tentang arti, jenis dan
untuk setiap opsi.
Sebagian besar opsi hanya dapat ditentukan sekali. Jika ditentukan beberapa kali, instance terakhir menang. Opsi yang dapat ditentukan beberapa kali adalah yang diidentifikasi dalam bantuan online dengan teks 'dapat digunakan beberapa kali'.
Lokasi paket
--package_path
Opsi ini menentukan kumpulan direktori yang dicari untuk menemukan file {i>BUILD<i} untuk paket tertentu.
Bazel menemukan paketnya dengan mencari jalur paket. Ini adalah tanda titik dua daftar direktori {i>bazel<i} yang diurutkan, masing-masing menjadi {i>root<i} 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 pertama adalah
/
, jalur tersebut bersifat absolut. - Jika jalur dimulai dengan
%workspace%
, jalur akan diambil secara relatif ke direktori {i>bazel<i} yang berdekatan. Misalnya, jika direktori kerja Anda adalah/home/bob/clients/bob_client/bazel/foo
, maka string%workspace%
di jalur paket diperluas ke/home/bob/clients/bob_client/bazel
. - Yang lainnya akan diambil terkait dengan direktori kerja.
Biasanya ini bukanlah
yang Anda maksud,
dan mungkin berperilaku tidak terduga jika Anda menggunakan Bazel dari direktori di bawah ruang kerja bazel.
Misalnya, jika Anda menggunakan elemen jalur paket
.
, dan kemudian {i>cd<i} 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 mengharuskan paket apa pun berada di direktori saat ini, sehingga Anda dapat melakukan build dari bazel kosong {i>workspace<i} jika semua paket yang diperlukan dapat ditemukan di tempat lain pada jalur paket.
Contoh: Membangun 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 dengan koma Bazel harus mempertimbangkan dihapus, dan tidak mencoba untuk memuat dari direktori mana pun pada jalur paket. Ini dapat digunakan untuk menyimulasikan penghapusan paket tanpa benar-benar menghapusnya.
Terjadi error saat memeriksa
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 {i>default<i} opsi ini adalah true, sehingga secara {i>default<i}, visibilitas pemeriksaan selesai.
--output_filter=regex
Opsi --output_filter
hanya akan menampilkan build dan kompilasi
peringatan untuk target yang cocok dengan ekspresi reguler. Jika target tidak
cocok dengan ekspresi reguler yang diberikan dan eksekusinya berhasil,
{i>output<i} dan {i>standard error<i}
akan dibuang.
Berikut beberapa nilai standar untuk opsi ini:
`--output_filter='^//(first/project|second/project):'` | Menampilkan output untuk paket yang ditentukan. |
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` | Tidak menampilkan output untuk paket yang ditentukan. |
`--output_filter=` | Tampilkan semuanya. |
`--output_filter=DONT_MATCH_ANYTHING` | Jangan tampilkan apa pun. |
Flag alat
Opsi ini mengontrol opsi mana yang akan diteruskan Bazel ke alat lain.
--copt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler. Argumen akan diteruskan ke compiler setiap kali dipanggil untuk pra-pemrosesan, kompilasi, dan/atau penyusunan C, C++, atau kode assembler. ID ini tidak akan diteruskan saat ditautkan.
Opsi ini dapat digunakan beberapa kali. Contoh:
% bazel build --copt="-g0" --copt="-fpic" //foo
akan mengompilasi library foo
tanpa tabel debug, sehingga menghasilkan
kode yang tidak bergantung posisi.
--host_copt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber
yang dikompilasi dalam
konfigurasi {i>host<i}. Hal ini setara dengan
opsi --copt
, tetapi hanya berlaku untuk
konfigurasi {i>host<i}.
--host_conlyopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber C
yang dikompilasi dalam
konfigurasi {i>host<i}. Hal ini setara dengan
opsi --conlyopt
, tetapi hanya berlaku
ke konfigurasi {i>host<i}.
--host_cxxopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler untuk file sumber C++
yang dikompilasi dalam
konfigurasi {i>host<i}. Hal ini setara dengan
opsi --cxxopt
, tetapi hanya berlaku untuk
konfigurasi {i>host<i}.
--host_linkopt=linker-option
Opsi ini menggunakan argumen yang akan diteruskan ke penaut untuk file sumber
yang dikompilasi dalam
konfigurasi {i>host<i}. Hal ini setara dengan
opsi --linkopt
, tetapi hanya berlaku untuk
konfigurasi {i>host<i}.
--conlyopt=cc-option
Opsi ini menggunakan argumen yang akan diteruskan ke compiler saat mengompilasi file sumber C.
Ini mirip dengan --copt
, tetapi hanya berlaku untuk kompilasi C,
bukan ke kompilasi atau penautan C++. Jadi, Anda bisa meneruskan opsi spesifik C
(seperti -Wno-pointer-sign
) dengan menggunakan --conlyopt
.
--cxxopt=cc-option
Opsi ini mengambil argumen yang akan diteruskan ke kompiler ketika mengompilasi file sumber C++.
Ini mirip dengan --copt
, tetapi hanya berlaku untuk kompilasi C++,
bukan ke kompilasi atau penautan C. Agar 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 ke kompilasi. Jadi Anda dapat meneruskan opsi compiler yang hanya masuk akal
pada waktu penautan (seperti -lssp
atau -Wl,--wrap,abort
)
menggunakan --linkopt
. Contoh:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
Aturan build juga dapat menentukan opsi link di atributnya. Opsi ini setelan 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 menggunakan opsi -Wl,--strip-debug
.
--strip=always
berarti selalu menghapus informasi proses debug.
--strip=never
berarti tidak pernah menghapus informasi proses debug.
Nilai default --strip=sometimes
berarti strip jika --compilation_mode
adalah fastbuild
.
% bazel build --strip=always //foo:bar
akan mengompilasi target sambil menghapus informasi proses debug dari semua file yang biner.
Opsi --strip
Bazel sesuai dengan opsi --strip-debug
ld:
perintah itu hanya menghilangkan
informasi {i>debugging<i}. Jika karena alasan tertentu Anda ingin menghilangkan semua simbol,
tidak hanya simbol debug, Anda harus menggunakan opsi --strip-all
ld,
yang dapat Anda lakukan dengan meneruskan --linkopt=-Wl,--strip-all
ke Bazel. Juga menjadi
perlu diketahui bahwa menyetel flag --strip
Bazel akan mengganti
--linkopt=-Wl,--strip-all
, jadi sebaiknya hanya tetapkan salah satunya.
Jika Anda hanya membangun satu biner dan ingin semua simbol dihapus, Anda juga dapat
teruskan --stripopt=--strip-all
dan bangun secara eksplisit
//foo:bar.stripped
versi target. Seperti yang dijelaskan pada bagian
--stripopt
, ini akan menerapkan tindakan pengosongan setelah biner akhir
ditautkan daripada menyertakan stripping di semua tindakan tautan build.
--stripopt=strip-option
Ini adalah opsi tambahan untuk diteruskan ke perintah strip
saat membuat
biner *.stripped
. Defaultnya
adalah -S -p
. Opsi ini dapat digunakan beberapa kali.
--fdo_instrument=profile-output-dir
Opsi --fdo_instrument
memungkinkan pembuatan
Output profil FDO (pengoptimalan yang diarahkan masukan) saat
biner C/C++ yang telah dibuat. Untuk GCC, argumen yang diberikan akan digunakan sebagai
awalan direktori untuk hierarki direktori file per objek dari file .gcda
yang berisi informasi profil untuk setiap file .o.
Setelah hierarki data profil dibuat, hierarki profil
harus di-zip, dan diberikan kepada
--fdo_optimize=profile-zip
Opsi Bazel untuk mengaktifkan kompilasi yang dioptimalkan FDO.
Untuk compiler LLVM, argumennya juga merupakan direktori tempat profil LLVM mentah
file data dibuang. Contoh: --fdo_instrument=/path/to/rawprof/dir/
Opsi --fdo_instrument
dan --fdo_optimize
tidak dapat digunakan secara bersamaan.
--fdo_optimize=profile-zip
Opsi --fdo_optimize
memungkinkan penggunaan
informasi profil file per objek untuk
melakukan FDO (umpan balik
pengoptimalan terarah) saat mengompilasi. Untuk GCC, argumennya
adalah file zip yang berisi hierarki file yang dibuat sebelumnya
file .gcda yang berisi informasi profil untuk setiap file .o.
Atau, argumen yang diberikan dapat mengarah ke profil otomatis yang diidentifikasi dengan ekstensi .afdo.
Untuk compiler LLVM, argumen yang diberikan harus mengarah ke LLVM yang diindeks file output profil yang disiapkan oleh alat llvm-profdata, dan harus memiliki .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 C++ yang dapat dieksekusi akan menghasilkan
file jumlah simbol (melalui --print-symbol-counts
gold
). Untuk setiap input penaut, file mencatat jumlah simbol yang
didefinisikan 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 akan menentukan versi sumber Java. Contoh:
% bazel build --java_language_version=8 java/com/example/common/foo:all
mengompilasi dan hanya mengizinkan konstruksi yang kompatibel dengan spesifikasi Java 8.
Nilai defaultnya adalah 11. -->
Nilai yang mungkin adalah: 8, 9, 10, 11, 14, dan 15 dan dapat diperpanjang dengan
mendaftarkan toolchain Java kustom menggunakan default_java_toolchain
.
--tool_java_language_version=version
Versi bahasa Java yang digunakan untuk membangun alat yang dijalankan selama pembangunan. Nilai defaultnya adalah 11.
--java_runtime_version=version
Opsi ini menentukan versi JVM yang akan digunakan untuk menjalankan kode dan menjalankan pengujian. Contoh:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
mengunduh JDK 11 dari repositori jarak jauh dan menjalankan aplikasi Java menggunakannya.
Nilai defaultnya adalah localjdk
.
Nilai yang mungkin adalah: localjdk
, localjdk_version
,
remotejdk_11
, dan remote_jdk17
.
Anda dapat memperluas nilainya dengan mendaftarkan JVM kustom menggunakan
local_java_repository
atau remote_java_repostory
aturan repositori.
--tool_java_runtime_version=version
Versi JVM yang digunakan untuk menjalankan alat yang diperlukan selama build.
Nilai defaultnya adalah remotejdk_11
.
--jvmopt=jvm-option
Opsi ini memungkinkan argumen opsi untuk diteruskan ke VM Java. Dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:
% bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
akan menggunakan VM server untuk meluncurkan semua biner Java dan menyetel ukuran heap startup untuk VM menjadi 256 MB.
--javacopt=javac-option
Opsi ini memungkinkan argumen opsi diteruskan ke javac. Dapat digunakan dengan satu argumen besar, atau beberapa kali dengan argumen individual. Contoh:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
akan membangun ulang java_binary dengan info debug default javac (bukan default bazel).
Opsi diteruskan ke javac setelah opsi {i>default<i} bawaan Bazel untuk javac dan sebelum opsi per aturan. Spesifikasi terakhir dari pilihan apa pun untuk javac. Opsi default untuk javac adalah:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
Opsi ini mengontrol apakah javac memeriksa dependensi langsung yang tidak ada. Target Java harus secara eksplisit mendeklarasikan semua target yang digunakan secara langsung sebagai dependensi. Flag ini menginstruksikan javac untuk menentukan jar yang benar-benar digunakan untuk pemeriksaan jenis setiap file java, dan peringatkan/error jika bukan output dependensi langsung dari target saat ini.
off
berarti pemeriksaan dinonaktifkan.warn
berarti javac akan menghasilkan peringatan java standar untuk jenis[strict]
untuk setiap dependensi langsung yang hilang.default
,strict
, danerror
semuanya berarti javac akan menghasilkan kesalahan, bukan peringatan, yang menyebabkan target untuk gagal dibangun jika ditemukan dependensi langsung yang hilang. Hal ini juga merupakan perilaku default jika tanda tidak ditentukan.
Membangun semantik
Opsi ini memengaruhi perintah build dan/atau konten file output.
--compilation_mode (fastbuild|opt|dbg)
(c)
Opsi --compilation_mode
(sering disingkat menjadi -c
,
terutama -c opt
) mengambil argumen fastbuild
, dbg
atau opt
, dan memengaruhi berbagai pembuatan kode C/C++
pilihan audiens, seperti tingkat pengoptimalan dan kelengkapan
tabel debug. Bazel menggunakan direktori {i>
output<i} yang berbeda untuk
mode kompilasi yang berbeda, sehingga Anda
bisa beralih mode tanpa
perlu melakukan build ulang secara menyeluruh setiap kali.
fastbuild
berarti membangun secepat mungkin: membuat informasi proses debug minimal (-gmlt -Wl,-S
), dan tidak mengoptimalkan. Ini adalah defaultnya. Catatan:-DNDEBUG
tidak akan disetel.dbg
berarti build dengan proses debug diaktifkan (-g
), sehingga Anda dapat menggunakan GiB (atau debugger lain).opt
berarti membangun dengan pengoptimalan yang diaktifkan dan dengan 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 menurut nama, dalam hal ini nilai akan diambil dari
lingkungan pemanggilan, atau dengan pasangan name=value
yang menetapkan nilai yang tidak bergantung pada
lingkungan pemanggilan.
Flag --action_env
ini dapat ditentukan beberapa kali. Jika nilai ditetapkan ke metode
variabel di beberapa tanda --action_env
, tugas terbaru akan menang.
--experimental_action_listener=label
Opsi experimental_action_listener
menginstruksikan Bazel untuk menggunakan
detail dari aturan action_listener
yang ditentukan oleh label untuk
masukkan extra_actions
ke dalam grafik build.
--[no]experimental_extra_action_top_level_only
Jika opsi ini disetel ke benar (true), tindakan tambahan akan ditentukan oleh
Perintah --experimental_action_listener
hanya akan dijadwalkan untuk target tingkat atas.
--experimental_extra_action_filter=regex
Opsi experimental_extra_action_filter
menginstruksikan Bazel untuk
filter kumpulan target untuk menjadwalkan extra_actions
.
Tanda ini hanya berlaku jika digunakan bersama
Flag --experimental_action_listener
.
Secara default semua extra_actions
dalam penutupan transitif
target-untuk-build yang diminta
dijadwalkan untuk dieksekusi.
--experimental_extra_action_filter
akan membatasi penjadwalan ke
extra_actions
yang label pemiliknya cocok dengan
ekspresi reguler.
Contoh berikut akan membatasi penjadwalan extra_actions
untuk hanya diterapkan pada tindakan yang label pemiliknya berisi '/bar/':
% bazel build --experimental_action_listener=//test:al //foo/... \ --experimental_extra_action_filter=.*/bar/.*
--host_cpu=cpu
Opsi ini menentukan nama arsitektur CPU yang harus yang digunakan untuk membangun alat {i>host<i}.
--fat_apk_cpu=cpu[,cpu]*
CPU untuk membangun library C/C++ dalam deps
transitif
android_binary
aturan. Aturan C/C++ lainnya tidak akan terpengaruh. Misalnya, jika
cc_library
muncul dalam deps
transitif dari aturan android_binary
dan
Aturan cc_binary
, cc_library
akan dibuat setidaknya dua kali:
sekali untuk setiap CPU yang ditentukan dengan --fat_apk_cpu
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 ditetapkan
dengan --fat_apk_cpu
. Nama file .so
memberi awalan nama aturan android_binary
dengan "lib". Misalnya, jika nama
android_binary
adalah "foo", maka filenya adalah libfoo.so
.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
Jika ada, file C++ apa pun dengan label atau jalur eksekusi yang cocok dengan salah satu ekspresi reguler penyertaan
dan tidak cocok dengan ekspresi pengecualian apa pun akan dibuat
dengan opsi yang diberikan. Pencocokan label menggunakan bentuk kanonis label
(yaitu, //package
:label_name
).
Jalur eksekusi adalah jalur relatif ke direktori ruang kerja Anda, termasuk nama dasar (termasuk ekstensi) file C++. Hal ini juga mencakup semua 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 itu tidak sesuai
dengan jalur eksekusi apa pun. Nama paket bisa digunakan seperti ini:
--per_file_copt=base/.*\.pb\.cc@-g0
. Ini akan cocok dengan setiap
File .pb.cc
pada direktori bernama base
.
Opsi ini dapat digunakan beberapa kali.
Opsi ini diterapkan terlepas dari mode kompilasi yang digunakan. Misalnya, dimungkinkan
untuk mengompilasi dengan --compilation_mode=opt
dan mengompilasi beberapa
file dengan pengoptimalan yang lebih kuat diaktifkan, atau dengan pengoptimalan dinonaktifkan.
Peringatan: Jika beberapa file dikompilasi secara selektif dengan simbol debug, simbol tersebut
mungkin dihilangkan selama penautan. Hal ini dapat dicegah
dengan mengatur
--strip=never
.
Sintaksis: [+-]regex[,[+-]regex]...@option[,option]...
Tempat
regex
adalah singkatan dari ekspresi reguler yang dapat diawali dengan
+
untuk mengidentifikasi pola penyertaan, dan -
untuk mengidentifikasi
mengecualikan pola. option
adalah singkatan dari opsi arbitrer yang diteruskan
ke compiler C++. Jika opsi berisi ,
, opsi tersebut harus dikutip seperti itu
\,
. Opsi juga dapat berisi @
, karena hanya yang pertama
@
digunakan untuk memisahkan ekspresi reguler dari opsi.
Contoh:
--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
menambahkan opsi -O0
dan -fprofile-arcs
ke perintah
baris compiler C++ untuk semua file .cc
di //foo/
kecuali file.cc
.
--dynamic_mode=mode
Menentukan apakah biner C++ akan ditautkan secara dinamis, melalui interaksi 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 atau tidak. Lihat linkstatic untuk mengetahui informasi selengkapnya tidak akurat atau tidak sesuai.fully
: Menautkan semua target secara dinamis. Hal ini akan mempercepat waktu penautan, dan mengurangi ukuran biner yang dihasilkan.off
: Menautkan semua target di mode sebagian besar statis. Jika-static
ditetapkan di linkopt, target akan berubah menjadi sepenuhnya statis.
--fission (yes|no|[dbg][,opt][,fastbuild])
Mengaktifkan Fission, yang menulis informasi debug C++ ke file .dwo khusus, bukan file .o, di mana jika tidak, pergi. Hal ini secara substansial mengurangi ukuran input untuk link dan dapat mengurangi waktu penautan.
Jika ditetapkan ke [dbg][,opt][,fastbuild]
(contoh:
--fission=dbg,fastbuild
), Fisi diaktifkan
hanya untuk set mode kompilasi yang ditentukan. Ini berguna untuk {i>bazelrc<i}
setelan. Jika ditetapkan ke yes
, Fission akan diaktifkan
secara universal. Jika ditetapkan ke no
, Fission akan dinonaktifkan
secara universal. Defaultnya adalah no
.
--force_ignore_dash_static
Jika flag ini disetel, opsi -static
apa pun di penautan
File BUILD aturan cc_*
diabaikan. Hal ini hanya dimaksudkan sebagai
untuk build hardening C++.
--[no]force_pic
Jika diaktifkan, semua kompilasi C++ akan menghasilkan kode yang tidak bergantung pada posisi ("-fPIC"), lebih memilih library bawaan PIC daripada library non-PIC, dan link menghasilkan file yang dapat dieksekusi independen posisi ("-pie"). Default-nya adalah dinonaktifkan.
--android_resource_shrinking
Memilih apakah akan melakukan penyingkatan resource untuk aturan android_binary. Menetapkan default untuk atribut shrink_resources aktif aturan android_binary; lihat dokumentasi aturan tersebut untuk detail lebih lanjut. Setelan defaultnya adalah nonaktif.
--custom_malloc=malloc-library-target
Jika ditentukan, selalu gunakan implementasi malloc yang diberikan, dengan mengganti semua
Atribut malloc="target"
, termasuk di target yang menggunakan
default (dengan tidak menentukan malloc
).
--crosstool_top=label
Opsi ini menentukan lokasi suite compiler crosstool
yang akan digunakan untuk semua kompilasi C++ selama build. Bazel akan melihatnya
untuk file CROSSTOOL dan menggunakannya
untuk menentukan secara otomatis
setelan untuk --compiler
.
--host_crosstool_top=label
Jika tidak ditentukan, Bazel akan menggunakan nilai --crosstool_top
untuk mengompilasi
dalam konfigurasi host, seperti
alat yang dijalankan selama build. Tujuan utama flag ini
adalah untuk memungkinkan kompilasi silang.
--apple_crosstool_top=label
Alat silang yang digunakan untuk mengompilasi aturan C/C++ dalam deps
transitif
aturan objc*, ios*, dan apple*. Untuk target tersebut, tanda ini akan menimpa
--crosstool_top
.
--android_crosstool_top=label
Alat silang yang digunakan untuk mengompilasi aturan C/C++ dalam deps
transitif
android_binary
aturan. Hal ini berguna jika target lain dalam
membutuhkan {i>crosstool<i} yang berbeda. Setelan defaultnya adalah menggunakan alat silang
yang dibuat 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 Anda ingin
dengan {i>crosstool<i} khusus, Anda harus
menggunakan file {i>CROSSTOOL <i}bukan
yang menentukan flag ini.
--android_sdk=label
Opsi ini menetapkan toolchain platform/Android SDK dan library runtime Android yang akan digunakan untuk membangun aturan.
Android SDK akan dipilih secara otomatis jika android_sdk_repository
ditentukan dalam file WORKSPACE.
--java_toolchain=label
Opsi ini menentukan label java_ toolchain yang digunakan untuk mengompilasi Java file sumber.
--host_java_toolchain=label
Jika tidak ditentukan, bazel akan menggunakan nilai --java_toolchain
untuk mengompilasi
dalam konfigurasi host, misalnya untuk alat yang dijalankan selama build. Tujuan utama flag ini
adalah untuk memungkinkan kompilasi silang.
--javabase=(label)
Opsi ini menetapkan label penginstalan Java dasar yang akan digunakan untuk bazel run,
pengujian bazel, serta untuk biner Java yang dibuat oleh java_binary
dan
java_test
aturan. JAVABASE
dan JAVA
"Buat" variabel 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.
Ini tidak memilih compiler Java yang digunakan untuk mengompilasi Java
file sumber. Kompilator dapat dipilih
melalui pengaturan
Opsi --java_toolchain
.
Strategi eksekusi
Opsi ini memengaruhi cara Bazel menjalankan build. Parameter ini tidak akan memiliki pengaruh yang signifikan pada file output yang dihasilkan oleh build. Biasanya efek utamanya adalah pada kecepatan build.
--spawn_strategy=strategy
Opsi ini mengontrol tempat dan cara perintah dieksekusi.
standalone
menyebabkan perintah dieksekusi sebagai subproses lokal. Nilai ini adalah tidak digunakan lagi. Sebagai gantinya, gunakanlocal
.sandboxed
menyebabkan perintah dijalankan dalam sandbox di komputer lokal. Ini mengharuskan semua file input, dependensi data, dan alat dicantumkan sebagai dependensi dalam atributsrcs
,data
, dantools
. Bazel mengaktifkan {i>sandbox<i} lokal secara {i>default<i} pada sistem yang mendukung eksekusi dalam {i>sandbox<i}.local
menyebabkan perintah dieksekusi sebagai subproses lokal.worker
menyebabkan perintah dieksekusi menggunakan pekerja persisten, jika tersedia.docker
menyebabkan perintah dijalankan di dalam sandbox Docker di komputer lokal. Tindakan ini memerlukan penginstalan Docker.remote
menyebabkan perintah dieksekusi dari jarak jauh; fitur ini hanya tersedia jika eksekutor jarak jauh telah dikonfigurasi secara terpisah.
--strategy mnemonic=strategy
Opsi ini mengontrol di mana dan bagaimana perintah dieksekusi, menggantikan --spawn_strategy (dan --genrule_strategy dengan mnemonik Genrule) berdasarkan per-mnemonik. Lihat --spawn_strategy untuk platform yang didukung strategi dan efeknya.
--strategy_regexp=<filter,filter,...>=<strategy>
Opsi ini menentukan strategi mana yang harus digunakan untuk menjalankan perintah yang memiliki deskripsi
cocok dengan regex_filter
tertentu. Lihat
--per_file_copt untuk mengetahui detail tentang
pencocokan regex_filter. Lihat
--spawn_strategy untuk platform yang didukung
strategi dan efeknya.
regex_filter
terakhir yang cocok dengan deskripsi digunakan. Opsi ini mengganti
penanda lain untuk menentukan strategi.
- Contoh:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
berarti menjalankan tindakan menggunakan Strategilocal
jika deskripsinya cocok dengan //foo.*.cc tetapi bukan //foo/bar. - Contoh:
--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed
menjalankan 'Kompilasi //foo/bar/baz' dengan strategisandboxed
, tetapi membalikkan pesanan menjalankannya denganlocal
. - Contoh:
--strategy_regexp='Compiling.*/bar=local,sandboxed'
run 'Mengompilasi //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 integer, menentukan batas jumlah tugas yang harus dieksekusi secara serentak selama fase eksekusi build.
--progress_report_interval=n
Bazel secara berkala mencetak laporan kemajuan tentang tugas yang belum
selesai (seperti pengujian yang berjalan lama). Opsi ini menetapkan
frekuensi pelaporan, progres akan dicetak setiap n
detik.
Defaultnya adalah 0, artinya algoritma inkremental: yang pertama laporan akan dicetak setelah 10 detik, lalu 30 detik dan setelah kemajuan tersebut dilaporkan sekali setiap menit.
Bila bazel menggunakan kontrol kursor, sebagaimana ditentukan oleh
--curses
, progres dilaporkan setiap detik.
--local_{ram,cpu}_resources resources or resource expression
Opsi ini menentukan jumlah resource lokal (RAM dalam MB dan jumlah core logis CPU)
yang dapat dipertimbangkan Bazel saat menjadwalkan aktivitas build dan pengujian untuk dijalankan secara lokal. Mereka mengambil
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
).
Penandanya bersifat independen; salah satu atau keduanya
dapat ditetapkan. Secara {i>default<i}, Bazel memperkirakan
jumlah RAM dan jumlah inti CPU
langsung dari konfigurasi sistem lokal.
--[no]build_runfile_links
Opsi ini, yang diaktifkan secara default, menentukan apakah runfile
symlink untuk pengujian dan biner harus dibangun di direktori output.
Menggunakan --nobuild_runfile_links
dapat berguna
untuk memvalidasi jika semua target dikompilasi tanpa menimbulkan overhead
untuk membangun pohon runfile.
Ketika pengujian (atau aplikasi) dijalankan, data runtime-nya
dependensi dikumpulkan
di satu tempat. Dalam pandangan Bazel,
hierarki output, "runfiles" ini pohon biasanya diakar
sebagai saudara dari
biner atau tes yang sesuai.
Selama eksekusi uji, runfile dapat diakses menggunakan jalur formulir
$TEST_SRCDIR/workspace/packagename/filename
.
Hierarki runfiles memastikan bahwa pengujian memiliki akses ke semua file
di mana mereka memiliki ketergantungan yang
nyata, tidak lebih dari itu. Menurut
secara {i>default<i}, pohon {i>runfiles<i} diimplementasikan
dengan membuat serangkaian
tautan simbolis ke
file yang dibutuhkan. Seiring bertambahnya jumlah
tautan, maka
melakukan biaya operasi ini, dan
untuk beberapa build besar itu bisa
berkontribusi secara signifikan terhadap waktu build secara keseluruhan, terutama karena
setiap pengujian (atau aplikasi) memerlukan hierarki runfile-nya sendiri.
--[no]build_runfile_manifests
Opsi ini, yang diaktifkan secara default, menentukan apakah manifes runfiles
harus ditulis ke hierarki output.
Menonaktifkannya menyiratkan --nobuild_runfile_links
.
Ini dapat dinonaktifkan ketika menjalankan pengujian dari jarak jauh, karena pohon runfiles akan dibuat secara jarak jauh dari manifes dalam memori.
--[no]discard_analysis_cache
Jika opsi ini diaktifkan, Bazel akan menghapus cache analisis tepat sebelum eksekusi dimulai, sehingga mengosongkan memori tambahan (sekitar 10%) untuk fase eksekusi. Kelemahannya adalah build inkremental selanjutnya akan lebih lambat. Lihat juga mode hemat memori.
--[no]keep_going
(-rb)
Seperti dalam GNU Make, fase eksekusi sebuah build berhenti saat terjadi kesalahan. Terkadang ada baiknya untuk mencoba membangun sebagai sebanyak mungkin bahkan ketika berhadapan dengan kesalahan. Opsi ini memungkinkan perilaku tersebut, dan ketika sudah ditentukan, build akan mencoba membangun setiap target yang prasyaratnya berhasil dibuat, tetapi akan mengabaikan error.
Sementara opsi ini biasanya
dikaitkan dengan fase eksekusi
build, hal itu juga mempengaruhi fase analisis: jika beberapa target
ditentukan dalam perintah {i>build<i}, tetapi
hanya beberapa yang bisa
berhasil dianalisis, build akan berhenti dengan error
kecuali jika --keep_going
ditentukan, dalam hal ini
build akan dilanjutkan ke fase eksekusi, tetapi hanya untuk target
yang berhasil dianalisis.
--[no]use_ijars
Opsi ini mengubah cara target java_library
dikompilasi oleh Bazel. Alih-alih menggunakan output
java_library
untuk mengompilasi dependensi
java_library
target, Bazel akan membuat toples antarmuka
yang hanya berisi tanda tangan
dari anggota non-pribadi (publik,
dilindungi, serta metode dan kolom akses default (paket)) serta menggunakan
jar antarmuka untuk mengompilasi target dependen. Hal ini membuatnya
mungkin untuk menghindari rekompilasi ketika
perubahan hanya dilakukan pada
isi metode atau anggota pribadi class.
--[no]interface_shared_objects
Opsi ini mengaktifkan antarmuka objek bersama, yang membuat biner dan library bersama lainnya bergantung pada antarmuka objek bersama, dan bukan implementasinya. Ketika hanya implementasi yang berubah, Bazel dapat menghindari membangun ulang target yang bergantung pada pustaka bersama yang diubah jika tidak diperlukan.
Pemilihan output
Opsi ini menentukan apa yang akan dibangun atau diuji.
--[no]build
Opsi ini menyebabkan fase eksekusi build terjadi; ini aktif secara default. Ketika dimatikan, fase eksekusi akan dilewati, dan hanya dua fase pertama, pemuatan dan analisis, yang terjadi.
Opsi ini dapat berguna untuk memvalidasi file BUILD dan mendeteksi kesalahan input, tanpa benar-benar membangun apa pun.
--[no]build_tests_only
Jika ditentukan, Bazel hanya akan membangun apa yang diperlukan untuk menjalankan *_test
dan test_suite
aturan yang tidak difilter karena
size (ukuran),
waktu tunggu,
tag, atau
bahasa.
Jika ditentukan, Bazel akan mengabaikan target lain yang ditentukan pada command line.
Secara {i>default<i}, opsi ini dinonaktifkan
dan Bazel akan membangun semuanya
diminta, termasuk aturan *_test
dan test_suite
yang difilter dari
pengujian. Hal ini berguna karena menjalankan
bazel test --build_tests_only foo/...
mungkin tidak mendeteksi semua build
kerusakan di hierarki foo
.
--[no]check_up_to_date
Opsi ini menyebabkan Bazel tidak melakukan build, tetapi hanya memeriksa apakah semua target yang ditentukan merupakan yang terbaru atau tidak. Jika ya, build berhasil diselesaikan, seperti biasa. Namun, jika ada file yang alih-alih dibuat, error dilaporkan dan build gagal. Opsi ini berguna untuk menentukan apakah build memiliki dilakukan lebih baru daripada pengeditan sumber (misalnya, untuk pra-pengiriman check) tanpa menimbulkan biaya build.
Lihat juga --check_tests_up_to_date
.
--[no]compile_one_dependency
Mengompilasi satu dependensi file argumen. Hal ini berguna untuk memeriksa sintaksis file sumber di IDE, misalnya, dengan membangun ulang satu target yang bergantung pada file sumber untuk mendeteksi error sedini mungkin mungkin dalam siklus edit/build/test. Argumen ini mempengaruhi bagaimana argumen non-flag ditafsirkan: setiap argumen harus berupa label target file atau nama file biasa yang terkait dengan fungsi saat ini direktori, dan satu aturan yang bergantung pada setiap nama file sumber dibuat. Untuk
C++ dan Java sumber, aturan dalam ruang bahasa yang sama dipilih secara istimewa. Sebagai beberapa aturan dengan preferensi yang sama, aturan yang akan muncul pertama kali File BUILD dipilih. Pola target bernama eksplisit yang tidak merujuk ke file sumber akan menghasilkan error.
--save_temps
Opsi --save_temps
menyebabkan output sementara dari compiler menjadi
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. Suhu hanya akan
yang dihasilkan untuk serangkaian target
yang ditentukan pada baris perintah.
Tanda --save_temps
saat ini hanya berfungsi untuk aturan cc_*.
Untuk memastikan bahwa Bazel bisa
mencetak lokasi file {i>output<i} tambahan, pastikan
--show_result n
Anda
sudah cukup tinggi.
--build_tag_filters=tag[,tag]*
Jika ditentukan, Bazel hanya akan membuat target yang memiliki setidaknya satu tag yang diperlukan (jika salah satunya ditentukan) dan tidak memiliki tag yang dikecualikan. Tag build filter ditetapkan sebagai daftar kata kunci tag yang dibatasi koma, diawali dengan '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan juga dapat memiliki tanda '+' sebelumnya tanda tangan.
Saat menjalankan pengujian, Bazel mengabaikan --build_tag_filters
untuk target pengujian,
yang dibuat dan dijalankan meskipun
mereka tidak sesuai dengan filter ini. Untuk menghindari pembuatannya, filter
menguji target menggunakan --test_tag_filters
atau dengan mengecualikannya secara eksplisit.
--test_size_filters=size[,size]*
Jika ditentukan, Bazel akan menguji (atau membangun jika --build_tests_only
ditentukan) hanya target pengujian dengan ukuran yang ditentukan. Uji filter ukuran
ditetapkan sebagai daftar yang dibatasi koma
dari nilai ukuran pengujian yang diizinkan (kecil,
sedang, besar, atau sangat besar), serta boleh diawali dengan '-' tanda yang digunakan untuk menunjukkan
dan ukuran pengujian yang dikecualikan. Misalnya,
% bazel test --test_size_filters=small,medium //foo:alldan
% 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 membangun jika --build_tests_only
ditentukan) hanya target pengujian dengan waktu tunggu yang diberikan. Uji filter waktu tunggu
ditetapkan sebagai daftar nilai batas waktu pengujian
yang dibatasi koma (singkat,
sedang, panjang, atau abadi), dapat juga diawali dengan '-' tanda yang digunakan untuk menunjukkan
waktu tunggu pengujian yang
dikecualikan. Lihat --test_size_filters
misalnya sintaks.
Secara default, pemfilteran waktu tunggu pengujian tidak diterapkan.
--test_tag_filters=tag[,tag]*
Jika ditentukan, Bazel akan menguji (atau membangun jika --build_tests_only
ditentukan) hanya target pengujian yang memiliki setidaknya satu tag yang diperlukan
(jika salah satunya ditentukan) dan tidak memiliki tag yang dikecualikan. Tag pengujian
filter ditetapkan sebagai daftar kata kunci tag yang dibatasi koma,
diawali dengan '-' yang digunakan untuk menunjukkan tag yang dikecualikan. Tag yang diperlukan juga dapat
memiliki tanda '+' sebelumnya tanda tangan.
Misalnya,
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
akan menguji target yang diberi tag dengan performance
atau
stress
, tetapi tidak diberi tag dengan tag flaky
.
Secara default, pemfilteran tag pengujian tidak diterapkan. Perhatikan bahwa Anda juga dapat memfilter
pada tag size
dan local
pengujian di
dengan cara ini.
--test_lang_filters=lang[,lang]*
Menentukan daftar yang dipisahkan koma untuk bahasa pengujian dengan aturan *_test
resmi
(lihat membuat ensiklopedia untuk mengetahui daftar lengkapnya). Masing-masing
bahasa dapat diawali dengan '-' untuk menentukan pengecualian
bahasa. Nama yang digunakan untuk setiap bahasa harus sama dengan
awalan bahasa dalam aturan *_test
, misalnya,
cc
, java
atau sh
.
Jika ditentukan, Bazel akan menguji (atau membangun jika --build_tests_only
juga ditentukan) hanya target pengujian dari bahasa yang ditentukan.
Misalnya,
% bazel test --test_lang_filters=cc,java foo/...
hanya akan menguji pengujian C/C++ dan Java (ditentukan menggunakan
cc_test
dan java_test
masing-masing)
di foo/...
, sementara
% 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 runner pengujian untuk memilih subset pengujian sedang berjalan. Semua target yang ditentukan dalam pemanggilan akan dibuat, tetapi bergantung pada ekspresi hanya beberapa dari mereka yang dapat dieksekusi; dalam beberapa kasus, hanya metode pengujian dijalankan.
Penafsiran khusus filter-expression memerlukan
kerangka kerja pengujian yang
bertanggung jawab untuk menjalankan pengujian. Objek ini dapat berupa glob,
{i>substring<i}, atau {i>regexp<i}. --test_filter
adalah kemudahan
selama meneruskan argumen filter --test_arg
yang berbeda,
tetapi tidak semua kerangka
kerja mendukungnya.
Panjang
Opsi ini mengontrol panjang {i>output<i} Bazel, baik ke terminal, atau ke file log tambahan.
--explain=logfile
Opsi ini, yang membutuhkan argumen nama file, menyebabkan
pemeriksa dependensi dalam fase eksekusi bazel build
untuk
menjelaskan, untuk setiap langkah pembangunan, mengapa itu dijalankan, atau
sudah yang terbaru. Penjelasan ditulis
ke logfile.
Jika Anda mengalami pembangunan ulang yang tak terduga, opsi ini dapat membantu
memahami alasannya. Tambahkan ke .bazelrc
Anda agar
logging terjadi untuk semua build berikutnya, lalu memeriksa log
saat melihat langkah eksekusi
yang dieksekusi secara tidak terduga. Opsi ini
mungkin membawa penalti kinerja kecil, jadi Anda mungkin ingin menghapus
saat tidak dibutuhkan lagi.
--verbose_explanations
Opsi ini meningkatkan panjang penjelasan yang dibuat jika opsi --explain diaktifkan.
Secara khusus, jika penjelasan panjang diaktifkan, dan file {i>output<i} dibuat ulang karena perintah yang digunakan untuk build telah berubah, maka {i>output<i} dalam file penjelasan akan sertakan detail lengkap tentang perintah baru (setidaknya untuk sebagian besar perintah).
Menggunakan opsi ini dapat menambah panjang
file penjelasan yang dihasilkan dan penalti performa dari penggunaan
--explain
.
Jika --explain
tidak diaktifkan,
--verbose_explanations
tidak berpengaruh.
--profile=file
Opsi ini, yang menggunakan argumen nama {i>file<i}, membuat Bazel menulis
membuat profil data ke dalam sebuah file. Data tersebut kemudian dapat dianalisis atau diuraikan menggunakan
Perintah bazel analyze-profile
. Profil {i>Build <i}dapat berguna di
memahami di mana perintah build
Bazel menghabiskan waktunya.
--[no]show_loading_progress
Opsi ini menyebabkan Bazel menampilkan progres pemuatan paket membuat pesan teks. Jika dinonaktifkan, pesan tidak akan ditampilkan.
--[no]show_progress
Opsi ini menyebabkan pesan progres ditampilkan; nyala oleh secara default. Jika dinonaktifkan, pesan progres akan disembunyikan.
--show_progress_rate_limit=n
Opsi ini menyebabkan bazel menampilkan maksimal satu pesan progres per n
detik,
dengan n adalah bilangan riil.
Nilai default untuk opsi ini adalah 0,02, yang berarti bazel akan membatasi progres
pesan menjadi satu per 0,02 detik.
--show_result=n
Opsi ini mengontrol pencetakan informasi hasil di bagian akhir
dari perintah bazel build
. Secara {i>default<i}, jika satu
target build ditentukan, Bazel akan mencetak pesan yang menyatakan apakah
target berhasil diperbarui atau tidak, dan jika ya,
daftar file {i>output<i}
yang dibuat oleh target. Jika lebih dari satu
target ditentukan, informasi hasil tidak ditampilkan.
Meskipun informasi hasil mungkin berguna untuk build
target atau beberapa target, untuk build besar (seperti seluruh level teratas
proyek), informasi ini bisa membanjiri dan mengganggu;
dengan opsi ini, Anda dapat
mengontrolnya. --show_result
menggunakan argumen integer, yang merupakan jumlah maksimum target
yang informasi hasil lengkapnya harus dicetak. Secara {i>default<i},
nilainya adalah 1. Di atas nilai minimum ini, tidak ada informasi hasil yang
yang ditampilkan untuk target individual. Dengan demikian nol menyebabkan hasil
informasi selalu disembunyikan, dan nilai yang sangat besar menyebabkan
hasilnya akan selalu dicetak.
Pengguna mungkin ingin memilih di antara nilai jika mereka rutin
bergantian antara membuat sekelompok kecil target (misalnya,
selama siklus kompilasi-edit-test) dan sekelompok besar target
(misalnya, saat membuat ruang kerja baru atau menjalankan
pengujian regresi). Dalam kasus sebelumnya, informasi hasilnya adalah
sangat berguna, sedangkan yang kedua kurang bermanfaat. Seperti semua
, ini bisa ditentukan secara implisit melalui
file .bazelrc
.
File-file tersebut dicetak untuk memudahkan Anda untuk menyalin dan menempelkan ({i>paste<i}) nama file ke {i>shell<i}, untuk menjalankan file {i>executable<i} yang dibangun. Versi "terbaru" atau "gagal" pesan untuk setiap target dapat dengan mudah diuraikan oleh skrip yang menjalankan build.
--sandbox_debug
Opsi ini menyebabkan Bazel mencetak informasi proses debug tambahan saat menggunakan sandbox untuk tindakan dalam proses eksekusi. Opsi ini juga mempertahankan direktori sandbox, sehingga file dapat dilihat oleh tindakan dapat diperiksa selama eksekusi.
--subcommands
(-s
)
Opsi ini menyebabkan fase eksekusi Bazel mencetak baris perintah lengkap untuk setiap perintah sebelum menjalankannya.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'] (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
Jika memungkinkan, perintah dicetak dalam
{i>syntax<i} yang kompatibel dengan {i>Bourne shell<i},
sehingga dapat dengan mudah disalin
dan ditempelkan ke {i>command prompt<i} shell.
(Tanda kurung di sekitarnya disediakan untuk
melindungi {i>shell<i} Anda dari
cd
dan exec
panggilan; pastikan untuk menyalinnya.)
Namun beberapa perintah diimplementasikan
secara internal dalam Bazel, seperti
membuat pohon 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 mungkin
membantu membuat baris perintah
yang panjang lebih mudah dibaca.
Lihat juga --verbose_failures, di bawah.
Untuk mencatat subperintah ke file dalam format yang mudah digunakan, lihat --execution_log_json_file dan --execution_log_binary_file.
--verbose_failures
Opsi ini menyebabkan fase eksekusi Bazel mencetak baris perintah lengkap untuk perintah yang gagal. Hal ini sangat bermanfaat untuk men-debug build yang gagal.
Perintah yang gagal dicetak dalam sintaks yang kompatibel dengan shell Bourne, yang cocok untuk menyalin dan menempelkan ke {i>prompt<i} shell.
Status ruang kerja
Gunakan opsi berikut untuk "memberi stempel" Biner yang dibuat Bazel: untuk menyematkan informasi tambahan ke dalam direktori
biner, seperti revisi kontrol sumber atau informasi terkait ruang kerja lainnya. Anda dapat menggunakan
mekanisme ini dengan aturan yang mendukung atribut stamp
, seperti
genrule
, cc_binary
, dan lainnya.
--workspace_status_command=program
Tanda 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 ".exe", ".bat", atau ".cmd" .
Program ini harus mencetak nol atau beberapa key-value pair ke output standar, satu entri di setiap baris, kemudian keluar dengan nol (jika tidak, build akan gagal). Nama kunci bisa apa saja tetapi mungkin hanya gunakan huruf besar dan garis bawah. Spasi pertama setelah nama kunci memisahkannya dari dengan sejumlah nilai. Nilainya adalah sisa baris (termasuk spasi kosong tambahan). Baik kunci maupun nilainya dapat mencakup beberapa baris. Kunci tidak boleh diduplikasi.
Bazel mempartisi kunci menjadi dua bucket: "stabil" dan "volatil". (Nama "stabil" dan "volatil" agak kontra-intuitif, jadi jangan terlalu dipikirkan.)
Kemudian, Bazel menulis pasangan nilai kunci ke dalam dua file:
bazel-out/stable-status.txt
berisi semua kunci dan nilai yang nama kuncinya dimulai denganSTABLE_
bazel-out/volatile-status.txt
berisi kunci lainnya dan nilainya
Kontraknya adalah:
"stabil" key nilainya harus jarang berubah, jika memungkinkan. Jika isi dari
bazel-out/stable-status.txt
berubah, Bazel membatalkan tindakan yang bergantung padanya. Di beberapa 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 mereka mengubah semua waktu, dan akan membuat Bazel mengulangi tindakan bercap pada setiap bangunan.Bazel selalu menghasilkan tombol stabil berikut:
BUILD_EMBED_LABEL
: nilai--embed_label
BUILD_HOST
: nama mesin host yang menjalankan BazelBUILD_USER
: nama pengguna yang dijalankan Bazel
"volatil" key nilainya mungkin sering berubah. Bazel berharap mereka berubah sepanjang waktu, seperti stempel waktu, dan memperbarui
bazel-out/volatile-status.txt
. Untuk menghindari menjalankan kembali tindakan yang distempel setiap saat, Bazel berpura-pura bahwa file yang tidak stabil tidak perubahan. Dengan kata lain, jika {i>file<i} status tidak stabil adalah satu-satunya file yang isinya diubah, Bazel tidak akan membatalkan tindakan yang bergantung padanya. Jika input lain dari tindakan telah berubah, lalu Bazel menjalankan ulang tindakan itu, dan tindakan itu akan melihat nilai volatil yang telah diperbarui , tetapi hanya perubahan status yang tidak stabil saja tidak akan membatalkan tindakan.Bazel selalu menghasilkan tombol tidak stabil berikut:
BUILD_TIMESTAMP
: waktu build dalam detik sejak Unix Epoch (nilainya dariSystem.currentTimeMillis()
dibagi dengan seribu)FORMATTED_DATE
: waktu build Diformat sebagaiyyyy MMM d HH mm ss EEE
(misalnya 2023 Jun 2 01 44 29 Jum) dalam UTC.
Di Linux/macOS, Anda dapat meneruskan --workspace_status_command=/bin/true
ke
nonaktifkan pengambilan status ruang kerja, karena true
tidak melakukan apa pun, berhasil (keluar
dengan nol) dan tidak mencetak output. Di Windows, Anda dapat meneruskan jalur true.exe
MSYS
untuk efek yang sama.
Jika perintah status workspace gagal (keluar bukan nol) karena alasan apa pun, build akan gagal.
Contoh program di Linux menggunakan Git:
#!/bin/bash echo "CURRENT_TIME $(date +%s)" echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)" echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)" echo "STABLE_USER_NAME $USER"
Teruskan jalur program ini dengan --workspace_status_command
, dan file status stabil
akan menyertakan baris STABLE dan file status yang tidak stabil akan menyertakan baris lainnya.
--[no]stamp
Opsi ini, bersama dengan atribut aturan stamp
, mengontrol apakah akan
menyematkan informasi build dalam biner.
Stempel waktu dapat diaktifkan atau dinonaktifkan secara eksplisit per aturan menggunakan
Atribut stamp
. Lihat Ensiklopedia Build untuk mengetahui detailnya. Kapan
aturan menetapkan stamp = -1
(default untuk *_binary
aturan), opsi ini
menentukan apakah penandaan diaktifkan atau tidak.
Bazel tidak pernah memberi stempel
pada biner yang dibuat untuk konfigurasi {i>host<i},
terlepas dari opsi ini atau atribut stamp
. Untuk aturan yang menetapkan stamp =
0
(default untuk aturan *_test
), penandaan akan dinonaktifkan terlepas dari
--[no]stamp
. Menentukan --stamp
tidak akan memaksa target untuk dibuat ulang jika
dependensi mereka tidak berubah.
Menyetel --nostamp
umumnya sangat diinginkan untuk performa build, karena
mengurangi volatilitas input dan memaksimalkan build caching.
Platform
Gunakan opsi ini untuk mengontrol platform target dan host yang mengonfigurasi cara kerja build, serta mengontrol platform eksekusi dan toolchain yang tersedia untuk aturan Bazel.
Harap lihat informasi latar belakang tentang Platform dan Toolchain.
--platforms=labels
Label aturan platform yang menjelaskan platform target untuk perintah {i>current<i}.
--host_platform=label
Label aturan platform yang menjelaskan sistem host.
--extra_execution_platforms=labels
Platform yang tersedia sebagai platform eksekusi untuk menjalankan tindakan. Platform dapat ditentukan berdasarkan target yang tepat, atau sebagai pola target. Ini platform akan dipertimbangkan sebelum dideklarasikan dalam file WORKSPACE oleh register_execution_platforms().
--extra_toolchains=labels
Aturan toolchain yang akan dipertimbangkan selama resolusi toolchain. Rantai Alat dapat ditentukan menurut target yang tepat, atau sebagai pola target. Toolchain ini akan dipertimbangkan sebelum yang dideklarasikan dalam file WORKSPACE dengan register_toolchains().
--toolchain_resolution_debug=regex
Mencetak informasi debug sambil mencari toolchain jika jenis toolchain cocok
ekspresi reguler. Beberapa regexe dapat dipisahkan dengan koma. Ekspresi reguler dapat berupa
diabaikan dengan menggunakan -
di awal. Hal ini dapat membantu developer
aturan Bazel atau Starlark dengan kegagalan proses debug karena toolchain yang hilang.
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 selengkapnya selengkapnya, lihat Konfigurasi Starlark.
--symlink_prefix=string
Mengubah awalan symlink praktis yang dibuat. Tujuan
nilai default untuk awalan symlink adalah bazel-
yang
akan membuat symlink bazel-bin
, bazel-testlogs
, dan
bazel-genfiles
.
Jika tautan simbolis tidak dapat dibuat karena alasan apa pun, peringatan akan tetapi proses build-nya masih dianggap berhasil. Secara khusus, kita akan membuat ini memungkinkan Anda membangun di direktori {i>read-only<i} atau direktori yang tidak memiliki izin tulis. Setiap jalur yang dicetak dalam pesan pada akhir build hanya akan menggunakan bentuk pendek relatif symlink jika symlink menunjuk ke lokasi; dengan kata lain, Anda dapat mengandalkan keakuratan walaupun Anda tidak dapat mengandalkan {i>symlink<i} yang dibuat.
Beberapa nilai umum opsi ini:
Hentikan pembuatan symlink:
--symlink_prefix=/
akan menyebabkan Bazel tidak buat atau perbarui symlink apa pun, termasukbazel-out
danbazel-<workspace>
{i>symlink<i}. Gunakan opsi ini untuk menyembunyikan pembuatan symlink sepenuhnya.Mengurangi kekacauan:
--symlink_prefix=.bazel/
akan membuat Bazel membuat symlink yang disebutbin
(dll.) di dalam direktori tersembunyi.bazel
.
--platform_suffix=string
Menambahkan akhiran ke nama pendek konfigurasi, yang digunakan untuk menentukan {i>output <i}yang ada. Menyetel opsi ini ke nilai yang berbeda akan menempatkan file ke dalam direktori yang berbeda, misalnya untuk meningkatkan tingkat kecocokan cache untuk build yang jika tidak melakukan clobber file {i>output<i} satu sama lain, atau untuk menyimpan file {i>output<i} untuk perbandingan.
--default_visibility=(private|public)
Tanda sementara untuk menguji perubahan visibilitas default bazel. Tidak dimaksudkan untuk penggunaan umum tetapi didokumentasikan untuk kelengkapan sake.
--[no]use_action_cache
Opsi ini diaktifkan secara default. Jika dinonaktifkan, Bazel tidak akan menggunakan cache tindakan lokal. Menonaktifkan cache tindakan lokal akan menghemat memori dan ruang disk untuk build bersih, tetapi akan build inkremental lebih lambat.
--starlark_cpu_profile=_file_
Penanda ini, yang nilainya adalah nama file, membuat Bazel mengumpulkan statistik tentang penggunaan CPU oleh semua utas Starlark, dan tulis profil, dalam format pprof, ke file yang bernama.
Gunakan opsi ini untuk membantu mengidentifikasi fungsi Starlark yang membuat pemuatan dan analisis menjadi lambat karena komputasi yang berlebihan. Contoh:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
Untuk melihat berbagai tampilan data yang sama, coba perintah pprof
seperti svg
,
web
, dan list
.
Menggunakan Bazel untuk rilis
Bazel digunakan baik oleh software engineer selama pengembangan dan oleh engineer rilis saat menyiapkan biner untuk deployment ke production. Bagian ini memberikan daftar tips untuk rilis insinyur menggunakan Bazel.
Opsi signifikan
Saat menggunakan Bazel untuk build rilis, masalah yang sama akan muncul seperti skrip lainnya yang menjalankan build. Untuk detail selengkapnya, lihat Memanggil Bazel dari skrip. Khususnya, opsi berikut sangat disarankan:
Opsi ini juga penting:
--package_path
--symlink_prefix
: guna mengelola build untuk beberapa konfigurasi, mungkin akan lebih mudah untuk membedakan setiap build dengan ID yang berbeda, seperti "64bit" vs. "32bit". Opsi ini membedakan symlinkbazel-bin
(dll.).
Menjalankan pengujian
Untuk membuat dan menjalankan pengujian dengan bazel, ketik bazel test
diikuti dengan
nama target pengujian.
Secara default, perintah ini melakukan build dan pengujian secara bersamaan
aktivitas Anda, membangun semua target yang ditentukan (termasuk aktivitas non-pengujian
target yang ditentukan pada baris perintah) dan menguji
*_test
dan test_suite
menargetkan segera setelah
prasyarat mereka dibangun, artinya
eksekusi uji adalah
disisipkan dengan bangunan. Melakukan hal tersebut biasanya akan menghasilkan
peningkatan kecepatan.
Opsi untuk bazel test
--cache_test_results=(yes|no|auto)
(-t
)
Jika opsi ini disetel ke 'otomatis' ({i>default<i}) maka Bazel hanya akan menjalankan ulang pengujian jika salah satu ketentuan berikut berlaku:
- Bazel mendeteksi perubahan pada pengujian atau dependensinya
- pengujian ditandai sebagai
external
- beberapa pengujian diminta dengan
--runs_per_test
- pengujian gagal.
Jika 'tidak', semua pengujian akan dijalankan tanpa syarat.
Jika 'ya', perilaku penyimpanan dalam cache akan sama dengan perilaku penyimpanan otomatis
kecuali bahwa server tersebut dapat menyimpan kegagalan uji
dalam cache dan menjalankan pengujian dengan
--runs_per_test
.
Pengguna yang telah mengaktifkan opsi
ini secara {i>default<i} di
file .bazelrc
dapat menemukan
singkatan -t
(aktif) atau -t-
(nonaktif)
nyaman untuk mengganti {i>default<i}
pada suatu proses operasi tertentu.
--check_tests_up_to_date
Opsi ini memberi tahu Bazel untuk tidak menjalankan pengujian, tetapi hanya memeriksa dan melaporkan hasil pengujian yang di-cache. Jika ada pengujian yang belum yang telah dibuat dan dijalankan sebelumnya, atau yang hasil pengujiannya sudah tidak berlaku (misalnya, karena kode sumber atau opsi {i>build<i} telah berubah), maka Bazel akan melaporkan pesan {i>error<i} ("hasil tes tidak diperbarui"), akan mencatat statusnya sebagai "TIDAK ADA STATUS" (warna merah, jika output warna diaktifkan), dan akan ditampilkan {i>exit code<i} 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 jauh lebih lama dari waktu eksekusi uji yang sebenarnya. Meskipun pengujian waktu tunggu harus diatur sedemikian rupa agar tidak berfluktuasi, pengujian yang memiliki waktu tunggu yang terlalu banyak dapat menyembunyikan masalah nyata yang muncul secara tidak terduga.
Misalnya, pengujian yang biasanya dijalankan dalam satu atau dua menit seharusnya tidak memiliki waktu tunggu ETERNAL atau PANJANG karena ini terlalu melimpah.
Opsi ini berguna untuk membantu pengguna menentukan nilai waktu tunggu yang baik atau memeriksa nilai waktu tunggu yang ada.
--[no]test_keep_going
Secara default, semua pengujian dijalankan sampai selesai. Jika penanda ini dinonaktifkan,
namun, build dibatalkan pada pengujian yang tidak lulus. Langkah build berikutnya
dan pemanggilan pengujian tidak dijalankan, dan pemanggilan yang sedang berlangsung akan dibatalkan.
Jangan tentukan --notest_keep_going
dan --keep_going
sekaligus.
--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
yang berhasil dilaporkan sebagai FLAKY
pada ringkasan pengujian. Yaitu,
namun, dianggap telah diteruskan untuk
mengidentifikasi kode keluar Bazel
atau jumlah total pengujian yang lulus. Pengujian yang gagal pada semua
upaya yang diperbolehkan adalah
dianggap gagal.
Secara default (saat opsi ini tidak ditentukan, atau saat opsi ini disetel ke
default), hanya satu upaya yang diizinkan untuk pengujian reguler, dan
3 untuk aturan pengujian dengan atribut flaky
yang ditetapkan. Anda dapat menentukan
nilai bilangan bulat untuk mengganti batas maksimum upaya pengujian. Bazel mengizinkan
maksimal 10 kali percobaan untuk
mencegah penyalahgunaan sistem.
--runs_per_test=[regex@]number
Opsi ini menentukan berapa kali setiap pengujian harus dijalankan. Semua eksekusi uji diperlakukan sebagai pengujian terpisah (fungsi penggantian akan berlaku untuk setiap akun secara independen).
Status target dengan operasi gagal bergantung pada nilai
Tanda --runs_per_test_detects_flakes
:
- Jika tidak ada, kegagalan operasi akan menyebabkan seluruh pengujian gagal.
- Jika ada dan dua operasi dari shard yang sama akan menampilkan PASS dan GAGAL, maka pengujian akan menerima status tidak stabil (kecuali operasi gagal lainnya menyebabkan gagal).
Jika satu angka ditentukan, semua pengujian akan berjalan berkali-kali.
Atau, ekspresi reguler dapat ditentukan menggunakan sintaksis
ekspresi reguler@angka. Ini membatasi efek --runs_per_test
terhadap 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), Bazel akan mendeteksi ketidakstabilan
shard pengujian melalui --runs_per_test
. Jika satu atau beberapa dijalankan untuk satu shard
gagal dan satu atau beberapa operasi untuk shard pass yang sama, targetnya akan
dianggap tidak stabil dengan bendera tersebut. Jika tidak ditentukan, target akan melaporkan
status gagal.
--test_summary=output_style
Menentukan cara ringkasan hasil pengujian harus ditampilkan.
short
mencetak hasil setiap pengujian bersama dengan nama file yang berisi output pengujian jika pengujian gagal. Ini adalah default dengan sejumlah nilai.terse
sepertishort
, tetapi lebih singkat: hanya cetak informasi tentang pengujian yang tidak lulus.detailed
mencetak setiap kasus pengujian individu yang gagal, bukan hanya pada setiap pengujian. Nama file output pengujian dihilangkan.none
tidak mencetak ringkasan pengujian.
--test_output=output_style
Menentukan cara output pengujian harus ditampilkan:
summary
menampilkan ringkasan apakah setiap pengujian lulus atau gagal. Juga menampilkan nama file log output untuk pengujian yang gagal. Ringkasan akan dicetak di akhir build (selama build, orang akan melihat hanya pesan progres sederhana saat pengujian dimulai, lulus, atau gagal). Ini merupakan perilaku default.errors
mengirimkan output stdout/stderr gabungan dari pengujian yang gagal hanya ke {i>stdout<i} segera setelah pengujian selesai, memastikan bahwa output pengujian dari pengujian simultan tidak dilakukan interaksi satu sama lain. Mencetak ringkasan pada build sesuai dengan output ringkasan di atas.all
mirip denganerrors
tetapi mencetak output untuk semua pengujian, termasuk yang lulus.streamed
mengalirkan output stdout/stderr dari setiap pengujian di secara real-time.
--java_debug
Opsi ini menyebabkan mesin virtual Java dari pengujian java menunggu koneksi dari
Debugger yang mematuhi JDWP sebelum memulai pengujian. Opsi ini menyiratkan --test_output=streamed
.
--[no]verbose_test_summary
Secara default, opsi ini diaktifkan, sehingga menyebabkan waktu pengujian dan
informasi tambahan (seperti percobaan pengujian) untuk dicetak ke ringkasan pengujian. Jika
--noverbose_test_summary
ditentukan, ringkasan pengujian akan
hanya mencakup nama pengujian, status pengujian,
dan indikator pengujian yang di-cache, dan akan
diformat agar tetap dalam rentang 80 karakter jika memungkinkan.
--test_tmpdir=path
Menentukan direktori sementara untuk pengujian yang dijalankan secara lokal. Setiap pengujian akan
dijalankan dalam subdirektori terpisah di dalam direktori ini. Direktori tersebut akan
dibersihkan di awal setiap perintah bazel test
.
Secara {i>default<i}, {i>bazel<i} akan menempatkan direktori
ini di bawah direktori dasar {i>output<i} Bazel.
--test_timeout=seconds
ATAU --test_timeout=seconds,seconds,seconds,seconds
Mengganti nilai waktu tunggu untuk semua pengujian dengan menggunakan jumlah detik sebagai nilai waktu tunggu yang baru. Jika hanya satu nilai yang diberikan, maka itu akan digunakan untuk semua kategori waktu tunggu pengujian.
Atau, tersedia empat nilai yang dipisahkan koma yang menentukan waktu tunggu individual untuk pengujian singkat, sedang, panjang, dan abadi (dalam lainnya). Dalam bentuk apa pun, nilai nol atau negatif untuk setiap ukuran uji akan diganti dengan waktu tunggu {i>default<i} untuk kategori waktu tunggu yang ditentukan oleh halaman Ujian Menulis. Secara default, Bazel akan menggunakan waktu tunggu ini untuk semua pengujian dengan menginferensi batas waktu tunggu dari ukuran pengujian, secara implisit atau eksplisit.
Pengujian yang secara eksplisit menyatakan kategori waktu tunggu yang berbeda dengan akan menerima nilai yang sama seolah-olah waktu tunggu itu telah secara implisit disetel oleh tag ukuran. Jadi tes ukuran 'small' yang menyatakan 'long' (panjang) waktu tunggu akan memiliki waktu tunggu efektif yang sama dengan pengujian secara tidak eksplisit waktu tunggu habis.
--test_arg=arg
Meneruskan opsi/flag/argumen command line ke setiap proses pengujian. Ini
dapat digunakan beberapa kali untuk meneruskan beberapa argumen. Misalnya,
--test_arg=--logtostderr --test_arg=--v=3
.
--test_env=variable=_value_
ATAU --test_env=variable
Menentukan variabel tambahan yang harus dimasukkan ke dalam pengujian
untuk setiap pengujian. Jika value tidak ditentukan, maka
diwarisi dari lingkungan shell yang digunakan untuk memulai bazel test
perintah.
Lingkungan dapat diakses dari dalam pengujian menggunakan
System.getenv("var")
(Java), getenv("var")
(C atau C++),
--run_under=command-prefix
Ini menentukan awalan yang akan disisipkan oleh test runner di depan perintah {i>test<i} sebelum menjalankannya. Tujuan command-prefix dibagi menjadi kata-kata menggunakan shell Bourne aturan tokenization, lalu daftar kata ditambahkan ke yang akan dieksekusi.
Jika kata pertama adalah label yang sepenuhnya memenuhi syarat (dimulai dengan
//
) build tersebut. Kemudian label diganti dengan
lokasi yang sesuai yang dapat dieksekusi
yang ditambahkan ke perintah
yang akan dieksekusi
bersama dengan kata lainnya.
Beberapa peringatan berlaku:
- PATH yang digunakan untuk menjalankan pengujian mungkin berbeda dari PATH di lingkungan Anda,
jadi Anda mungkin perlu menggunakan jalur absolut untuk
--run_under
(kata pertama dalam command-prefix). stdin
tidak terhubung, jadi--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. Suatu kenyamanan filter nama umum dapat meneruskan argumen filter ke runner pengujian.
Opsi lain untuk bazel test
Sintaks dan opsi yang tersisa sama persis dengan
bazel build
Menjalankan file yang dapat dieksekusi
Perintah bazel run
mirip dengan bazel build
, kecuali
digunakan untuk membangun dan menjalankan satu target. Berikut adalah sesi umumnya:
% bazel run java/myapp:myapp -- --arg1 --arg2 Welcome to Bazel INFO: Loading package: java/myapp INFO: Loading package: foo/bar INFO: Loading complete. Analyzing... INFO: Found 1 target... ... Target //java/myapp:myapp up-to-date: bazel-bin/java/myapp:myapp INFO: Elapsed time: 0.638s, Critical Path: 0.34s INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2 Hello there $EXEC_ROOT/java/myapp/myapp --arg1 --arg2
bazel run
serupa, tetapi tidak sama, dalam memanggil langsung
biner yang dibuat oleh Bazel dan
perilakunya berbeda tergantung pada apakah
biner yang akan dipanggil
adalah tes atau tidak.
Ketika biner bukan merupakan tes, direktori kerja saat ini akan menjadi pohon {i>runfiles <i}dari biner.
Ketika biner adalah tes, direktori kerja saat ini akan menjadi {i>exec root<i}
dan upaya dengan niat baik dilakukan untuk
mereplikasi pengujian lingkungan biasanya
berlari. Emulasi ini tidak sempurna, dan pengujian yang memiliki beberapa
sharding tidak dapat dijalankan dengan cara ini (
Opsi command line --test_sharding_strategy=disabled
dapat digunakan
untuk mengatasi masalah ini)
Variabel lingkungan tambahan berikut juga tersedia untuk biner:
BUILD_WORKSPACE_DIRECTORY
: root ruang kerja tempat build telah dijalankan.BUILD_WORKING_DIRECTORY
: direktori kerja saat ini tempat Bazel dilarikan.
Ini dapat digunakan, misalnya, untuk menafsirkan nama file pada baris perintah di mudah digunakan.
Opsi untuk bazel run
--run_under=command-prefix
Ini memiliki efek yang sama dengan opsi --run_under
untuk
bazel test
(lihat di atas),
kecuali bahwa ini berlaku untuk perintah yang dijalankan oleh bazel
run
, bukan untuk pengujian yang dijalankan oleh bazel test
dan tidak dapat berjalan di bawah label.
Memfilter output logging dari Bazel
Saat memanggil biner dengan bazel run
, Bazel mencetak output logging dari Bazel
itu sendiri dan biner di pemanggilan. Untuk membuat log yang tidak berisik, Anda dapat
menyembunyikan output dari Bazel itu sendiri dengan --ui_event_filters
dan
--noshow_progress
.
Contoh:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
Menjalankan pengujian
bazel run
juga dapat menjalankan biner pengujian, yang memiliki efek
menjalankan pengujian pada perkiraan yang mendekati lingkungan seperti yang dijelaskan pada
Ujian Menulis. Perhatikan bahwa tidak satu pun
Argumen --test_*
berpengaruh saat menjalankan pengujian dengan cara ini kecuali
--test_arg
.
Membersihkan output build
Perintah clean
Bazel memiliki perintah clean
, yang serupa dengan Make.
Menghapus direktori output untuk semua konfigurasi build yang dilakukan
oleh {i>instance<i} Bazel ini, atau seluruh
pohon kerja yang dibuat oleh {i>instance<i}
instance Bazel, dan mereset cache internal. Jika dijalankan tanpa
opsi command line, lalu direktori output untuk semua konfigurasi
akan dibersihkan.
Ingat bahwa setiap {i>instance<i} Bazel dikaitkan dengan satu ruang kerja, sehingga
Perintah clean
akan menghapus semua output dari semua build yang telah Anda buat
dengan instance Bazel di ruang kerja tersebut.
Untuk sepenuhnya menghapus seluruh pohon kerja yang dibuat oleh Bazel
Anda dapat menentukan opsi --expunge
. Kapan
dieksekusi dengan --expunge
, perintah clean hanya akan
seluruh pohon dasar output yang, selain build
, berisi semua file {i>temp<i} yang dibuat oleh Bazel. Ini juga
menghentikan server Bazel setelah clean, yang setara dengan perintah shutdown
. Misalnya, untuk
membersihkan semua jejak {i>disk<i} dan memori
dari instance Bazel, Anda dapat
sebutkan:
% bazel clean --expunge
Atau, Anda dapat menghapus permanen di latar belakang dengan menggunakan
--expunge_async
. Anda dapat menjalankan
perintah Bazel secara aman
di klien yang sama sementara penghapusan asinkron terus berjalan.
Perintah clean
disediakan terutama sebagai cara
ruang {i>disk<i} untuk ruang
kerja yang tidak lagi diperlukan.
Rebuild inkremental Bazel mungkin tidak
sudah sempurna sehingga clean
dapat digunakan untuk memulihkan
menentukan kapan masalah muncul.
Desain Bazel sedemikian rupa sehingga
masalah ini dapat diperbaiki dan
{i>bug<i} ini memiliki prioritas
tinggi untuk diperbaiki. Jika Anda
menemukan build inkremental yang salah, ajukan laporan bug, dan laporkan bug di alat
daripada menggunakan clean
.
Membuat kueri grafik dependensi
Bazel menyertakan bahasa kueri untuk mengajukan pertanyaan tentang grafik dependensi yang digunakan selama build. Bahasa kueri digunakan oleh dua perintah: query dan cquery. Perbedaan utama antara dua perintah tersebut adalah kueri yang dijalankan setelah fase pemuatan dan kueri berjalan setelah fase analisis. Alat-alat ini adalah bantuan yang sangat berharga untuk banyak tugas rekayasa perangkat lunak.
Bahasa kueri didasarkan pada gagasan operasi aljabar di atas grafik; hal ini didokumentasikan secara rinci dalam
Referensi Kueri Bazel. Lihat dokumen tersebut sebagai referensi, untuk contoh, dan untuk opsi command line khusus kueri.
Alat kueri menerima beberapa command line
sebelumnya. --output
memilih format output.
--[no]keep_going
(dinonaktifkan secara default) menyebabkan kueri
alat untuk terus membuat kemajuan setelah terjadi kesalahan; perilaku ini mungkin
dinonaktifkan jika hasil yang tidak lengkap tidak dapat diterima jika terjadi error.
Opsi --[no]tool_deps
,
diaktifkan secara default, menyebabkan dependensi dalam konfigurasi non-target disertakan dalam
grafik dependensi di mana
kueri beroperasi.
Opsi --[no]implicit_deps
, yang diaktifkan secara default, menyebabkan
dependensi implisit untuk dimasukkan dalam grafik dependensi di mana kueri beroperasi. Channel
dependensi implisit adalah dependensi yang tidak secara eksplisit ditentukan dalam file BUILD
tapi ditambahkan oleh bazel.
Contoh: "Tampilkan lokasi definisi (dalam file BUILD) semua genrules yang diperlukan untuk membuat semua pengujian di pohon 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.
Analisis ini beroperasi pada grafik target pasca-analisis yang
terkonfigurasi dan mengekspos
informasi tentang tindakan, artefak
dan hubungannya.
Alat ini menerima beberapa opsi command line.
--output
memilih format output. Format output default
(text
) dapat dibaca manusia, gunakan proto
atau textproto
untuk
format yang dapat dibaca mesin.
Secara khusus, perintah {i>aquery<i} berjalan di atas
{i>build<i} Bazel biasa dan mewarisi
seperangkat opsi yang
tersedia selama proses build.
Alat ini mendukung serangkaian fungsi yang
sama yang juga tersedia untuk
query
tetapi siblings
, buildfiles
, dan
tests
.
Untuk detail selengkapnya, lihat Kueri Grafik Tindakan.
Perintah dan opsi lain-lain
help
Perintah help
memberikan bantuan online. Secara {i>default<i},
menunjukkan ringkasan perintah dan topik bantuan yang tersedia, seperti ditunjukkan dalam
Membuat aplikasi dengan Bazel.
Menentukan argumen menampilkan bantuan terperinci untuk
topik. Sebagian besar topik adalah perintah Bazel, seperti build
atau query
, tetapi ada beberapa topik bantuan tambahan
yang tidak sesuai dengan perintah.
--[no]long
(-l
)
Secara default, bazel help [topic]
hanya mencetak
ringkasan opsi yang relevan untuk suatu topik. Jika
opsi --long
ditentukan, jenis, nilai default
dan deskripsi lengkap
setiap opsi juga akan dicetak.
shutdown
Proses server Bazel dapat dihentikan dengan menggunakan shutdown
perintah. Perintah ini menyebabkan server
Bazel keluar segera setelah
menjadi tidak ada aktivitas (misalnya, setelah penyelesaian build atau
perintah yang sedang berlangsung). Untuk detail selengkapnya, lihat
Implementasi klien/server.
Server Bazel berhenti sendiri setelah waktu tunggu tidak ada aktivitas, jadi perintah ini jarang diperlukan; Namun, cara ini dapat berguna dalam skrip ketika mengetahui bahwa tidak ada pembangunan lebih lanjut yang akan terjadi di ruang kerja tertentu.
shutdown
menerima satu
--iff_heap_size_greater_than _n_
, yang mana
memerlukan argumen bilangan bulat (dalam MB). Jika ditentukan, akan membuat penonaktifan
tergantung pada jumlah
memori yang telah digunakan. Ini adalah
berguna untuk skrip yang memulai banyak build, karena setiap memori
kebocoran di server Bazel dapat
menyebabkan server mengalami {i>crash<i} secara palsu
acara; melakukan mulai ulang bersyarat akan men-preempt kondisi ini.
info
Perintah info
mencetak berbagai nilai yang terkait dengan
{i>instance<i} server Bazel, atau dengan
konfigurasi build khusus.
(Ini dapat digunakan oleh skrip yang mendorong build.)
Perintah info
juga mengizinkan satu (opsional)
, yang merupakan nama salah satu kunci dalam daftar di bawah ini.
Dalam hal ini, bazel info key
hanya akan mencetak
nilai untuk satu kunci tersebut. (Hal ini sangat nyaman ketika
membuat skrip Bazel, karena menghindari kebutuhan untuk menyalurkan hasil
sampai sed -ne /key:/s/key://p
:
Data yang tidak bergantung konfigurasi
release
: label rilis untuk Bazel ini instance, atau "versi pengembangan" jika ini tidak dirilis biner.workspace
jalur absolut ke ruang kerja dasar saat ini.install_base
: jalur absolut untuk menginstal yang digunakan oleh instance Bazel ini untuk pengguna saat ini. Roti Bazel menginstal {i>executable<i} yang dibutuhkan secara internal di bawah direktori ini.output_base
: jalur absolut ke output dasar yang digunakan oleh {i>instance<i} Bazel ini untuk pengguna saat ini dan kombinasi ruang kerja. Bazel bekerja dengan keras dan berkreasi di bawah direktori ini.execution_root
: jalur absolut ke eksekusi direktori {i>root <i}di bawah output_base. Direktori ini adalah {i>root<i} untuk semua file dapat diakses oleh perintah yang dieksekusi selama build, dan berfungsi untuk perintah tersebut. Jika direktori {i>workspace<i} dapat ditulis, symlink bernamabazel-<workspace>
ditempatkan di sana dan mengarahkan ke direktori ini.output_path
: jalur absolut ke output di bawah {i>root <i}eksekusi yang digunakan untuk semua file yang dihasilkan sebagai hasil dari perintah build. Jika direktori ruang kerja dapat ditulis, symlink bernamabazel-out
ditempatkan di sana ke direktori ini.server_pid
: ID proses server Bazel {i>checkout<i}.server_log
: jalur absolut ke file log debug server Bazel. File ini berisi informasi proses debug untuk semua perintah selama masa pakai Server Bazel, dan ditujukan untuk konsumsi manusia oleh pengembang dan pengguna super Bazel.command_log
: jalur absolut ke file log perintah; file ini berisi aliran stdout dan stderr yang disisipkan dari Perintah Bazel. Perlu diketahui bahwa menjalankanbazel info
akan menimpa isi file ini, karena kemudian menjadi perintah Bazel terbaru. Namun, lokasi file log perintah tidak akan berubah kecuali Anda ubah setelan--output_base
atau--output_user_root
opsi.used-heap-size
,committed-heap-size
,max-heap-size
: melaporkan berbagai ukuran heap JVM parameter. Masing-masing: memori yang saat ini digunakan, memori yang saat ini dipastikan akan tersedia untuk JVM dari sistem, alokasi yang memungkinkan.gc-count
,gc-time
: Jumlah kumulatif dari pengumpulan sampah sejak awal server Bazel ini dan waktu yang dihabiskan untuk menjalankannya. Perlu diketahui bahwa nilai ini tidak direset di awal setiap buat.package_path
: Daftar jalur yang dipisahkan titik dua yang akan mencari 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 mungkin terpengaruh oleh opsi konfigurasi yang diteruskan
ke bazel info
, untuk
contoh --cpu
, --compilation_mode
,
dll. Perintah info
menerima semua
opsi yang mengontrol dependensi
analisis, karena beberapa di antaranya menentukan lokasi
direktori {i>output<i} dari sebuah {i>build<i},
pilihan compiler, dll.
bazel-bin
,bazel-testlogs
,bazel-genfiles
: melaporkan jalur absolut ke direktoribazel-*
tempat program yang dihasilkan oleh telah ditemukan. Ini biasanya, meskipun tidak selalu, sama dengan symlinkbazel-*
yang dibuat di direktori ruang kerja dasar setelah berhasil dibuat. Namun, jika direktori Workspace bersifat hanya baca, tidak ada symlinkbazel-*
yang dapat dibuat. Skrip yang menggunakan nilai yang dilaporkan olehbazel info
, bukan mengasumsikan keberadaan {i>symlink<i}, akan lebih tangguh.- Lengkap
"Buat" lingkungan fleksibel. Jika flag
--show_make_env
yang ditentukan, semua variabel dalam konfigurasi saat ini. lingkungan juga ditampilkan (sepertiCC
,GLIBC_VERSION
, dll.). Ini adalah variabel yang diakses menggunakan$(CC)
atauvarref("CC")
di dalam file BUILD.
Contoh: compiler C++ untuk konfigurasi saat ini.
Ini adalah variabel $(CC)
di "Make" lingkungan,
jadi flag --show_make_env
diperlukan.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
Contoh: direktori output bazel-bin
untuk direktori saat ini
konfigurasi Anda. Hal ini dijamin akan tetap tepat
bahkan dalam kasus di mana
symlink bazel-bin
tidak dapat dibuat karena beberapa alasan
(misalnya, jika Anda membangun dari direktori hanya-baca).
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version
dan --version
Perintah versi mencetak detail versi tentang Bazel yang dibuat biner, termasuk daftar perubahan tempat layanan itu dibuat dan tanggalnya. Hal ini sangat berguna dalam menentukan apakah Anda memiliki Bazel, atau jika Anda melaporkan bug. Beberapa nilai menarik adalah:
changelist
: daftar perubahan tempat versi ini Bazel dibebaskan.label
: label rilis untuk Bazel ini instance, atau "versi pengembangan" jika ini tidak dirilis biner. Sangat berguna saat melaporkan bug.
bazel --version
, tanpa argumen lain, akan memberikan output yang sama dengan
bazel version --gnu_format
, kecuali tanpa efek samping dari kemungkinan memulai
server Bazel atau
membongkar arsip server. bazel --version
dapat dijalankan dari
di mana saja - tidak memerlukan direktori workspace.
mobile-install
Perintah mobile-install
menginstal aplikasi ke perangkat seluler.
Saat ini, hanya perangkat Android yang menjalankan ART yang didukung.
Lihat penginstalan seluler bazel untuk informasi selengkapnya.
Opsi berikut ini didukung:
--incremental
Jika diatur, Bazel akan mencoba menginstal aplikasi secara bertahap, yaitu
bagian yang telah berubah sejak build terakhir. Tindakan ini tidak dapat memperbarui resource
direferensikan dari AndroidManifest.xml
, kode native, atau Java
(seperti yang dirujuk oleh Class.getResource()
). Jika
hal-hal berubah, pilihan ini harus diabaikan. Bertentangan dengan semangat Bazel
dan karena keterbatasan platform Android,
tanggung jawab pengguna untuk mengetahui apakah perintah ini cukup baik dan
saat diperlukan penginstalan lengkap.
Jika Anda menggunakan perangkat dengan versi Marshmallow atau yang lebih baru, pertimbangkan
Flag --split_apks
.
--split_apks
Apakah akan menggunakan APK terpisah untuk menginstal dan mengupdate aplikasi di perangkat.
Hanya berfungsi pada perangkat yang menjalankan Marshmallow atau yang lebih baru. Perhatikan bahwa
Tanda --incremental
tidak diperlukan saat menggunakan --split_apks
.
--start_app
Memulai aplikasi dalam keadaan bersih setelah penginstalan. Setara dengan --start=COLD
.
--debug_app
Menunggu debugger terpasang sebelum memulai aplikasi dalam keadaan bersih setelah penginstalan.
Setara dengan --start=DEBUG
.
--start=_start_type_
Bagaimana aplikasi harus dimulai setelah menginstalnya. _start_type_s yang didukung adalah:
NO
Tidak memulai aplikasi. Ini adalah defaultnya.COLD
Memulai aplikasi dari kondisi bersih setelah penginstalan.WARM
Mempertahankan dan memulihkan status aplikasi pada penginstalan inkremental.DEBUG
Menunggu debugger sebelum memulai aplikasi dalam keadaan 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
. Ini ditempatkan sebelum subperintah di
baris perintah dan biasanya digunakan untuk
menentukan perangkat mana yang akan diinstal.
Misalnya, untuk memilih perangkat Android atau emulator yang akan digunakan:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
memanggil adb
sebagai
adb -s deadbeef install ...
--incremental_install_verbosity=number
Verbositas untuk penginstalan inkremental. Setel ke 1 agar logging debug menjadi yang dicetak ke konsol.
dump
Perintah dump
mencetak ke stdout dump dari
kondisi internal server Bazel. Perintah ini dimaksudkan
terutama untuk digunakan oleh pengembang Bazel, jadi {i>output<i} dari perintah ini
tidak ditentukan dan dapat berubah.
Secara {i>default<i}, perintah hanya akan mencetak pesan bantuan yang menguraikan kemungkinan opsi untuk membuang area tertentu dari status Bazel. Untuk membuang status internal, setidaknya salah satu opsi harus ditentukan.
Opsi berikut ini didukung:
--action_cache
membuang konten cache tindakan.--packages
membuang konten cache paket.--skyframe
membuang status grafik dependensi Bazel internal.--rules
menghapus ringkasan aturan untuk setiap aturan dan class aspek, termasuk jumlah dan jumlah tindakan. Ini mencakup aturan native dan Starlark. Jika pelacakan memori diaktifkan, aturan juga akan dicetak.--skylark_memory
membuang File .gz yang kompatibel dengan pprof ke jalur yang ditentukan. Anda harus mengaktifkan pelacakan memori agar tindakan ini berfungsi.
Pelacakan memori
Beberapa perintah dump
memerlukan pelacakan memori. Untuk mengaktifkannya, Anda harus meneruskan
flag startup ke Bazel:
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1
java-agent diperiksa di Bazel di
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
, jadi buat
pastikan Anda menyesuaikan $BAZEL
tempat Anda menyimpan repositori Bazel.
Jangan lupa untuk terus meneruskan opsi ini ke Bazel untuk setiap perintah atau server akan mulai ulang.
Contoh:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
Perintah analyze-profile
menganalisis data yang dikumpulkan sebelumnya
selama build menggunakan opsi --profile
. Alat ini menyediakan beberapa
opsi untuk melakukan analisis eksekusi build atau mengekspor data
format yang ditentukan.
Opsi berikut ini didukung:
--dump
menampilkan semua data yang dikumpulkan dalam dapat dibaca manusia. Namun, karena belum mendukung format lain.
Untuk detail format dan bantuan penggunaan, lihat Memecahkan masalah performa dengan pembuatan profil.
canonicalize-flags
canonicalize-flags
yang mengambil daftar opsi untuk perintah Bazel dan mengembalikan daftar
opsi yang memiliki efek sama. Daftar opsi baru ini bersifat kanonis. Misalnya,
dua daftar opsi dengan efek yang sama dikanonikalisasi ke daftar baru yang sama.
Opsi --for_command
dapat digunakan untuk memilih di antara berbagai
perintah. Saat ini, hanya build
dan test
yang
didukung. Opsi yang tidak didukung perintah tertentu menyebabkan error.
Sebagai contoh:
% bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint" --config=any_name --test_tag_filters=-lint
Opsi startup
Opsi yang dijelaskan di bagian ini memengaruhi startup Java mesin virtual yang digunakan oleh proses server Bazel, dan berlaku untuk semua perintah selanjutnya yang ditangani oleh server itu. Jika sudah ada menjalankan server Bazel dan opsi {i>startup<i} tidak sesuai, maka akan harus dimulai ulang.
Semua opsi yang dijelaskan dalam bagian ini harus ditentukan menggunakan
--key=value
atau --key value
sintaksis. Selain itu, opsi ini harus muncul sebelum nama Bazel
perintah. Gunakan startup --key=value
untuk mencantumkannya dalam file .bazelrc
.
--output_base=dir
Opsi ini memerlukan argumen jalur, yang harus menentukan yang dapat ditulis, {i>writable<i}. Bazel akan menggunakan lokasi ini untuk menulis semua {i>output<i} tersebut. Basis {i>output<i} juga merupakan kunci yang digunakan klien untuk menemukan server Bazel. Dengan mengubah basis {i>output<i}, Anda mengubah server yang akan menangani perintah tersebut.
Secara {i>default<i}, basis {i>output<i}
diperoleh dari nama {i>login<i} pengguna,
dan nama direktori ruang kerja (sebenarnya, ringkasan MD5-nya),
sehingga nilai umumnya terlihat seperti:
/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
.
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 serentak (karena
operator &
shell), masing-masing menggunakan Bazel yang berbeda
instance server (karena basis output yang berbeda).
Sebaliknya, jika basis {i>output<i} {i>default<i}
digunakan dalam kedua perintah,
maka kedua permintaan akan dikirim ke server yang sama, yang akan
menanganinya secara berurutan: membangun //foo
terlebih dahulu, diikuti
dengan build inkremental //bar
.
--output_user_root=dir
Mengarah ke direktori utama tempat output dan basis penginstalan dibuat. Direktori harus tidak ada atau dimiliki oleh pengguna yang memanggil. Di masa lalu, ini diizinkan untuk menunjuk ke direktori yang dibagikan di antara berbagai pengguna tapi itu tidak diizinkan lagi. Ini dapat diizinkan sekali masalah #11100 telah diatasi.
Jika opsi --output_base
ditentukan, opsi tersebut akan menggantikan
menggunakan --output_user_root
untuk menghitung basis output.
Lokasi basis penginstalan dihitung berdasarkan
--output_user_root
, ditambah identitas MD5 dari Bazel yang disematkan
biner.
Anda dapat menggunakan opsi --output_user_root
untuk memilih
lokasi dasar alternatif untuk semua output Bazel (bazel dan output
) jika ada lokasi yang lebih baik di tata letak sistem file.
--server_javabase=dir
Menentukan mesin virtual Java tempat Bazel itu sendiri berjalan. Nilai harus berupa jalur ke direktori yang berisi JDK atau JRE. Teks ini tidak boleh berupa label. Opsi ini seharusnya muncul sebelum perintah Bazel apa pun, misalnya:
% bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
Tanda ini tidak memengaruhi JVM yang digunakan oleh subproses Bazel seperti aplikasi, pengujian, alat, dan sebagainya. Gunakan opsi build --javabase atau Sebagai gantinya, --host_javabase.
Flag ini sebelumnya bernama --host_javabase
(terkadang disebut sebagai
'sebelah kiri' --host_javabase
), tetapi diganti namanya untuk menghindari kebingungan dengan
flag build --host_javabase (terkadang disebut sebagai
'sebelah kanan' --host_javabase
).
--host_jvm_args=string
Menentukan opsi startup yang akan diteruskan ke Java Virtual Machine tempat Bazel itu sendiri yang dijalankan. Ini dapat digunakan untuk menyetel ukuran tumpukan, misalnya:
% bazel --host_jvm_args="-Xss256K" build //foo
Opsi ini dapat digunakan beberapa kali dengan argumen individual. Perlu diketahui bahwa pengaturan penanda ini biasanya jarang diperlukan. Anda juga dapat meneruskan daftar string yang dipisahkan oleh spasi, yang masing-masing akan ditafsirkan sebagai argumen JVM yang terpisah, tetapi fitur ini akan segera tidak digunakan lagi.
Bahwa ini tidak memengaruhi JVM apa pun yang digunakan oleh
subproses Bazel: aplikasi, pengujian, alat, dan sebagainya. Untuk lulus
Dari opsi JVM ke program Java yang dapat dieksekusi, baik yang dijalankan oleh bazel
run
maupun di command line, Anda harus menggunakan
argumen --jvm_flags
yang
semua program java_binary
dan java_test
dukungan teknis IT. Atau untuk pengujian, gunakan bazel test --test_arg=--jvm_flags=foo ...
.
--host_jvm_debug
Opsi ini menyebabkan mesin virtual Java menunggu koneksi dari debugger yang sesuai dengan JDWP sebelum memanggil metode utama Bazel itu sendiri. Fungsi ini terutama yang ditujukan untuk digunakan oleh pengembang Bazel.
--autodetect_server_javabase
Opsi ini menyebabkan Bazel secara otomatis
mencari JDK yang terinstal saat dimulai,
dan kembali ke JRE yang terinstal jika JRE yang disematkan tidak tersedia.
--explicit_server_javabase
dapat digunakan untuk memilih JRE eksplisit untuk
yang digunakan Bazel.
--batch
Mode batch menyebabkan Bazel tidak menggunakan mode klien/server standar, tetapi menjalankan bazel proses java untuk satu perintah, yang telah digunakan agar lebih mudah diprediksi semantik yang berkaitan dengan penanganan sinyal, kontrol tugas, dan lingkungan pewarisan variabel, dan diperlukan untuk menjalankan bazel di penjara chroot.
Mode batch mempertahankan semantik antrean yang tepat dalam output_base yang sama. Artinya, pemanggilan simultan akan diproses secara berurutan, tanpa tumpang-tindih. Jika Bazel mode batch dijalankan pada klien dengan server yang berjalan, hal itu mematikan server sebelum memproses perintah itu.
Bazel akan berjalan lebih lambat dalam mode batch, atau dengan alternatif yang dijelaskan di atas. Ini karena, di antara hal-hal lain, cache file build bersifat permanen dengan memori, jadi dipertahankan di antara pemanggilan batch berurutan. Oleh karena itu, penggunaan mode batch sering kali lebih masuk akal ketika tidak begitu 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. Tujuan
nilai defaultnya adalah 10800 (3 jam). --max_idle_secs=0
akan menyebabkan
Proses server Bazel terus ada tanpa batas waktu.
Opsi ini dapat digunakan oleh skrip yang memanggil Bazel untuk memastikan bahwa
mereka tidak meninggalkan proses server Bazel
pada komputer pengguna ketika mereka
tidak akan berjalan jika tidak berfungsi.
Misalnya, skrip pra-pengiriman mungkin ingin
panggil bazel query
untuk memastikan
bahwa pengguna sedang menunggu persetujuan
tidak menimbulkan dependensi yang tidak diinginkan. Namun, jika
pengguna belum melakukan pembangunan terbaru di ruang kerja tersebut,
tidak diinginkan bagi skrip pra-pengiriman
untuk memulai server Bazel hanya
agar tetap menganggur
selama sisa hari itu.
Dengan menentukan nilai kecil --max_idle_secs
di kolom
permintaan kueri, skrip dapat memastikan bahwa jika menyebabkan
server untuk memulai, server itu akan segera
keluar, tetapi jika sebaliknya
sudah ada server yang berjalan, server itu akan tetap berjalan
hingga tidak ada aktivitas seperti biasanya. Tentu saja, teknologi yang sudah ada
timer tidak ada aktivitas server akan direset.
--[no]shutdown_on_low_sys_mem
Jika kebijakan ini disetel ke aktif dan --max_idle_secs
disetel ke durasi positif,
setelah server build tidak ada aktivitas selama beberapa waktu, matikan server saat sistem
kehabisan memori. Khusus Linux.
Selain menjalankan pemeriksaan tidak ada aktivitas yang berhubungan 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 hampir habis, server akan keluar.
--[no]block_for_lock
Jika diaktifkan, Bazel akan menunggu perintah Bazel lain yang menahan kunci server selesai sebelum melanjutkan. Jika dinonaktifkan, Bazel akan keluar dengan error jika tidak bisa segera memperoleh kunci dan lanjutkan.
Developer dapat menggunakannya dalam pemeriksaan prapengiriman untuk menghindari waktu tunggu yang lama 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 terendah. Penjadwal antisipatif mungkin hanya memenuhi prioritas 4. Nilai negatif akan diabaikan.
--batch_cpu_scheduling
Gunakan penjadwalan CPU batch
untuk Bazel. Kebijakan ini bermanfaat bagi
beban kerja yang non-interaktif, tetapi tidak ingin menurunkan nilainya.
Lihat 'man 2 sched_setscheduler'. Kebijakan ini dapat memberikan kualitas sistem yang lebih baik
interaktivitas dengan mengorbankan throughput Bazel.
Opsi lain-lain
--[no]announce_rc
Mengontrol apakah Bazel mengumumkan opsi 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 menyorot {i>outputnya<i} di layar.
Jika opsi ini disetel ke yes
, output warna akan diaktifkan.
Jika opsi ini disetel ke auto
, Bazel akan menggunakan output warna hanya jika
{i>output<i} dikirim ke terminal dan variabel lingkungan TERM
ditetapkan ke nilai selain dumb
, emacs
, atau xterm-mono
.
Jika opsi ini disetel ke no
, output warna akan dinonaktifkan,
terlepas dari apakah {i>output<i} masuk ke terminal dan terlepas dari
dari pengaturan variabel lingkungan TERM.
--config=name
Memilih bagian konfigurasi tambahan dari
file rc; untuk command
saat ini,
cara ini juga menarik opsi dari command:name
jika ada bagian seperti itu. Bisa
ditentukan beberapa kali untuk menambahkan flag dari beberapa bagian konfigurasi. Perluasan dapat mengacu pada
(misalnya, perluasan dapat dirantai).
--curses (yes|no|auto)
Opsi ini menentukan apakah Bazel akan menggunakan kontrol kursor
dalam output layarnya. Ini menghasilkan lebih sedikit data
yang bergulir, dan lebih banyak
aliran {i>output<i} yang ringkas dan mudah dibaca dari Bazel. Ini berfungsi baik dengan
--color
.
Jika opsi ini disetel ke yes
, penggunaan kontrol kursor akan diaktifkan.
Jika opsi ini disetel ke no
, penggunaan kontrol kursor akan dinonaktifkan.
Jika opsi ini disetel ke auto
, penggunaan kontrol kursor akan
diaktifkan dalam kondisi yang sama seperti untuk --color=auto
.
--[no]show_timestamps
Jika ditentukan, stempel waktu akan ditambahkan ke setiap pesan yang dibuat oleh Bazel yang menentukan waktu saat pesan ditampilkan.