Bu sayfada Bazel hakkında bilginiz olduğu varsayılarak yönergeler ve projelerinizi yapılandırma ve Bazel'ın özelliklerinden en iyi şekilde yararlanma konusunda tavsiye almaktı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.
- 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 kurallara uyacaktır hepsinde yardımcı olur. Lint'in man sayfasında şöyle diyor: "Yararlanabileceğiniz oluşturmak için yapay zeka ile hiçbir hata üretmeyen gerçek bir program sıkı bir kontrol gerekiyor." 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 her zaman bazel build //... ve
bazel test //... kararlı dalında başarıyla oluşturuldu. 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ı
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. 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ş. Bir de kapsam, statik analiz veya dinamik analiz gibi yalnızca kaynak üzerinde çalışı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ığına karşı daha dirençlidir.
sorunlar: bir kitaplık guava-19.0 uygulamasına, diğeri de guava-20.0 özelliğine bağımlıysa
iki farklı sürüme bağlı kalmaya çalışan bir kitaplık elde edebilirsiniz.
Her iki hedefi 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ı kullanılıyor
Projeye özel seçenekler için şu yapılandırma dosyasını kullanın:
workspace/.bazelrc (bazelrc biçimine bakın).
Projeniz için desteklemek istemediğiniz kullanıcı başına sunulan seçenekleri desteklemek istiyorsanız kontrol etmek istiyorsanız aşağıdaki 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. BUILD
dosyası, alt dizinlerdeki dosyalara başvurur (srcs = ["a/b/C.java"] gibi).
söz konusu alt dizine bir BUILD dosyasının eklenmesi gerektiğine dair bir işaret. Ne kadar uzun
döngüsel bağımlılıklar da
o kadar büyük ihtimalle
yanlışlıkla oluşturulduğunda hedefin kapsamı daralır ve sayısı arttıkça
güncellenmesi gerekecektir.