Bazel, derlemenizde kullanılan ve çalışma alanınızdan gelmeyen harici bağımlılıkları ve kaynak dosyalarını (hem metin hem de ikili program) destekler. Örneğin, GitHub deposunda barındırılan bir kural grubu, Maven yapısı veya mevcut çalışma alanınızın dışındaki yerel makinenizde bulunan bir dizin olabilir.
Bazel 6.0'dan itibaren, Bazel ile harici bağımlılıkları yönetmenin iki yolu vardır: Geleneksel, depoya odaklanan WORKSPACE
sistemi ve daha yeni modüle odaklanan MODULE.bazel
sistemi (Bzlmod kod adındadır ve --enable_bzlmod
işaretiyle etkinleştirilir). Bu iki sistem birlikte kullanılabilir ancak Bzlmod, gelecekteki Bazel sürümlerinde WORKSPACE
sisteminin yerini alacak. Taşıma işlemiyle ilgili Bzlmod taşıma kılavuzunu inceleyin.
Bu belgede Bazel'de dış bağımlılık yönetimini ele alan kavramlar açıklanmıştır. Ayrıca, sırayla iki sistem hakkında daha fazla ayrıntıya girilmelidir.
Kavramlar
Kod deposu
Kökünde sınır işaretçisi dosyası bulunan ve Bazel derlemesinde kullanılabilecek kaynak dosyaları içeren bir dizin ağacı. Genellikle depo olarak kısaltılır.
Depo sınır işaretçisi dosyası MODULE.bazel
(bu reponun bir Bazel modülü temsil ettiğini belirtir), REPO.bazel
(aşağıya bakın) veya eski bağlamlarda WORKSPACE
ya da WORKSPACE.bazel
olabilir. Herhangi bir depo sınır işaretçi dosyası, deponun sınırını belirtir. Bu tür birden fazla dosya bir dizinde bir arada bulunabilir.
Ana depo
Geçerli Bazel komutunun çalıştırıldığı depo.
Ana deponun kökü, çalışma alanı kökü olarak da bilinir.
Çalışma alanı
Tüm Bazel komutlarının paylaştığı ortam aynı ana depoda çalışır. Ana depo ve tanımlanmış tüm harici depoları kapsar.
Geçmişte "depo" ve "çalışma alanı" kavramlarının karıştırıldığını unutmayın. "Çalışma alanı" terimi, genellikle ana depoyu ifade etmek için kullanılmış, hatta bazen "depo"nun eş anlamlısı olarak bile kullanılmıştır.
Standart depo adı
Bir deponun adreslenebilir olduğu kurallı ad. Bir çalışma alanı bağlamında her deponun tek bir standart adı vardır. Bir depo içerisinde standart adı canonical_name
olan bir hedef, @@canonical_name//pac/kage:target
etiketi tarafından ele alınabilir (çift @
değerine dikkat edin).
Ana deponun kanon adı her zaman boş dizedir.
Görünen depo adı
Bir depoya, başka bir depo bağlamında hitap edilebilir.
Bu, deponun "rumuz" olarak düşünülebilir: michael
standart adlı depo,
alice
kod deposu bağlamında mike
görünen adına sahip
olabilir ancak depo bob
bağlamında mickey
olarak görünen ada
sahip olabilir. Bu durumda, michael
içindeki bir hedef, alice
bağlamında @mike//pac/kage:target
etiketiyle adreslenebilir (tek @
'a dikkat edin).
Bu, depo eşlemesi olarak da anlaşılabilir: Her depo, "görünen kod deposu adı"ndan "standart depo adı"na eşleme sağlar.
Depo kuralı
Bazel'a bir depoyu nasıl gerçeğe dönüştüreceğini söyleyen depo tanımları için bir şema. Örneğin, "belirli bir URL'den zip arşivi indirip ayıklayın" veya "belirli bir Maven yapısını getirip java_import
hedefi olarak kullanılabilir hale getirin" ya da "yerel bir dizine simge bağlantısı oluşturun" olabilir. Her depo, uygun sayıda bağımsız değişkene sahip bir depo kuralı çağırarak tanımlanır.
Kendi depo kurallarınızı nasıl yazacağınız hakkında daha fazla bilgi için Depo kuralları bölümüne bakın.
Şu ana kadar en yaygın depo kuralları, URL'den arşiv indiren ve bu arşivin ayıklandığı http_archive
ile zaten Bazel deposu olan yerel bir dizine sembolik bir şekilde bağlantı veren local_repository
'tir.
Kod deposu getir
İlişkili repo kuralını çalıştırarak bir repoyu yerel diskte kullanılabilir hale getirme işlemi. Bir çalışma alanında tanımlanan depolar, getirilmeden önce yerel diskte kullanılamaz.
Bazel, genellikle yalnızca repodan bir şeye ihtiyaç duyduğunda ve repo henüz getirilmediğinde repoyu getirir. Depo daha önce getirilmişse Bazel yalnızca tanımı değiştiyse yeniden getirir.
fetch
komutu, herhangi bir derleme gerçekleştirmek için depo, hedef veya gerekli tüm depolar için önceden getirme işlemini başlatmak amacıyla kullanılabilir. Bu özellik, --nofetch
seçeneğini kullanarak çevrimdışı derlemeleri etkinleştirir.
--fetch
seçeneği, ağ erişimini yönetmede yayınlanır. Varsayılan değeri "doğru"dur.
Ancak yanlış (--nofetch
) olarak ayarlandığında komut, bağımlığın önbelleğe alınmış bir sürümünü kullanır. Önbelleğe alınmış sürüm yoksa komut başarısız olur.
Getirme işlemini kontrol etme hakkında daha fazla bilgi için getirme seçenekleri bölümüne bakın.
Dizin düzeni
Depo, getirildikten sonra çıkış tabanındaki external
alt dizininde, standart adının altında bulunabilir.
canonical_name
kanonik adıyla deponun içeriğini görmek için aşağıdaki komutu çalıştırabilirsiniz:
ls $(bazel info output_base)/external/ canonical_name
REPO.bazel dosyası
REPO.bazel
dosyası, bir depoyu oluşturan dizin ağacının en üst sınırını işaretlemek için kullanılır. Depo sınır dosyası olarak hizmet etmek için herhangi bir şey içermesi gerekmez. Ancak, depodaki tüm derleme hedefleri için bazı ortak özellikleri belirtmek amacıyla da kullanılabilir.
REPO.bazel
dosyalarının söz dizimi, BUILD
dosyalarına benzer. Bununla birlikte, load
ifadeleri desteklenmez ve yalnızca repo()
işlevi kullanılabilir. repo()
, BUILD
dosyalarındaki package()
işleviyle aynı bağımsız değişkenleri alır. package()
ise paket içindeki tüm derleme hedefleri için ortak özellikleri belirtir. repo()
ise benzer şekilde depo içindeki tüm derleme hedefleri için bunu yapar.
Örneğin, aşağıdaki REPO.bazel
dosyasını kullanarak deponuzdaki tüm hedefler için ortak bir lisans belirtebilirsiniz:
repo(
default_package_metadata = ["//:my_license"],
)
Dış bağımlılıkları Bzlmod ile yönetin
Yeni harici bağımlılık alt sistemi Bzlmod, depo tanımlarıyla doğrudan çalışmamaktadır. Bunun yerine modüllerden bir bağımlılık grafiği oluşturur, grafiğin en üstünde uzantıları çalıştırır ve depoları buna göre tanımlar.
Bazel modülü, birden fazla sürümü olabilecek bir Bazel projesidir. Her sürüm, bağımlı olduğu diğer modüller hakkında meta veriler yayınlar. Bir modülün, depo kökünde WORKSPACE
dosyasının yanında bir MODULE.bazel
dosyası olmalıdır. Bu dosya, modülün manifest dosyasıdır ve adını, sürümünü, bağımlılık listesini ve diğer bilgileri bildirir. Aşağıda temel bir örnek verilmiştir:
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
Bir modül yalnızca Bzlmod'un bir Bazel kayıt otoritesinde (varsayılan olarak Bazel Merkez Kayıt otoritesi) aradığı doğrudan bağımlılıklarını listelemelidir. Kayıt defteri, bağımlılıkların MODULE.bazel
dosyalarını sağlar. Bu sayede Bazel, sürüm çözümlemesi yapmadan önce geçişli bağımlılık grafiğinin tamamını keşfedebilir.
Her modül için bir sürümün seçildiği sürüm çözümlemesinden sonra Bazel, her modül için bir deponun nasıl tanımlanacağını öğrenmek üzere kayıt defterine tekrar danışır (çoğu durumda http_archive
kullanılarak).
Modüller, etiketler adı verilen özelleştirilmiş veri parçalarını da belirtebilir. Bu veriler, modül çözümlemesinden sonra ek depolar tanımlamak için modül uzantıları tarafından kullanılır. Bu uzantılar, depo kurallarına benzer özellikler sunarak dosya G/Ç ve ağ istekleri gönderme gibi işlemleri gerçekleştirmelerini sağlar. Diğerlerinin yanı sıra Bazel'in Bazel modüllerinden oluşturulan bağımlılık grafiğine saygı duyarken diğer paket yönetim sistemleriyle etkileşim kurmasına olanak tanır.
Bzlmod'daki harici bağlantılar
- bazelbuild/examples'deki Bzlmod kullanım örnekleri
- Bazel Dış Bağımlılıkları Revizyon (orijinal Bzlmod tasarım dokümanı)
- Bzlmod'da BazelCon 2021 konuşması
- Bzlmod'da Bazel Topluluk Günü konuşması
WORKSPACE
ile depo tanımlayın
Geçmişte, WORKSPACE
(veya WORKSPACE.bazel
) dosyasında depoları tanımlayarak harici bağımlılıkları yönetebiliyordunuz. Bu dosyanın söz dizimi, derleme kuralları yerine depo kuralları kullanan BUILD
dosyalarına benzer.
Aşağıdaki snippet, WORKSPACE
dosyasında http_archive
repo kuralının kullanıldığı bir örnektir:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "foo",
urls = ["https://example.com/foo.zip"],
sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)
Snippet, standart adı foo
olan bir depoyu tanımlıyor. WORKSPACE
sisteminde, varsayılan olarak bir deponun kurallı adı, diğer tüm depolar için görünen adıdır.
WORKSPACE
dosyalarında kullanılabilen işlevlerin tam listesine göz atın.
WORKSPACE
sisteminin eksiklikleri
WORKSPACE
sisteminin kullanıma sunulmasından bu yana geçen yıllarda kullanıcılar aşağıdakiler de dahil olmak üzere birçok sorun yaşadığını bildirdi:
- Bazel, bağımlılıkların
WORKSPACE
dosyalarını değerlendirmez. Bu nedenle, tüm geçişli bağımlılıkların doğrudan bağımlılıklara ek olarak ana deponunWORKSPACE
dosyasında tanımlanması gerekir. - Bu sorunun üstesinden gelmek için projeler "deps.bzl" kalıbını benimsedi. Bu kalıpta, birden fazla depoyu tanımlayan bir makro tanımlanır ve kullanıcılardan bu makroyu
WORKSPACE
dosyalarında çağırmaları istenir.- Bunun da kendine özgü sorunları vardır: Makrolar diğer
.bzl
dosyalarınıload
edemez. Bu nedenle, bu projelerin geçişli bağımlılıklarını bu "deps" makrosunda tanımlaması veya kullanıcının birden fazla katmanlı "deps" makrosu çağırmasını sağlayarak bu sorunu gidermesi gerekir. - Bazel,
WORKSPACE
dosyasını sırayla değerlendirir. Ayrıca, bağımlılıklar herhangi bir sürüm bilgisi olmadan URL'lerle birliktehttp_archive
kullanılarak belirtilir. Bu, elmas bağımlılıkları durumunda sürüm çözümlemesi yapmanın güvenilir bir yolu olmadığı anlamına gelir (A
,B
veC
'a bağlıdır;B
veC
,D
sürümünün farklı sürümlerine bağlıdır).
- Bunun da kendine özgü sorunları vardır: Makrolar diğer
WORKSPACE'in eksiklikleri nedeniyle Bzlmod, gelecekteki Bazel sürümlerinde eski WORKSPACE sisteminin yerini alacak. Bzlmod'a geçiş hakkında lütfen Bzlmod taşıma kılavuzunu okuyun.