Tindakan
Perintah yang akan dijalankan selama build, misalnya, panggilan ke compiler yang menggunakan artefak sebagai input dan menghasilkan artefak lain sebagai output. Mencakup metadata seperti argumen command line, kunci tindakan, variabel lingkungan, dan artefak input/output yang dideklarasikan.
Lihat juga: Dokumentasi aturan
Cache tindakan
Cache di disk yang menyimpan pemetaan tindakan yang dieksekusi ke output yang dibuatnya. Kunci cache dikenal sebagai kunci tindakan. Komponen inti untuk model inkrementalitas Bazel. Cache disimpan di direktori dasar output sehingga tetap ada saat server Bazel dimulai ulang.
Grafik tindakan
Grafik dalam memori dari tindakan dan artefak yang
dibaca dan dihasilkan oleh tindakan ini. Grafik dapat menyertakan artefak yang ada sebagai
file sumber (misalnya, dalam sistem file) serta
artefak perantara/akhir yang dihasilkan yang tidak disebutkan dalam file BUILD. Dibuat
selama fase analisis dan digunakan selama fase
eksekusi.
Kueri grafik tindakan (aquery)
Alat kueri yang dapat membuat kueri berdasarkan tindakan build. Hal ini memberikan kemampuan untuk menganalisis bagaimana aturan build diterjemahkan ke dalam build pekerjaan yang sebenarnya.
Tombol tindakan
Kunci cache tindakan. Dihitung berdasarkan metadata tindakan, yang mungkin mencakup perintah yang akan dieksekusi dalam tindakan, flag compiler, lokasi library, atau header sistem, bergantung pada tindakan. Memungkinkan Bazel menyimpan dalam cache atau membatalkan setiap tindakan secara deterministik.
Fase analisis
Fase kedua build. Memproses grafik target
yang ditentukan dalam file BUILD untuk menghasilkan grafik
tindakan dalam memori yang menentukan urutan tindakan yang akan dijalankan selama
fase eksekusi. Ini adalah fase saat penerapan
aturan dievaluasi.
Artefak
File sumber atau file yang dihasilkan. Dapat juga berupa direktori file, yang dikenal sebagai artefak hierarki.
Artefak dapat berupa input untuk beberapa tindakan, tetapi hanya boleh dihasilkan oleh maksimal satu tindakan.
Artefak yang sesuai dengan target file dapat ditangani oleh label.
Aspek
Mekanisme untuk aturan guna membuat tindakan tambahan dalam
dependensinya. Misalnya, jika target A bergantung pada B, seseorang dapat menerapkan aspek pada
A yang melintasi ke atas tepi dependensi ke B, dan menjalankan tindakan tambahan di B
untuk membuat dan mengumpulkan file output tambahan. Tindakan tambahan ini
di-cache dan digunakan kembali di antara target yang memerlukan aspek yang sama. Dibuat dengan
fungsi aspect() Starlark Build API. Dapat digunakan, misalnya, untuk membuat
metadata untuk IDE, dan membuat tindakan untuk linting.
Lihat juga: Dokumentasi aspek
Aspek-pada-aspek
Mekanisme komposisi yang memungkinkan aspek diterapkan ke hasil
aspek lainnya. Misalnya, aspek yang menghasilkan informasi untuk digunakan oleh IDE dapat diterapkan di atas aspek yang menghasilkan file .java dari proto.
Agar aspek A diterapkan di atas aspek B, penyedia yang
B iklankan dalam atribut provides
harus cocok dengan yang A deklarasikan dalam atribut
required_aspect_providers.
Atribut
Parameter ke aturan, yang digunakan untuk menyatakan informasi build per target.
Contohnya mencakup srcs, deps, dan copts, yang masing-masing mendeklarasikan
file sumber, dependensi, dan opsi compiler kustom target. Atribut
tertentu yang tersedia untuk target tertentu bergantung pada jenis aturannya.
.bazelrc
File konfigurasi Bazel digunakan untuk mengubah nilai default untuk flag
startup dan flag perintah, serta untuk menentukan grup
opsi umum yang kemudian dapat ditetapkan bersama di command line Bazel menggunakan
flag --config. Bazel dapat menggabungkan setelan dari beberapa file bazelrc
(seluruh sistem, per ruang kerja, per pengguna, atau dari lokasi kustom), dan
file bazelrc juga dapat mengimpor setelan dari file bazelrc lainnya.
Blaze
Bazel versi internal Google. Sistem build utama Google untuk mono-repositorinya.
File BUILD
File BUILD adalah file konfigurasi utama yang memberi tahu Bazel output
software yang akan di-build, dependensinya, dan cara mem-build-nya. Bazel
mengambil file BUILD sebagai input dan menggunakan file tersebut untuk membuat grafik dependensi
dan untuk mendapatkan tindakan yang harus diselesaikan untuk mem-build output
software menengah dan akhir. File BUILD menandai direktori dan subdirektori apa pun yang tidak
berisi file BUILD sebagai paket, dan dapat berisi
target yang dibuat oleh aturan. File juga dapat diberi nama
BUILD.bazel.
File BUILD.bazel
Lihat File BUILD. Lebih diprioritaskan daripada file BUILD di direktori
yang sama.
File .bzl
File yang menentukan aturan, makro, dan konstanta yang ditulis dalam
Starlark. Kemudian, file ini dapat diimpor ke file BUILD menggunakan fungsi load().
Membuat grafik
Grafik dependensi yang dibuat dan dijelajahi Bazel untuk melakukan build. Mencakup node seperti target, target yang dikonfigurasi, tindakan, dan artefak. Build dianggap selesai saat semua artefak yang menjadi dependensi serangkaian target yang diminta diverifikasi sebagai yang terbaru.
Setelan build
Bagian konfigurasi yang ditentukan Starlark. Transisi dapat menetapkan setelan build untuk mengubah konfigurasi subgrafik. Jika ditampilkan kepada pengguna sebagai flag command line, juga dikenal sebagai flag build.
Build bersih
Build yang tidak menggunakan hasil build sebelumnya. Hal ini umumnya lebih lambat daripada build inkremental, tetapi biasanya dianggap lebih benar. Bazel menjamin build bersih dan inkremental selalu benar.
Model klien-server
Klien command line bazel otomatis memulai server latar belakang di
mesin lokal untuk menjalankan perintah Bazel. Server tetap ada di seluruh perintah, tetapi otomatis berhenti setelah periode tidak aktif (atau secara eksplisit melalui penghentian bazel). Memisahkan Bazel menjadi server dan klien membantu mengamortisasi waktu startup JVM
dan mendukung build inkremental yang lebih cepat
karena grafik tindakan tetap berada dalam memori di seluruh perintah.
Perintah
Digunakan di command line untuk memanggil berbagai fungsi Bazel, seperti bazel
build, bazel test, bazel run, dan bazel query.
Flag perintah
Kumpulan flag khusus untuk perintah. Flag perintah ditentukan
setelah perintah (bazel build <command flags>). Flag dapat berlaku untuk
satu atau beberapa perintah. Misalnya, --configure adalah flag khusus untuk
perintah bazel sync, tetapi --keep_going berlaku untuk sync, build,
test, dan lainnya. Flag sering digunakan untuk tujuan konfigurasi, sehingga perubahan nilai flag dapat menyebabkan Bazel membatalkan validasi grafik
dalam memori dan memulai ulang fase analisis.
Konfigurasi
Informasi di luar definisi aturan yang memengaruhi cara aturan menghasilkan tindakan. Setiap build memiliki setidaknya satu konfigurasi yang menentukan platform target, variabel lingkungan tindakan, dan flag build command line. Transisi dapat membuat konfigurasi tambahan, seperti untuk alat host atau kompilasi silang.
Lihat juga: Konfigurasi
Pemangkasan konfigurasi
Proses yang hanya menyertakan bagian konfigurasi yang benar-benar diperlukan target. Misalnya, jika Anda mem-build //:j biner Java dengan dependensi
C++ //:c, akan sia-sia jika menyertakan nilai --javacopt dalam
konfigurasi //:c karena mengubah --javacopt tidak perlu merusak cache build
C++.
Kueri yang dikonfigurasi (cquery)
Alat kueri yang membuat kueri di seluruh target yang dikonfigurasi (setelah fase analisis selesai). Artinya, select() dan flag build (seperti
--platforms) tercermin secara akurat dalam hasil.
Lihat juga: dokumentasi cquery
Target yang dikonfigurasi
Hasil evaluasi target dengan
konfigurasi. Fase analisis menghasilkan
hal ini dengan menggabungkan opsi build dengan target yang perlu dibuat.
Misalnya, jika //:foo di-build untuk dua arsitektur yang berbeda dalam build
yang sama, //:foo memiliki dua target yang dikonfigurasi: <//:foo, x86> dan <//:foo, arm>.
Ketepatan
Build sudah benar jika outputnya mencerminkan status input transitifnya dengan akurat. Untuk mencapai build yang benar, Bazel berusaha untuk hermetis, dapat direproduksi, dan membuat analisis build dan eksekusi tindakan deterministik.
Dependensi
Tepi terarah antara dua target. //:foo target memiliki dependensi
target pada //:bar target jika nilai atribut //:foo berisi
referensi ke //:bar. //:foo memiliki dependensi tindakan pada //:bar jika
tindakan di //:foo bergantung pada artefak input yang dibuat oleh
tindakan di //:bar.
Dalam konteks tertentu, modul juga dapat merujuk ke dependensi eksternal; lihat modul.
Depset
Struktur data untuk mengumpulkan data tentang dependensi transitif. Dioptimalkan sehingga penggabungan depset hemat waktu dan ruang, karena depset yang sangat besar (ratusan ribu file) adalah hal yang umum. Diimplementasikan untuk merujuk secara berulang ke depset lain karena alasan efisiensi ruang. Implementasi Aturan tidak boleh "meratakan" depset dengan mengonversinya menjadi daftar, kecuali jika aturan berada di tingkat teratas grafik build. Meratakan depset besar akan menyebabkan konsumsi memori yang sangat besar. Juga dikenal sebagai set bertingkat dalam implementasi internal Bazel.
Lihat juga: Dokumentasi depset
Cache disk
Penyimpanan blob lokal di disk untuk fitur penyimpanan dalam cache jarak jauh. Dapat digunakan bersama dengan penyimpanan blob jarak jauh yang sebenarnya.
Distdir
Direktori hanya baca yang berisi file yang akan diambil Bazel dari internet menggunakan aturan repositori. Memungkinkan build berjalan sepenuhnya secara offline.
Eksekusi dinamis
Strategi eksekusi yang memilih antara eksekusi lokal dan jarak jauh berdasarkan berbagai heuristik, dan menggunakan hasil eksekusi dari metode yang berhasil lebih cepat. Tindakan tertentu dijalankan lebih cepat secara lokal (misalnya, penautan) dan tindakan lainnya lebih cepat dari jarak jauh (misalnya, kompilasi yang sangat paralel). Strategi eksekusi dinamis dapat memberikan waktu build bersih dan inkremental terbaik.
Fase eksekusi
Fase ketiga build. Menjalankan tindakan dalam grafik tindakan yang dibuat selama fase analisis. Tindakan ini memanggil file yang dapat dieksekusi (compiler, skrip) untuk membaca dan menulis artefak. Strategi spawn mengontrol cara tindakan ini dijalankan: secara lokal, jarak jauh, dinamis, sandbox, docker, dan sebagainya.
Root eksekusi
Direktori di direktori basis output
ruang kerja tempat tindakan lokal dijalankan dalam
build non-dengan sandbox. Konten direktori sebagian besar adalah symlink
artefak input dari ruang kerja. Root eksekusi juga
berisi symlink ke repositori eksternal sebagai input lainnya dan direktori bazel-out
untuk menyimpan output. Disiapkan selama fase pemuatan
dengan membuat hutan symlink dari direktori yang mewakili penutupan
transisional paket yang menjadi dependensi build. Dapat diakses dengan bazel info
execution_root di command line.
File
Lihat Artefak.
Hermetisitas
Build bersifat hermetis jika tidak ada pengaruh eksternal pada operasi build dan pengujiannya, yang membantu memastikan bahwa hasilnya bersifat deterministik dan benar. Misalnya, build hermetis biasanya tidak mengizinkan akses jaringan ke tindakan, membatasi akses ke input yang dideklarasikan, menggunakan stempel waktu dan zona waktu tetap, membatasi akses ke variabel lingkungan, dan menggunakan seed tetap untuk generator angka acak
Build inkremental
Build inkremental menggunakan kembali hasil build sebelumnya untuk mengurangi waktu build dan penggunaan resource. Pemeriksaan dan penyimpanan dalam cache dependensi bertujuan untuk menghasilkan hasil yang benar untuk jenis build ini. Build inkremental adalah kebalikan dari build bersih.
Label
ID untuk target. Umumnya memiliki bentuk
@repo//path/to/package:target, dengan repo adalah nama (yang terlihat) dari
repositori yang berisi target, path/to/package adalah jalur
ke direktori yang berisi file BUILD yang mendeklarasikan
target (direktori ini juga dikenal sebagai paket), dan target
adalah nama target itu sendiri. Bergantung pada situasinya, bagian sintaksis ini
dapat dihilangkan.
Lihat juga: Label
Fase pemuatan
Fase pertama build tempat Bazel mengeksekusi file BUILD untuk
membuat paket. Makro dan fungsi tertentu seperti
glob() dievaluasi dalam fase ini. Diinterleave dengan fase kedua
build, fase analisis, untuk membuat grafik
target.
Makro lama
Varian makro yang dideklarasikan sebagai fungsi
Starlark biasa, dan yang berjalan sebagai efek samping dari mengeksekusi
file BUILD.
Makro lama dapat melakukan apa pun yang dapat dilakukan fungsi. Artinya, kode tersebut dapat memudahkan,
tetapi juga dapat lebih sulit dibaca, ditulis, dan digunakan. Makro lama mungkin
melakukan mutasi argumennya secara tidak terduga atau gagal saat diberi argumen select() atau argumen
yang salah.
Berbeda dengan makro simbolis.
Lihat juga: Dokumentasi makro lama
Macro
Mekanisme untuk menyusun beberapa deklarasi target rule secara bersamaan dalam
satu Starlark yang dapat dipanggil. Memungkinkan penggunaan kembali pola deklarasi aturan umum di seluruh file BUILD. Diperluas ke deklarasi target aturan dasar selama fase pemuatan.
Tersedia dalam dua ragam: makro simbolis (sejak Bazel 8) dan makro lama.
Mnemonik
String pendek yang dapat dibaca manusia yang dipilih oleh penulis aturan untuk dengan cepat memahami
apa yang dilakukan tindakan dalam aturan. Mnemonik dapat digunakan sebagai
ID untuk pemilihan strategi spawn. Beberapa contoh mnemoni tindakan
adalah Javac dari aturan Java, CppCompile dari aturan C++, dan
AndroidManifestMerger dari aturan Android.
Modul
Project Bazel yang dapat memiliki beberapa versi, yang masing-masing dapat memiliki dependensi pada modul lain. Hal ini mirip dengan konsep yang sudah dikenal di sistem pengelolaan dependensi lainnya, seperti artefak Maven, paket npm, modul Go, atau crate Cargo. Modul membentuk tulang punggung sistem pengelolaan dependensi eksternal Bazel.
Setiap modul didukung oleh repo dengan file MODULE.bazel di
root-nya. File ini berisi metadata tentang modul itu sendiri (seperti nama dan
versinya), dependensi langsungnya, dan berbagai data lainnya termasuk pendaftaran
toolchain dan input ekstensi modul.
Metadata modul dihosting di registry Bazel.
Lihat juga: Modul Bazel
Ekstensi Modul
Bagian logika yang dapat dijalankan untuk membuat repo dengan membaca input dari seluruh grafik dependensi modul dan memanggil aturan repo. Ekstensi modul memiliki kemampuan yang mirip dengan aturan repo, yang memungkinkannya mengakses internet, melakukan I/O file, dan sebagainya.
Lihat juga: Ekstensi modul
Aturan native
Aturan yang disertakan dalam Bazel dan diterapkan di Java. Aturan tersebut muncul di file .bzl sebagai fungsi dalam modul native (misalnya, native.cc_library atau native.java_library). Aturan yang ditentukan pengguna (non-native) dibuat menggunakan Starlark.
Dasar output
Direktori khusus ruang kerja untuk menyimpan file output Bazel. Digunakan untuk memisahkan output dari hierarki sumber ruang kerja (repo utama). Berada di root pengguna output.
Grup output
Sekelompok file yang diharapkan akan di-build saat Bazel selesai mem-build
target. Aturan menempatkan output biasanya di "grup output default"
(misalnya, file .jar dari java_library, .a, dan .so untuk target
cc_library). Grup output default adalah grup output yang
artefak-nya di-build saat target diminta di command line.
Aturan dapat menentukan lebih banyak grup output bernama yang dapat ditentukan secara eksplisit dalam
file BUILD (aturan filegroup) atau command line
(flag --output_groups).
Root pengguna output
Direktori khusus pengguna untuk menyimpan output Bazel. Nama direktori diperoleh dari nama pengguna sistem pengguna. Mencegah konflik file output jika beberapa pengguna mem-build project yang sama di sistem secara bersamaan. Berisi subdirektori yang sesuai dengan output build dari setiap ruang kerja, juga dikenal sebagai basis output.
Paket
Kumpulan target yang ditentukan oleh file BUILD. Nama
paket adalah jalur file BUILD yang relatif terhadap root
repo. Paket dapat berisi subpaket, atau subdirektori yang berisi file
BUILD, sehingga membentuk hierarki paket.
Grup paket
Target yang mewakili sekumpulan paket. Sering digunakan dalam nilai atribut
visibility.
Platform
"Jenis mesin" yang terlibat dalam build. Ini mencakup mesin tempat Bazel berjalan (platform "host"), alat build mesin yang dijalankan di ("platform exec"), dan target mesin yang dibuat untuk ("target platform").
Penyedia
Skema yang menjelaskan unit informasi yang akan diteruskan antara
target aturan di sepanjang hubungan dependensi. Biasanya, file ini
berisi informasi seperti opsi compiler, file sumber atau output transitif,
dan metadata build. Sering digunakan bersama dengan depsets untuk
menyimpan data transitif yang terakumulasi secara efisien. Contoh penyedia bawaan
adalah DefaultInfo.
Lihat juga: Dokumentasi penyedia
Kueri (konsep)
Proses menganalisis grafik build untuk memahami properti target dan struktur dependensi. Bazel mendukung tiga varian kueri: query, cquery, dan aquery.
kueri (perintah)
Alat kueri yang beroperasi di grafik target build pascafase
pemuatan. Proses ini relatif cepat,
tetapi tidak dapat menganalisis efek select(), flag build,
artefak, atau membuat tindakan.
Lihat juga: Cara membuat kueri, Referensi kueri
Repositori
Hierarki direktori dengan file penanda batas di root-nya, yang berisi file sumber yang dapat digunakan dalam build Bazel. Sering disingkat menjadi repo.
File penanda batas repo dapat berupa MODULE.bazel (menandakan bahwa repo ini
mewakili modul Bazel), REPO.bazel, atau dalam konteks lama, WORKSPACE atau
WORKSPACE.bazel. Setiap file penanda batas repo akan menunjukkan batas repo; beberapa file tersebut dapat berdampingan dalam direktori.
Repo utama adalah repo tempat perintah Bazel saat ini dijalankan.
Repositori eksternal ditentukan dengan menentukan modul dalam file
MODULE.bazel, atau memanggil aturan repo di ekstensi
modul. Data tersebut dapat diambil sesuai permintaan ke lokasi "ajaib"
yang telah ditentukan di disk.
Setiap repo memiliki nama kanonis yang unik dan konstan, serta nama tampak yang berpotensi berbeda saat dilihat dari repo lain.
Lihat juga: Ringkasan dependensi eksternal
Cache repositori
Cache file yang dapat dialamatkan konten bersama yang didownload oleh Bazel untuk build,
yang dapat dibagikan di seluruh ruang kerja. Mengaktifkan build offline setelah
download awal. Umumnya digunakan untuk meng-cache file yang didownload melalui aturan repositori seperti http_archive dan API aturan repositori seperti repository_ctx.download. File hanya di-cache jika checksum SHA-256-nya ditentukan untuk download.
Aturan repositori
Skema untuk definisi repositori yang memberi tahu Bazel cara mewujudkan (atau
"mengambil") repositori. Sering disingkat menjadi aturan repo.
Aturan repo dipanggil oleh Bazel secara internal untuk menentukan repo yang didukung oleh
modul, atau dapat dipanggil oleh ekstensi modul.
Aturan repo dapat mengakses internet atau melakukan I/O file; aturan repo
yang paling umum adalah http_archive untuk mendownload arsip yang berisi file sumber dari
internet.
Lihat juga: Dokumentasi aturan repo
Reproduktivitas
Properti build atau pengujian bahwa serangkaian input ke build atau pengujian akan selalu menghasilkan serangkaian output yang sama setiap saat, terlepas dari waktu, metode, atau lingkungan. Perhatikan bahwa hal ini tidak selalu menyiratkan bahwa output benar atau output yang diinginkan.
Aturan
Skema untuk menentukan target aturan dalam file BUILD, seperti
cc_library. Dari perspektif penulis file BUILD, aturan terdiri dari
serangkaian atribut dan logika kotak hitam. Logika ini memberi tahu
target aturan cara menghasilkan artefak output dan meneruskan informasi ke
target aturan lainnya. Dari perspektif penulis .bzl, aturan adalah
cara utama untuk memperluas Bazel guna mendukung bahasa dan
lingkungan pemrograman baru.
Aturan dibuat instance-nya untuk menghasilkan target aturan dalam fase pemuatan. Pada fase analisis, target aturan menyampaikan informasi ke dependensi downstream dalam bentuk penyedia, dan mendaftarkan tindakan yang menjelaskan cara membuat artefak output. Tindakan ini dijalankan dalam fase eksekusi.
Lihat juga: Dokumentasi aturan
Target aturan
Target yang merupakan instance aturan. Berbeda dengan target file dan grup paket. Jangan samakan dengan aturan.
Runfiles
Dependensi runtime dari target yang dapat dieksekusi. Biasanya, file yang dapat dieksekusi adalah output yang dapat dieksekusi dari aturan pengujian, dan runfile adalah dependensi data runtime pengujian. Sebelum pemanggilan file yang dapat dieksekusi (selama pengujian bazel), Bazel menyiapkan hierarki runfile bersama dengan file yang dapat dieksekusi pengujian sesuai dengan struktur direktori sumbernya.
Lihat juga: Dokumentasi runfile
Sandboxing
Teknik untuk mengisolasi tindakan yang sedang berjalan di dalam root eksekusi sementara dan dibatasi, yang membantu memastikan tindakan tersebut tidak membaca input yang tidak dideklarasikan atau menulis output yang tidak dideklarasikan. Sandboxing sangat meningkatkan hermetisitas, tetapi biasanya memiliki biaya performa, dan memerlukan dukungan dari sistem operasi. Biaya performa bergantung pada platform. Di Linux, hal ini tidak signifikan, tetapi di macOS, hal ini dapat membuat sandboxing tidak dapat digunakan.
Skyframe
Skyframe adalah framework evaluasi inti paralel, fungsional, dan inkremental Bazel.
Pengecapan
Fitur untuk menyematkan informasi tambahan ke dalam
artefak yang dibuat Bazel. Misalnya, ini dapat digunakan untuk kontrol sumber, waktu
build, dan informasi terkait lingkungan atau ruang kerja lainnya untuk build rilis.
Aktifkan melalui flag --workspace_status_command dan aturan yang
mendukung atribut stempel.
Starlark
Bahasa ekstensi untuk menulis aturan dan makro. Subkumpulan
Python yang dibatasi (secara sintaksis dan tata bahasa) yang ditujukan untuk
tujuan konfigurasi, dan untuk performa yang lebih baik. Menggunakan ekstensi file
.bzl. File BUILD menggunakan versi Starlark yang lebih terbatas (seperti tidak ada definisi fungsi def), yang sebelumnya dikenal sebagai Skylark.
Lihat juga: Dokumentasi bahasa Starlark
Flag startup
Kumpulan flag yang ditentukan antara bazel dan perintah,
misalnya, build bazel --host_jvm_debug. Flag ini mengubah
konfigurasi server Bazel, sehingga setiap modifikasi pada
flag startup akan menyebabkan server dimulai ulang. Flag startup tidak spesifik untuk perintah
apa pun.
Makro simbolis
Varian makro yang dideklarasikan dengan skema atribut seperti aturan, memungkinkan penyembunyian target internal yang dideklarasikan dari paketnya sendiri, dan menerapkan pola penamaan yang dapat diprediksi pada target yang dideklarasikan makro. Dirancang untuk menghindari beberapa masalah yang terlihat di codebase makro lama yang besar.
Lihat juga: Dokumentasi makro simbolis
Target
Objek yang ditentukan dalam file BUILD dan diidentifikasi oleh
label. Target mewakili unit ruang kerja yang dapat di-build dari
sudut pandang pengguna akhir.
Target yang dideklarasikan dengan membuat instance aturan disebut target
aturan. Bergantung pada aturan, target ini dapat dijalankan (seperti cc_binary) atau diuji (seperti cc_test). Target aturan biasanya bergantung pada target lain melalui atribut-nya (seperti deps); dependensi ini membentuk dasar grafik target.
Selain target aturan, ada juga target file dan target
grup paket. Target file sesuai dengan artefak yang direferensikan
dalam file BUILD. Sebagai kasus khusus, file BUILD dari paket apa pun
selalu dianggap sebagai target file sumber dalam paket tersebut.
Target ditemukan selama fase pemuatan. Selama fase analisis, target dikaitkan dengan konfigurasi build untuk membentuk target yang dikonfigurasi.
Grafik target
Grafik dalam memori dari target dan dependensinya. Dibuat selama fase pemuatan dan digunakan sebagai input untuk fase analisis.
Pola target
Cara menentukan grup target di command line. Pola yang biasa
digunakan adalah :all (semua target aturan), :* (semua target aturan + file),
... (paket saat ini dan semua subpaket secara berulang). Dapat digunakan
secara kombinasi, misalnya, //...:* berarti semua target aturan dan file di semua
paket secara berulang dari root ruang kerja.
Pengujian
Target aturan dibuat instance-nya dari aturan pengujian, sehingga berisi pengujian yang dapat dieksekusi. Kode return nol dari penyelesaian file yang dapat dieksekusi menunjukkan keberhasilan pengujian. Kontrak yang tepat antara Bazel dan pengujian (seperti variabel lingkungan pengujian, metode pengumpulan hasil pengujian) ditentukan dalam Ensiklopedia Pengujian.
Toolchain
Kumpulan alat untuk mem-build output untuk suatu bahasa. Biasanya, toolchain mencakup compiler, penaut, penafsir, atau/dan linter. Toolchain juga dapat bervariasi menurut platform, yaitu, komponen toolchain compiler Unix dapat berbeda untuk varian Windows, meskipun toolchain tersebut ditujukan untuk bahasa yang sama. Memilih toolchain yang tepat untuk platform dikenal sebagai resolusi toolchain.
Target tingkat teratas
Target build adalah tingkat teratas jika diminta di command line
Bazel. Misalnya, jika //:foo bergantung pada //:bar, dan bazel build //:foo
dipanggil, maka untuk build ini, //:foo adalah tingkat atas, dan //:bar tidak
tingkat atas, meskipun kedua target harus dibuat. Perbedaan penting
antara target tingkat teratas dan non-tingkat teratas adalah bahwa flag
perintah yang ditetapkan di command line Bazel (atau melalui
.bazelrc) akan menetapkan konfigurasi untuk target
tingkat teratas, tetapi dapat diubah oleh transisi untuk target
non-tingkat teratas.
Transisi
Pemetaan status konfigurasi dari satu nilai ke nilai lainnya. Memungkinkan target di grafik build memiliki konfigurasi yang berbeda, meskipun dibuat instance-nya dari aturan yang sama. Penggunaan transisi yang umum adalah dengan transisi split, dengan bagian tertentu dari grafik target di-fork dengan konfigurasi yang berbeda untuk setiap fork. Misalnya, seseorang dapat mem-build APK Android dengan biner native yang dikompilasi untuk ARM dan x86 menggunakan transisi terpisah dalam satu build.
Lihat juga: Transisi buatan pengguna
Artefak hierarki
Artefak yang mewakili kumpulan file. Karena file ini bukan artefak itu sendiri, tindakan yang beroperasi pada file tersebut harus mendaftarkan artefak hierarki sebagai input atau outputnya.
Visibilitas
Salah satu dari dua mekanisme untuk mencegah dependensi yang tidak diinginkan dalam sistem build:
visibilitas target untuk mengontrol apakah target dapat diandalkan
oleh target lain; dan visibilitas pemuatan untuk mengontrol apakah file BUILD
atau .bzl dapat memuat file .bzl tertentu. Tanpa konteks, biasanya
"visibilitas" mengacu pada visibilitas target.
Lihat juga: Dokumentasi visibilitas
Workspace
Lingkungan yang digunakan bersama oleh semua perintah Bazel dijalankan dari repositori utama yang sama.
Perhatikan bahwa secara historis konsep "repositori" dan "ruang kerja" telah dicampuradukkan; istilah "ruang kerja" sering digunakan untuk merujuk ke repositori utama, dan terkadang bahkan digunakan sebagai sinonim dari "repositori". Penggunaan tersebut harus dihindari agar lebih jelas.