Bu sayfada, Bazel'i bildiğiniz varsayılmakta ve projelerinizi Bazel'in özelliklerinden tam olarak yararlanacak şekilde yapılandırma konusunda yönergeler ve tavsiyeler verilmektedir.
Genel hedefler şunlardır:
- Paralelliğe ve artımlılığa izin vermek için ayrıntılı bağımlılıkları kullanmak.
- Bağımlılıkları iyi bir şekilde kapsamak için.
- Kodun iyi yapılandırılmış ve test edilebilir olması için.
- Anlaşılması ve bakımı kolay bir derleme yapılandırması oluşturmak için.
Bu yönergeler zorunlu değildir. Çok az proje bu yönergelerin tamamına uyabilir. Lint'in kılavuz sayfasında belirtildiği gibi, "Sıkı kontrolle hata üretmeyen gerçek bir programı ilk oluşturan kişiye özel bir ödül verilir." Ancak bu ilkelerin mümkün olduğunca fazlasını dahil etmek projeyi daha okunabilir, daha az hataya açık ve daha hızlı oluşturulabilir hale getirmelidir.
Bu sayfada, bu RFC'de açıklanan şart düzeyleri kullanılmaktadır.
Derleme ve testleri çalıştırma
Bir proje, kararlı dalında her zaman bazel build //... ve bazel test //... başarılı bir şekilde çalıştırılabilmelidir. Gerekli olan ancak belirli durumlarda (ör. belirli derleme işaretleri gerektiren, belirli bir platformda derlenmeyen, lisans sözleşmeleri gerektiren) oluşturulmayan hedefler mümkün olduğunca spesifik olarak 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 yardımcı olur.
Üçüncü taraf bağımlılıkları
Üçüncü taraf bağımlılıklarını beyan edebilirsiniz:
- Bunları
MODULE.bazeldosyasında uzak depolar olarak bildirin. - Alternatif olarak, bunları çalışma alanı dizininizin altında
third_party/adlı bir dizine de yerleştirebilirsiniz.
İkili programlara bağlı
Mümkün olduğunda her şey kaynaktan derlenmelidir. Genel olarak bu, bir kitaplığa some-library.so bağlı kalmak yerine bir BUILD dosyası oluşturup some-library.so dosyasını kaynaklarından oluşturacağınız ve ardından bu hedefe bağlı kalacağınız anlamına gelir.
Her zaman kaynaktan derleme, derlemenin uyumsuz işaretlerle veya farklı bir mimariyle oluşturulmuş bir kitaplığı kullanmamasını sağlar. Ayrıca, yalnızca kaynakta çalışan kapsam, statik analiz veya dinamik analiz gibi bazı özellikler de vardır.
Sürüm oluşturma
Mümkün olduğunca tüm kodu baştan oluşturmayı tercih edin. Sürümlerin kullanılması gerektiğinde sürümü hedef adına eklemeyin (ö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 dayanıklıdır: Bir kitaplık guava-19.0'ya, diğeri ise guava-20.0'ya bağlıysa iki farklı sürüme bağlı olmaya çalışan bir kitaplıkla karşılaşabilirsiniz.
Her iki hedefi de tek 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 özel seçenekler için workspace/.bazelrc yapılandırma dosyanızı kullanın (bkz. bazelrc biçimi).
Projenizde, kaynak kontrolüne eklemek 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 dosyanızda ve .gitignore dosyanıza user.bazelrc ekleyin.
Açık kaynaklı bazelrc-preset.bzl {: .external} Bazel sürümünüzle eşleşen özel bir bazelrc dosyası oluşturur ve önerilen işaretlerin önceden ayarlanmış bir sürümünü sağlar.
Paketler
Derlenebilir dosyalar içeren her dizin bir paket olmalıdır. Bir BUILD dosyasının alt dizinlerdeki dosyalara (ör. srcs = ["a/b/C.java"]) referans vermesi, söz konusu alt dizine bir BUILD dosyası eklenmesi gerektiğinin işaretidir. Bu yapı ne kadar uzun süre var olursa döngüsel bağımlılıkların yanlışlıkla oluşturulma, bir hedefin kapsamının genişleme ve artan sayıda ters bağımlılığın güncellenme olasılığı o kadar yüksek olur.