Bu sayfada Bazel hakkında bilgi sahibi olduğunuz varsayılır ve projelerinizi Bazel'in özelliklerinden tam olarak yararlanacak şekilde yapılandırmayla ilgili yönergeler ve öneriler sunulur.
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.
- Anlaması ve bakımı kolay bir derleme yapılandırması oluşturmak için.
Bu yönergeler şart değildir: az sayıda proje bu kuralların tamamına uyar. lint'in man sayfasında şöyle demiştir: "Sıkı bir kontrolle hata üretmeyen gerçek bir program üreten ilk kişiye özel bir ödül verilecektir." Ancak bu ilkelerden mümkün olduğunca fazla sayıda uygulama, projeleri daha okunabilir, hataya daha az ve daha hızlı derlenebilir hale getirecektir.
Bu sayfada, bu RFC'de açıklanan gereksinim düzeyleri kullanılmaktadır.
Derleme ve testleri çalıştırma
Bir proje, kararlı dalında her zaman bazel build //... ve bazel test //... işlemlerini başarıyla çalıştırabilmelidir. Gerekli olan ancak belirli koşullar altında oluşturulmayan hedefler (ör. özel derleme işaretleri gerektirme,belirli bir platformda derlememe, lisans sözleşmeleri gerektirme) mümkün olduğunca spesifik bir şekilde etiketlenmelidir (örneğin, "requires-osx"). Bu etiketleme, hedeflerin "manuel" etikete göre daha ayrıntılı bir düzeyde filtrelenmesine olanak tanır ve BUILD dosyasını inceleyen kişinin hedef kısıtlamalarının ne olduğunu anlamasına olanak tanır.
Üçüncü taraf bağımlılıkları
Üçüncü taraf bağımlılıklarını belirtebilirsiniz:
- Bunları
WORKSPACEdosyası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ğu sürece her şeyin kaynaktan derlenmesi gerekir. Genel olarak bu, bir some-library.so kitaplığına bağlı kalmak yerine, bir BUILD dosyası oluşturup bu dosyanın kaynaklarından some-library.so derlemeniz ve ardından bu hedefe bağımlı olmanız gerektiği anlamına gelir.
Her zaman kaynaktan derleme, bir derlemenin uyumsuz işaretlerle veya farklı bir mimariyle oluşturulmuş bir kitaplık kullanmamasını sağlar. Kapsam, statik analiz veya dinamik analiz gibi yalnızca kaynak üzerinde ç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ümlerin kullanılması gerektiğinde hedef ada sürümü dahil etmekten kaçının (örneğin, //guava-20.0 değil, //guava). Bu adlandırma, kitaplığın güncellenmesini kolaylaştırır (yalnızca bir hedefin güncellenmesi gerekir). Ayrıca elmas bağımlılık sorunlarına karşı daha dirençlidir: Bir kitaplık guava-19.0, diğeri guava-20.0 bağımlıysa iki farklı sürüme bağımlı bir kitaplık ortaya çıkabilir.
Her iki hedefi tek bir guava kitaplığına işaret eden yanıltıcı bir takma ad oluşturduysanız BUILD dosyaları yanıltıcıdır.
.bazelrc dosyası kullanılıyor
Projeye özel seçenekler için workspace/.bazelrc yapılandırma dosyasını kullanın (bazelrc biçimine bakın).
Projenizde kaynak kontrolüne kontrol etmek istemediğiniz kullanıcı tabanlı seçenekleri desteklemek istiyorsanız şu satırı ekleyin:
try-import %workspace%/user.bazelrc
(veya başka bir dosya adı) workspace/.bazelrc
ve .gitignore içine user.bazelrc ekleyin.
Paketler
Derlenebilir dosyalar içeren her dizin bir paket olmalıdır. BUILD dosyası alt dizinlerdeki dosyalara (ör. srcs = ["a/b/C.java"]) başvuruyorsa bu, söz konusu alt dizine bir BUILD dosyasının eklenmesi gerektiğinin işaretidir. Bu yapı ne kadar uzun süre kalırsa döngüsel bağımlılıkların yanlışlıkla oluşturulması, hedefin kapsamı kayacak ve giderek artan sayıda ters bağımlılığın güncellenmesi gerekecektir.