Bu sayfada, Bazel'i bildiğinizi varsayılarak Bazel'in özelliklerinden tam olarak yararlanmak için projelerinizi yapılandırmayla ilgili yönergeler ve öneriler sunulmaktadır.
Genel hedefler şunlardır:
- Paralellik ve artımlılığa olanak tanımak için ayrıntılı bağımlılıklar kullanmak.
- Bağımlılıkları iyi bir şekilde kapsamak için.
- Kodu iyi yapılandırılmış ve test edilebilir hale getirmek için.
- Anlaşılması ve sürdürülmesi kolay bir derleme yapılandırması oluşturmak için.
Bu kurallar zorunlu değildir. Çok az proje bu kuralların tümüne uyabilir. lint'in man sayfasında da belirtildiği gibi, "Katı kontrolde hata vermeyen gerçek bir program üreten ilk kişiye özel bir ödül verilecektir." Ancak bu ilkelerden mümkün olduğunca çoğunu daha okunabilir, hataya daha az açık ve daha hızlı üretilebilir hale getirmektir.
Bu sayfada, şurada açıklanan gereksinim düzeyleri kullanılmaktadır: bu RFC'yi inceleyin.
Derleme ve testleri çalıştırma
Bir proje, kararlı dalında bazel build //... ve bazel test //...'i her zaman başarıyla çalıştırabilmelidir. Gerekli hedefler
ancak belirli koşullar altında derleme yapmayın (örneğin,
(belirli bir platformda derlemeyin, lisans sözleşmeleri gerektirir) olmamalıdır.
Mümkün olduğunca özel olarak etiketleyin (örneğin, "requires-osx"). Bu
Etiketleme, hedeflere kıyasla daha hassas bir düzeyde filtrelenmesine olanak sağlar.
"manuel" etiketi ile birlikte BUILD dosyasını inceleyen bir kişinin
kısıtlamalara bağlıdır.
Üçüncü taraf bağımlılıkları
Üçüncü taraf bağımlılıklarını belirtebilirsiniz:
- Bunları
MODULE.bazeldosyasında uzak depo olarak tanımlayın. - İsterseniz bu dosyaları çalışma alanı dizininizin altındaki
third_party/adlı bir dizine de yerleştirebilirsiniz.
İkili programlara bağlı olarak
Mümkün olduğunda her şey kaynaktan derlenmelidir. Bu, genelde
bunun yerine bir kitaplık (some-library.so)
BUILD dosyasını yükleyin ve kaynaklarından some-library.so derleyin ve bu koda
hedefi belirleyebilirsiniz.
Her zaman kaynaktan derleme, bir derlemenin uyumsuz flag'lerle veya farklı bir mimariyle oluşturulmuş. Kapsam, statik analiz veya dinamik analiz gibi yalnızca kaynakta çalışan bazı özellikler de vardır.
Sürüm oluşturma
Mümkün olduğunda tüm kodu başlıktan oluşturmayı tercih edin. Sürümler ne zaman
sürümü hedef ada dahil etmeyin (örneğin, //guava,
//guava-20.0 değil). Bu adlandırma, kitaplığın güncellenmesini kolaylaştırır (yalnızca bir
hedefin güncellenmesi gerekir). Ayrıca elmas bağımlılığı sorunlarına karşı daha dirençlidir: Bir kitaplık guava-19.0'e, diğeri guava-20.0'a bağlıysa iki farklı sürüme bağımlı olmaya çalışan bir kitaplıkla karşılaşabilirsiniz.
Her iki hedefi de bir guava kitaplığına yönlendirmek için yanıltıcı bir takma ad oluşturduysanız BUILD dosyaları yanıltıcıdır.
.bazelrc dosyasını kullanma
Projeye özgü seçenekler için workspace/.bazelrc yapılandırma dosyasını kullanın (bazelrc biçimine bakın).
Projeniz için kaynak denetimine kaydetmek istemediğiniz kullanıcı başına seçenekleri desteklemek istiyorsanız şu satırı ekleyin:
try-import %workspace%/user.bazelrc
(veya başka bir dosya adı) workspace/.bazelrc içinde
ve .gitignore cihazınıza user.bazelrc ekleyin.
Paketler
Derlenebilir dosyalar içeren her dizin bir paket olmalıdır. Bir BUILD dosyası, alt dizinlerdeki dosyaları (srcs = ["a/b/C.java"] gibi) referans alıyorsa bu, söz konusu alt dizin için bir BUILD dosyası eklenmesi gerektiği anlamına gelir. Bu yapı ne kadar uzun süre var olursa yanlışlıkla dairesel bağımlılıkların oluşturulma olasılığı o kadar artar, hedefin kapsamı genişler ve giderek artan sayıda ters bağımlılık güncellenmelidir.