Bir hedef A
, derleme veya yürütme sırasında A
tarafından B
'e ihtiyaç duyuluyorsa B
'e bağlıdır. Bağlı ilişkisi, hedefler üzerinde bir yönlü düz ağaç (DAG) oluşturur ve bu ağaca bağlılık grafiği denir.
Bir hedefin doğrudan bağımlılıkları, bağımlılıklar grafiğinde 1 uzunluğunda bir yola ulaşılarak erişilebilen diğer hedeflerdir. Bir hedefin geçişli bağımlılıkları, grafiğin herhangi bir uzunluğundaki bir yol üzerinden bağlı olduğu hedeflerdir.
Aslında derleme bağlamında iki bağımlılığı grafik vardır: Gerçek bağımlılıkların grafiği ve beyan edilen bağımlılıkların grafiği. Çoğu zaman bu iki grafik o kadar benzerdir ki bu ayrımı yapmanın bir anlamı yoktur ancak aşağıdaki tartışma için bu ayrım faydalıdır.
Gerçek ve beyan edilen bağımlılar
X
hedefinin doğru şekilde oluşturulabilmesi için Y
hedefinin mevcut, oluşturulmuş ve güncel olması gerekiyorsa X
hedefi Y
hedefine gerçekten bağlıdır. Derlendi ifadesi, oluşturuldu, işlendi, derlendi, bağlandı, arşivlendi, sıkıştırıldı, yürütüldü veya derleme sırasında rutin olarak gerçekleşen diğer görev türlerinden herhangi birini ifade edebilir.
X
paketinde X
ile Y
arasında bir bağımlılık kenarı varsa X
hedefi, Y
hedefi için belirlenmiş bir bağımlılığa sahiptir.
Doğru derlemeler için gerçek bağımlılıkların grafiği A, beyan edilen bağımlılıkların grafiğinin D bir alt grafiği olmalıdır. Yani A'da doğrudan bağlı x --> y
düğümlerinin her bir çifti de D'de doğrudan bağlı olmalıdır. D'nin A'nın aşırı yakınsaması olduğu söylenebilir.
BUILD
dosya yazarları, her kural için derleme sistemine uygulanan doğrudan bağımlılıkların tümünü açıkça beyan etmeli ve bundan sonrasını yapmamalıdır.
Bu ilkeye uyulmaması, tanımlanmamış davranışa neden olur: Derleme başarısız olabilir ancak daha da kötüsü, derleme bazı önceki işlemlere veya hedefin sahip olduğu geçişli olarak tanımlanmış bağımlılıklara bağlı olabilir. Bazel eksik bağımlılıkları kontrol eder ve hataları bildirir, ancak bu kontrolün her durumda tamamlanması mümkün değildir.
Yürütme sırasında A
tarafından ihtiyaç duyulsa bile dolaylı olarak içe aktarılan her şeyi listelemeniz gerekmez (ve listelemeniz de gerekmez).
X
hedefinin derlenmesi sırasında derleme aracı, bu hedeflerdeki değişikliklerin nihai sonuca yansıtıldığından emin olmak için X
'nin bağımlılıkların geçişli kapatılmasının tamamını inceler ve gerektiğinde ara öğeleri yeniden oluşturur.
Bağımlılıkların geçişli yapısı, yaygın bir hataya yol açar. Bazen bir dosyadaki kod, dolaylı bir bağımlılık tarafından sağlanan kodu kullanabilir. Bu dolaylı, bildirilen bağımlılık grafiğinde geçişli ama doğrudan olmayan bir bağımlılıktır. Dolaylı bağımlılar BUILD
dosyasında görünmez. Kural doğrudan sağlayıcıya bağlı olmadığından aşağıdaki örnek zaman çizelgesinde gösterildiği gibi değişiklikleri izlemek mümkün değildir:
1. Beyan edilen bağımlılıklar gerçek bağımlılıklarla eşleşiyor
Başlangıçta her şey yolunda gider. a
paketindeki kod, b
paketindeki kodu kullanıyor.
b
paketindeki kod, c
paketindeki kodu kullandığından a
, c
'e dolaylı olarak bağlıdır.
a/BUILD |
b/BUILD |
---|---|
rule( name = "a", srcs = "a.in", deps = "//b:b", ) |
rule( name = "b", srcs = "b.in", deps = "//c:c", ) |
a / a.in |
b / b.in |
import b; b.foo(); |
import c; function foo() { c.bar(); } |
Beyan edilen bağımlılıklar, gerçek bağımlılıkları fazla tahmin ediyor. Her şey yolunda.
2. Bildirilmemiş bir bağımlılık ekleme
Bir kullanıcı a
dosyasına c
'a doğrudan gerçek bağımlılık oluşturan kod eklediğinde ancak bunu a/BUILD
derleme dosyasında belirtmeyi unuttuğunuzda gizli bir tehlike ortaya çıkar.
a / a.in |
|
---|---|
import b; import c; b.foo(); c.garply(); |
|
Beyan edilen bağımlılıklar, artık gerçek bağımlılıklara fazla değer vermiyor.
İki grafiğin geçişli kapatmaları eşit olduğu için bu derleme işlemi sorunsuz olabilir ancak bir sorunu maskeler: a
, c
'a karşı gerçek ancak bildirilmemiş bir bağımlılığa sahiptir.
3. Beyan edilen ve gerçek bağımlılık grafikleri arasındaki farklılık
Bir kullanıcı b
'ü artık c
'e bağlı olmayacak şekilde yeniden yapılandırdığında ve kendi hatası olmadan a
'yi yanlışlıkla bozduğunda tehlike ortaya çıkar.
b/BUILD |
|
---|---|
rule( name = "b", srcs = "b.in", deps = "//d:d", ) |
|
b / b.in |
|
import d; function foo() { d.baz(); } |
|
Bildirilen bağımlılık grafiği, artık geçişli olarak kapatılsa bile gerçek bağımlılıkların düşük bir tahmini olarak sunulmaktadır. Derleme büyük olasılıkla başarısız olacaktır.
Sorun, 2. adımda tanıtılan a
ile c
arasındaki gerçek bağımlığın BUILD
dosyasında doğru şekilde tanımlanmasıyla önlenebilirdi.
Bağımlılık türleri
Çoğu derleme kuralında, farklı türde genel bağımlılıkları belirtmek için üç özellik bulunur: srcs
, deps
ve data
. Bunlar aşağıda açıklanmıştır. Daha fazla bilgi için Tüm kurallarda ortak olan özellikler bölümüne bakın.
Birçok kuralda, kurala özgü bağımlılık türleri için ek özellikler de bulunur (ör. compiler
veya resources
). Bu bilgiler Build Encyclopedia'da ayrıntılı olarak açıklanmıştır.
srcs
bağımlılıkları
Doğrudan kaynak dosyaları oluşturan kural veya kurallar tarafından kullanılan dosyalar.
deps
bağımlılıkları
Başlık dosyaları, simgeler, kitaplıklar, veriler vb. sağlayan ayrı olarak derlenmiş modülleri işaret eden kural.
data
bağımlılık
Bir derleme hedefinin doğru şekilde çalışabilmesi için bazı veri dosyalarına ihtiyacı olabilir. Bu veri dosyaları kaynak kod değildir: Hedefin nasıl oluşturulduğunu etkilemez. Örneğin, bir birim testi bir işlevin çıkışını bir dosyanın içeriğiyle karşılaştırabilir. Birim testini oluştururken dosyaya ihtiyacınız yoktur ancak testi çalıştırırken dosyaya ihtiyacınız vardır. Aynı durum, yürütme sırasında başlatılan araçlar için de geçerlidir.
Derleme sistemi, yalnızca data
olarak listelenen dosyaların bulunduğu izole bir dizinde testler çalıştırır. Bu nedenle, bir ikili programın/kitaplık/testin çalışması için bazı dosyalar gerekiyorsa bunları (veya bunları içeren bir derleme kuralını) data
içinde belirtin. Örneğin:
# I need a config file from a directory named env:
java_binary(
name = "setenv",
...
data = [":env/default_env.txt"],
)
# I need test data from another directory
sh_test(
name = "regtest",
srcs = ["regtest.sh"],
data = [
"//data:file1.txt",
"//data:file2.txt",
...
],
)
Bu dosyalar, path/to/data/file
göreli yolu kullanılarak kullanılabilir. Testlerde, testin kaynak dizininin yollarını ve Workspace'e göreli yolu (ör. ${TEST_SRCDIR}/workspace/path/to/data/file
) birleştirerek bu dosyalara referans verebilirsiniz.
Dizinlere referans vermek için etiketleri kullanma
BUILD
dosyalarımıza göz atarken bazı data
etiketlerinin dizinlere işaret ettiğini fark edebilirsiniz. Aşağıdaki örneklerde gösterildiği gibi, bu etiketler /.
veya /
ile biter. Bu etiketleri kullanmamanız önerilir:
Önerilmeyen —
data = ["//data/regression:unittest/."]
Önerilmeyen:
data = ["testdata/."]
Önerilmeyen:
data = ["testdata/"]
Bu, özellikle testler için kullanışlıdır çünkü bir testin dizindeki tüm veri dosyalarını kullanmasına olanak tanır.
Ancak bunu yapmamaya çalışın. Bir değişiklikten sonra artımlı yeniden derlemelerin doğru şekilde yapılmasını (ve testlerin yeniden yürütülmesini) sağlamak için derleme sisteminin, derlemeye (veya teste) giriş olan tüm dosya grubundan haberdar olması gerekir. Bir dizin belirttiğinizde, derleme sistemi yalnızca dizinin kendisi değiştiğinde (dosya ekleme veya silme nedeniyle) yeniden oluşturma işlemi gerçekleştirir, ancak bu değişiklikler ilgili dizini etkilemediğinden, tek tek dosyalarda yapılan düzenlemeleri algılayamaz.
Derleme sistemine giriş olarak dizinleri belirtmek yerine, bu dizinlerde bulunan dosya grubunu açıkça veya glob()
işlevini kullanarak listelemeniz gerekir. (glob()
öğesini yinelemeli olmaya zorlamak için **
öğesini kullanın.)
Önerilen:
data = glob(["testdata/**"])
Maalesef dizin etiketlerinin kullanılması gereken bazı senaryolar vardır.
Örneğin, testdata
dizini adları etiket söz dizimine uygun olmayan dosyalar içeriyorsa dosyaların açıkça numaralandırılması veya glob()
işlevinin kullanılması geçersiz etiket hatası oluşturur. Bu durumda dizin etiketlerini kullanmanız gerekir ancak yukarıda açıklanan yanlış yeniden oluşturma riskine dikkat edin.
Dizin etiketleri kullanmanız gerekiyorsa üst pakete göreli ../
yolu ile atıfta bulunamayacağınızı unutmayın. Bunun yerine //data/regression:unittest/.
gibi mutlak bir yol kullanın.
Birden fazla dosyayı kullanması gereken harici kurallar (ör. testler) tüm dosyalara olan bağımlılığını açıkça belirtmelidir. Dosyaları BUILD
dosyasında gruplandırmak için filegroup()
kullanabilirsiniz:
filegroup(
name = 'my_data',
srcs = glob(['my_unittest_data/*'])
)
Daha sonra, testinizde veri bağımlılığı olarak my_data
etiketine referans verebilirsiniz.
BUILD dosyaları | Görünürlük |