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 izin vermek için ayrıntılı bağımlılıklardan yararlanmak.
- Bağımlılıkları iyi bir şekilde kapsüllemek 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 ilkeleri mümkün olduğunca fazla uygulamak, projenin daha okunaklı, hatalara daha az eğilimli ve daha hızlı oluşturulmasını sağlar.
Bu sayfada, bu RFC'de açıklanan şart düzeyleri kullanılmaktadır.
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 olan ancak belirli koşullar altında derlenmeyen hedefler (ör. belirli derleme işaretleri gerektiren, belirli bir platformda derlenmeyen, lisans sözleşmeleri gerektiren) mümkün olduğunca ayrıntılı bir şekilde etiketlenmelidir (ör. "requires-osx"). Bu etiketleme, hedeflerin "manuel" etiketten daha ayrıntılı bir düzeyde filtrelenmesine olanak tanır ve BUILD dosyasını inceleyen bir kullanıcının hedefin kısıtlamalarını anlamasına olanak tanır.
Üçüncü taraf bağımlılıkları
Üçüncü taraf bağımlılıklarını şu şekilde belirtebilirsiniz:
- Bunları
WORKSPACEdosyasında uzak depo olarak tanımlayın. - Dilerseniz bunları çalışma alanı dizininizdeki
third_party/adlı bir dizine de yerleştirebilirsiniz.
İkili programlara bağlı olarak
Mümkün olduğunda her şey kaynaktan derlenmelidir. Genel olarak bu, bir some-library.so kitaplığına bağlı olmak yerine bir BUILD dosyası oluşturup some-library.so'yi kaynaklarından derleyeceğiniz ve ardından bu hedefe bağlı kalacağınız anlamına gelir.
Her zaman kaynaktan derleme yapmak, 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 kaynakta çalışan bazı özellikler de vardır.
Sürüm oluşturma
Mümkün olduğunda tüm kodu baştan derlemeyi tercih edin. Sürümlerin kullanılması gerektiğinde sürümü hedef adınıza eklemekten kaçının (örneğin, //guava-20.0 yerine //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ığı 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ı) ekleyin ve .gitignore dosyanıza user.bazelrc ekleyin.workspace/.bazelrc
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 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.