Laman ini mengasumsikan Anda sudah mengenal Bazel dan memberikan pedoman serta saran tentang menyusun proyek Anda untuk memanfaatkan sepenuhnya fitur Bazel.
Tujuan keseluruhan adalah:
- Untuk menggunakan dependensi terperinci guna memungkinkan paralelisme dan inkrementalitas.
- Untuk menjaga dependensi agar tetap dienkapsulasi dengan baik.
- Untuk membuat kode terstruktur dengan baik dan dapat diuji.
- Untuk membuat konfigurasi build yang mudah dipahami dan dikelola.
Pedoman ini bukanlah persyaratan: hanya sedikit proyek yang dapat mematuhi semuanya. Seperti yang tertulis di halaman man untuk lint, "Hadiah khusus akan diberikan kepada orang pertama yang membuat program nyata yang tidak menghasilkan error dengan pemeriksaan ketat". Namun, menggabungkan sebanyak mungkin prinsip-prinsip ini harus membuat proyek lebih mudah dibaca, tidak rentan terhadap kesalahan, dan lebih cepat dibangun.
Halaman ini menggunakan tingkat persyaratan yang dijelaskan di RFC ini.
Menjalankan build dan pengujian
Sebuah project harus selalu dapat menjalankan bazel build //...
dan
bazel test //...
berhasil di cabang stabilnya. Target yang diperlukan
tetapi tidak di-build dalam situasi tertentu (seperti, memerlukan flag build
tertentu, tidak di-build di platform tertentu, memerlukan perjanjian lisensi) harus
diberi tag sekhusus mungkin (misalnya, "requires-osx
"). Pemberian tag
ini memungkinkan target difilter pada tingkat yang lebih terperinci daripada
tag "manual" dan memungkinkan seseorang yang memeriksa file BUILD
untuk memahami
batasan target.
Dependensi pihak ketiga
Anda dapat mendeklarasikan dependensi pihak ketiga:
- Deklarasikan sebagai repositori jarak jauh dalam file
MODULE.bazel
. - Atau, letakkan dalam direktori bernama
third_party/
di bawah direktori ruang kerja Anda.
Bergantung pada biner
Semuanya harus dibuat dari sumber jika memungkinkan. Umumnya hal ini berarti
sehingga, alih-alih bergantung pada library some-library.so
, Anda akan membuat
BUILD
dan buat some-library.so
dari sumbernya, lalu bergantung pada resource tersebut
target.
Selalu mem-build dari sumber memastikan bahwa build tidak menggunakan library yang di-build dengan flag yang tidak kompatibel atau arsitektur yang berbeda. Ada juga beberapa fitur seperti cakupan, analisis statis, atau analisis dinamis yang hanya berfungsi di sumber.
Pembuatan Versi
Memilih membuat semua kode dari head jika memungkinkan. Kapan versi harus
digunakan, hindari menyertakan versi dalam nama target (misalnya //guava
,
bukan //guava-20.0
). Penamaan ini membuat library lebih mudah diperbarui (hanya satu
target perlu diperbarui). Desain ini juga lebih tahan terhadap
dependensi berlian
masalah: jika satu library bergantung pada guava-19.0
dan library lain bergantung pada guava-20.0
,
Anda mungkin menemui sebuah {i>library<i} yang
mencoba bergantung pada dua versi yang berbeda.
Jika Anda membuat alias yang menyesatkan untuk mengarahkan kedua target ke satu library guava
,
maka file BUILD
tersebut menyesatkan.
Menggunakan file .bazelrc
Untuk opsi khusus proyek, gunakan file konfigurasi yang
workspace/.bazelrc
(lihat format bazelrc).
Jika Anda ingin mendukung opsi per pengguna untuk project yang tidak yang ingin Anda periksa ke kontrol sumber, sertakan baris:
try-import %workspace%/user.bazelrc
(atau nama file lainnya) di workspace/.bazelrc
Anda
dan tambahkan user.bazelrc
ke .gitignore
Anda.
Paket
Setiap direktori yang berisi file yang dapat dibangun harus berupa paket. Jika file BUILD
merujuk ke file dalam subdirektori (seperti, srcs = ["a/b/C.java"]
), ini
adalah tanda bahwa file BUILD
harus ditambahkan ke subdirektori tersebut. Makin lama
struktur ini ada, makin besar kemungkinan dependensi melingkar akan
dibuat secara tidak sengaja, cakupan target akan meluas, dan makin banyak
dependensi terbalik yang harus diperbarui.