Bu sayfa Bazel hakkında bilgi sahibi olduğunuzu varsayar ve projelerinizi Bazel'in özelliklerinden tam olarak yararlanacak şekilde yapılandırmak için yönergeler ve tavsiyeler sunar.
Genel hedefler şunlardır:
- Paralelliğe ve artımlılığa imkan tanımak amacıyla ayrıntılı bağımlılıkları kullanmak.
- Bağımlılıkları kapsamlı bir şekilde özetlemek.
- Kodu iyi yapılandırılmış ve test edilebilir hale getirmek için.
- Anlaşılması ve bakımı kolay bir derleme yapılandırması oluşturmak için.
Bu yönergeler gerekli değildir: Çok az sayıda proje bunların tamamına uyar. Lint’in kılavuz sayfasında şöyle yazıyor: "Sıkı kontrollerle hiçbir hata üretmeyen gerçek bir program üretmek için ilk kişiye özel bir ödül verilecek." Ancak bu ilkelerden olabildiğince fazlasını dahil ederseniz proje daha okunabilir, hataya daha az açık ve daha hızlı derlenir.
Bu sayfa, bu RFC'de açıklanan gereksinim düzeylerini kullanır.
Derlemeleri ve testleri çalıştırma
Bir proje kararlı şubesinde her zaman bazel build //... ve bazel test //... başarılı şekilde çalıştırabilmelidir. Gerekli olan ancak belirli koşullar altında oluşturulmayan hedefler (ör. belirli derleme işaretleri gerektirme, belirli bir platformda derlememe, lisans sözleşmeleri gerekliliği gibi) mümkün olduğunca ayrıntılı şekilde etiketlenmelidir (ör. "requires-osx"). Bu etiketleme, hedeflerin "manuel" etiketten daha ayrıntılı bir düzeyde filtrelenmesini sağlar ve BUILD dosyasını inceleyen kişinin bir hedefin kısıtlamalarını anlamasına olanak tanır.
Üçüncü taraf bağımlılıkları
Üçüncü taraf bağımlılıklarını bildirebilirsiniz:
WORKSPACEdosyasında bunları uzak depo olarak bildirin.- Alternatif olarak, bu dosyaları çalışma alanı dizininizin altındaki
third_party/adlı bir dizine de yerleştirebilirsiniz.
İkili kodlara bağlı olarak
Mümkün olduğunda her şey kaynaktan derlenmelidir. Genel olarak bu, 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ğlı olmanız anlamına gelir.
Her zaman kaynaktan derleme yapmak, bir derlemenin uyumsuz işaretler veya farklı bir mimariyle oluşturulmuş bir kitaplık kullanmamasını sağlar. Ayrıca, yalnızca kaynak üzerinde çalışan kapsam, statik analiz veya dinamik analiz gibi bazı özellikler de vardır.
Sürüm oluşturma
Mümkün olduğunda tüm kodları başlıktan oluşturmayı tercih edin. Sürümlerin kullanılması gerektiğinde, sürümü hedef ada (örneğin, //guava-20.0 değil) eklemekten kaçının. Bu adlandırma, kitaplığın güncellenmesini kolaylaştırır (yalnızca bir hedefin güncellenmesi gerekir).//guava Ayrıca, elmas bağımlılığı sorunlarına karşı daha dirençlidir: Bir kitaplık guava-19.0, bir kitaplık ise guava-20.0 kullanıyorsa iki farklı sürüme bağlı olmaya çalışan bir kitaplıkla karşılaşabilirsiniz.
Her iki hedefi tek bir guava kitaplığına yönlendirecek 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).
Projeniz için kaynak kontrolünde kontrol etmek 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ını) workspace/.bazelrc ekleyin ve .gitignore öğenize user.bazelrc ekleyin.
Paketler
Oluşturulabilir dosyalar içeren her dizin bir paket olmalıdır. BUILD dosyası, alt dizinlerdeki dosyalara işaret ediyorsa (srcs = ["a/b/C.java"] gibi), bu alt dizine bir BUILD dosyasının eklenmesi gerektiğini gösterir. Bu yapı ne kadar uzun olursa döngüsel bağımlılıklar yanlışlıkla oluşturulur, hedefin kapsamı kayabilir ve artan sayıda ters bağımlılığın güncellenmesi gerekir.