Bu sayfada kod deposu kurallarının nasıl tanımlanacağı açıklanmakta ve inceleyebilirsiniz.
Harici depo, dizin ağacıdır.
tarafından oluşturulan ve Bazel derlemesinde kullanılabilen kaynak dosyaları içeren
ilgili depo kuralını çalıştırın. Depolar birçok farklı şekilde tanımlanabilir.
ancak nihayetinde her depo bir depo kuralının çağrılmasıyla tanımlanır.
derleme hedefleri çağrılarak tanımlanır. Birlikte çalıştığınız
üçüncü taraf kitaplıklar (ör. Maven paketlenmiş kitaplıklar)
Bazel'in çalıştığı ana makineye özel BUILD
dosyaları.
Depo kuralı tanımı
.bzl
dosyasında
repository_rule işlevi
depolayan yeni bir kod deposuna gidin ve bunu bir genel değişkende depolayın. Depo kuralı tanımlandıktan sonra,
depoları tanımlamak için bir işlev olarak çağrılabilir. Bu çağrı genellikle
bir modül uzantısı uygulamasının içinden gerçekleştirilen
işlevini kullanın.
Bir depo kuralı tanımının iki ana bileşeni şudur: özellik şeması ve işlevi görür. Özellik şeması, öğelerin adlarını ve türlerini özellikleri ile birlikte çalışır ve uygulama işlevi çalıştırılmasını sağlayabilirsiniz.
Özellikler
Özellikler, depo kuralı çağrısına iletilen bağımsız değişkenlerdir. Şema
bir depo kuralı tarafından kabul edilen özellikler, şu durumlarda attrs
bağımsız değişkeni kullanılarak belirtilir:
depo kuralı repository_rule
çağrısıyla tanımlanır. Projenin gidişatını
Dize olarak url
ve sha256
özellikleri:
http_archive = repository_rule(
implementation=_impl,
attrs={
"url": attr.string(mandatory=True),
"sha256": attr.string(mandatory=True),
}
)
Uygulama işlevindeki bir özelliğe erişmek için
repository_ctx.attr.<attribute_name>
:
def _impl(repository_ctx):
url = repository_ctx.attr.url
checksum = repository_ctx.attr.sha256
Tüm repository_rule
'ler, dolaylı olarak tanımlanmış name
özelliğine sahiptir. Bu,
sihirli davranan dize özelliği:
bir depo kuralı çağrısı yapıyorsa görünür bir depo adı alır; ancak şuradan okunduğunda:
depo kuralının repository_ctx.attr.name
kullanarak uygulama işlevini döndürürse
standart depo adını kullanıyor.
Uygulama işlevi
Her depo kuralı için implementation
işlevi gerekir. Belge,
yükleme Aşamasında tam olarak yürütülür.
İşlev, repository_ctx
adlı tam bir giriş parametresine sahiptir. İşlev
kuralın tekrarlanabilir olduğunu belirtmek için None
değerini döndürür
veya bu kural için bir dizi parametre içeren bir dikte
kuralı, aynı depoyu oluşturan tekrarlanabilir bir kurala dönüştürür. Örneğin,
Örneğin, Git deposunu izleyen bir kural için
ilk başta bu değerde olan kayan bir dal yerine belirli bir taahhüt tanımlayıcısı
belirtiliyor.
repository_ctx
giriş parametresi şu amaçlar için kullanılabilir:
erişim özellik değerlerine ve hermetik olmayan işlevlere (ikili program,
ikili program yürütme, depoda dosya oluşturma veya dosya indirme
daha fazla içerik sunar. Şu konular için API dokümanlarına bakın:
daha fazla bağlam sunar. Örnek:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
Uygulama işlevi ne zaman yürütülür?
Depo kuralının uygulama işlevi, Bazel tarafından başka bir hedef her zaman başka bir hedef olduğunda depo) buna veya komut satırında belirtip belirtmediğine bağlıdır. İlgili içeriği oluşturmak için kullanılan uygulama işlevinin dosyada depoyu oluşturması beklenir. bahsedeceğim. Buna "getirme" adı verilir buyle ilgili daha fazla bilgi edinin.
Normal hedeflerin aksine depolar, ve deponun farklı olmasına yol açacak birtakım değişiklikler yapabilir. Bu Çünkü Bazel'in değişiklikleri algılayamadığı veya her derleme için çok fazla ek yüke neden olur (örneğin, ağdan). Bu nedenle, depolar yalnızca aşağıdaki şeyler değişir:
- Depo kuralı çağrısına iletilen özellikler.
- Depo kuralının uygulanmasını içeren Starlark kodu.
repository_ctx
öğesine iletilen herhangi bir ortam değişkeninin değerigetenv()
yöntemini kullanarak veyaenviron
repository_rule
. Değerler Bu ortam değişkenlerinin bazıları--repo_env
işareti.read()
,execute()
ve benzeri öğelere iletilen dosyaların içeriği bir etiketle başvuruda bulunulanrepository_ctx
yöntemleri (örneğin,//mypkg:label.txt
ancakmypkg/label.txt
değil)bazel fetch --force
yürütüldüğünde.
Depoların ne zaman ne zaman çalışacağını kontrol eden iki repository_rule
parametresi vardır
geri getirilir:
configure
işareti ayarlanırsa depo yalnızca şurada yeniden getirilir:--configure
parametresi kendisine aktarıldığındabazel fetch
( özelliği ayarlanmazsa bu komut yeniden getirme işlemine neden olmaz)local
işareti ayarlanırsa yukarıdaki durumlara ek olarak depo şu şekilde olur: yeniden getirilir.
Uygulama işlevini yeniden başlatma
Uygulama işlevi, bir kod deposu işlenirken yeniden başlatılabilir istediği bir bağımlılık eksikse getirilir. Böyle bir durumda, uygulama işlevi durur, eksik bağımlılık bu işlev, bağımlılık çözüldükten sonra yeniden yürütülür. Alıcı: gereksiz yeniden başlatmalardan kaçının (ağ erişimi tekrarlanması gerekiyorsa) etiket bağımsız değişkenleri, tüm standart etiket bağımsız değişkenleri mevcut bir dosyaya çözümlenebilir. Sorun çözüldüğünde, yalnızca yürütme sırasında oluşturulan bir dizeden veya etiketten alınan yol işlevin yeniden başlatılması yeniden başlatmaya neden olabilir.
Harici depoları yeniden getirmeyi zorlama
Bazen harici bir depo, şurada herhangi bir değişiklik yapılmadan güncelliğini yitirebilir:
ve bağımlılıklarını
anlamanıza yardımcı olur. Örneğin, bir depo getirme kaynakları
bir üçüncü taraf deposunun belirli bir dalını takip edebilir ve
üzerinden erişilebilir. Bu durumda, bazel'dan tüm
harici depoları koşulsuz olarak bazel fetch --force --all
çağırarak gerçekleştirebilirsiniz.
Ayrıca, bazı depo kuralları yerel makineyi denetler ve
yerel makine yeni sürüme geçirildiyse güncel değildir. Burada Bazel’dan şunları yapmasını isteyebilirsiniz:
depolandığı gibi yalnızca
repository_rule
tanımında configure
özellik ayarlanmış,
bazel fetch --all --configure
.
Örnekler
C++ otomatik yapılandırılmış araç zinciri: otomatik olarak oluşturmak için bir depo kuralı kullanır. Yerel C++ derleyicisi olan Bazel için C++ yapılandırma dosyalarını ortamı ve C++ derleyicisinin desteklediği işaretler.
Go depoları bağımlılık listesini tanımlamak için birkaç
repository_rule
kullanır gereken tüm bilgileri içerir.rules_jvm_external oluşturma varsayılan olarak
@maven
adlı ve derleme hedefleri oluşturan harici bir depo geçişli bağımlılık ağacındaki her Maven yapısı için geçerlidir.