Praktik Terbaik

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.
Laporkan masalah Lihat sumber

Halaman ini mengasumsikan bahwa Anda sudah memahami Bazel dan memberikan panduan serta saran untuk menyusun project agar dapat memanfaatkan fitur Bazel sepenuhnya.

Sasaran keseluruhannya adalah:

  • Menggunakan dependensi terperinci untuk memungkinkan paralelisme dan inkrementalitas.
  • Agar dependensi tetap dienkapsulasi dengan baik.
  • Untuk membuat kode terstruktur dengan baik dan dapat diuji.
  • Untuk membuat konfigurasi build yang mudah dipahami dan dikelola.

Pedoman ini bukan persyaratan: beberapa project akan dapat mematuhi semuanya. Seperti yang dijelaskan di halaman manual lint, "Reward khusus akan diberikan kepada orang pertama untuk menghasilkan program nyata yang tidak menyebabkan error dengan pemeriksaan yang ketat." Namun, menggabungkan sebanyak mungkin prinsip ini dapat membuat project lebih mudah dibaca, tidak terlalu rentan mengalami error, dan lebih cepat dibuat.

Halaman ini menggunakan tingkat persyaratan yang dijelaskan dalam RFC ini.

Menjalankan build dan pengujian

Project harus selalu dapat menjalankan bazel build //... dan bazel test //... dengan sukses pada cabang stabilnya. Target yang diperlukan, tetapi tidak di-build dalam situasi tertentu (seperti, memerlukan flag build tertentu, tidak mem-build pada platform tertentu, memerlukan perjanjian lisensi) harus diberi tag sespesifik mungkin (misalnya, "requires-osx"). Pemberian tag ini memungkinkan target difilter pada tingkat yang lebih terperinci daripada tag "manual" dan memungkinkan seseorang memeriksa file BUILD untuk memahami batasan target apa saja yang dimaksud.

Dependensi pihak ketiga

Anda dapat mendeklarasikan dependensi pihak ketiga:

  • Mendeklarasikannya sebagai repositori jarak jauh dalam file WORKSPACE.
  • Atau tempatkan keduanya di direktori yang bernama third_party/ di bawah direktori ruang kerja Anda.

Bergantung pada biner

Segala sesuatu harus dibuat dari sumber jika memungkinkan. Secara umum, ini berarti Anda akan membuat file BUILD dan mem-build some-library.so dari sumbernya, bukan bergantung pada library some-library.so, lalu bergantung pada target tersebut.

Selalu mem-build dari sumber memastikan bahwa build tidak menggunakan library yang dibuat dengan flag yang tidak kompatibel atau arsitektur yang berbeda. Ada juga beberapa fitur seperti cakupan, analisis statis, atau analisis dinamis yang hanya berfungsi pada sumber.

Pembuatan versi

Sebaiknya buat semua kode dari awal jika memungkinkan. Saat versi harus digunakan, jangan sertakan versi dalam nama target (misalnya, //guava, bukan //guava-20.0). Penamaan ini membuat library lebih mudah diperbarui (hanya satu target yang perlu diupdate). Metode ini juga lebih tahan terhadap masalah dependensi diamond: jika satu library bergantung pada guava-19.0 dan yang satu lagi bergantung pada guava-20.0, Anda dapat menemukan library yang mencoba bergantung pada dua versi yang berbeda. Jika Anda membuat alias menyesatkan untuk mengarahkan kedua target ke satu library guava, maka file BUILD akan menyesatkan.

Menggunakan file .bazelrc

Untuk opsi khusus project, gunakan file konfigurasi workspace/.bazelrc (lihat format bazelrc).

Jika ingin mendukung opsi per pengguna untuk project Anda yang tidak ingin diperiksa ke dalam kontrol sumber, sertakan baris berikut:

try-import %workspace%/user.bazelrc

(atau nama file lainnya) di workspace/.bazelrc dan tambahkan user.bazelrc ke .gitignore Anda.

Paket

Setiap direktori yang berisi file yang dapat di-build harus berupa paket. Jika file BUILD merujuk pada file dalam subdirektori (seperti, srcs = ["a/b/C.java"]), itu merupakan tanda bahwa file BUILD harus ditambahkan ke subdirektori tersebut. Semakin lama struktur ini ada, semakin besar kemungkinan dependensi melingkar akan dibuat secara tidak sengaja, cakupan target akan merayap, dan peningkatan jumlah dependensi terbalik harus diperbarui.