Tüm hedefler tam olarak bir pakete aittir. Bir hedefin adına etiket adı verilir. Her etiket bir hedefi benzersiz bir şekilde tanımlar. Standart biçimdeki tipik bir etiket aşağıdaki gibi görünür:
@myrepo//my/app/main:app_binary
Etiketin ilk bölümü kod deposu adıdır, @myrepo//
.
Bir etiketin, kullanıldığı aynı depoya işaret etmesi durumunda depo tanımlayıcısının adı //
olarak kısaltılabilir.
Dolayısıyla, bu etiket @myrepo
içinde genellikle şu şekilde yazılır:
//my/app/main:app_binary
Etiketin ikinci bölümü, uygun olmayan paket adı my/app/main
, yani depo köküne göre paketin yoludur. Depo adı ve uygun olmayan paket adı birlikte tam nitelikli paket adını @myrepo//my/app/main
oluşturur. Etiket, kullanıldığı pakete atıfta bulunduğunda paket adı (ve isteğe bağlı olarak iki nokta üst üste) atlanabilir. Dolayısıyla, @myrepo//my/app/main
içinde bu etiket aşağıdaki yollardan biriyle yazılabilir:
app_binary
:app_binary
İki nokta üst üste işaretinin dosyalar için atlanması, ancak kurallar için tutulması normaldir ancak diğer açıdan önemli değildir.
Etiketin iki nokta üst üste işaretinden sonraki bölümü olan app_binary
, uygun olmayan hedef addır. Paket yolunun son bileşeniyle eşleştiğinde, ve iki nokta üst üste işareti çıkarılabilir. Dolayısıyla, şu iki etiket eşdeğerdir:
//my/app/lib
//my/app/lib:lib
Paketin alt dizinindeki bir dosya hedefinin adı, dosyanın paket köküyle (BUILD
dosyasını içeren dizin) göreli yoludur. Bu nedenle, bu dosya deponun my/app/main/testdata
alt dizininde yer almaktadır:
//my/app/main:testdata/input.txt
//my/app
ve @some_repo//my/app
gibi dizeler, kullanıldıkları bağlama bağlı olarak iki anlama gelir: Bazel bir etiket beklediğinde sırasıyla //my/app:app
ve @some_repo//my/app:app
anlamına gelir. Ancak, Bazel bir paket beklediğinde (ör. package_group
spesifikasyonlarında) bu etiketi içeren pakete referans verir.
BUILD
dosyalarında yaygın olarak yapılan bir hata, //my/app
işlevinin bir pakete atıfta bulunmak için kullanılması veya bir paketteki hedeflerin tümüne referans vermesidir; bunu yapmaz. //my/app:app
ile eşdeğer olduğunu ve bu nedenle app
hedefini mevcut deponun my/app
paketinde adlandırdığını unutmayın.
Bununla birlikte, paket adının mutlak olduğunu ve çalışma alanının en üst düzey dizininde rootlanmış olduğunu açıkça belirttiğinden, bir pakete atıfta bulunmak için //my/app
kullanılması package_group
spesifikasyonunda veya .bzl
dosyalarında önerilir.
Göreli etiketler diğer paketlerdeki hedeflere başvurmak için kullanılamaz. Bu durumda depo tanımlayıcısı ve paket adı her zaman belirtilmelidir.
Örneğin, kaynak ağaç hem my/app
paketini hem de my/app/testdata
paketini içeriyorsa (bu iki dizinin her birinin kendi BUILD
dosyası vardır) ikinci paket testdepot.zip
adlı bir dosya içerir. Bu dosyaya //my/app:BUILD
içinde referans vermenin iki yolu vardır (bir yanlış, bir doğru):
Yanlış: testdata
farklı bir paket olduğundan göreli bir yol kullanamazsınız
testdata/testdepot.zip
Doğru — Tam yolu ile testdata
sayfasına bakın
//my/app/testdata:testdepot.zip
@//
ile başlayan etiketler, ana depoya yapılan referanslardır ve harici depolarda bile çalışmaya devam eder.
Bu nedenle @//a/b/c
, harici bir depodan referans alındığında //a/b/c
ile farklıdır.
Birincisi ana kod deposunu, ikincisi ise harici deponun kendisinde //a/b/c
arar.
Bu, özellikle ana depodaki hedeflere işaret eden kurallar ana depoya yazılırken geçerlidir ve harici depolardan kullanılır.
Hedeflere başvuruda bulunabileceğiniz farklı yollar hakkında bilgi edinmek için hedef kalıpları konusuna bakın.
Etiketin sözcüksel spesifikasyonu
Etiket söz dizimi, kabuk için özel anlamı olan meta karakterlerin kullanılmasını önler. Bu, yanlışlıkla alıntılama sorunlarının önlenmesine yardımcı olur ve Bazel Sorgu Dili gibi etiketleri değiştiren araçlar ve komut dosyaları oluşturmayı kolaylaştırır.
İzin verilen hedef adlarıyla ilgili kesin ayrıntıları aşağıda bulabilirsiniz.
Hedef adları: package-name:target-name
target-name
, paket içindeki hedefin adıdır. Bir kuralın adı, BUILD
dosyasındaki kuralın bildirimindeki name
özelliğinin değeridir. Dosyanın adı ise BUILD
dosyasını içeren dizine göre yol adıdır.
Hedef adları a
–z
,
A
–Z
, 0
–9
kümesinden alınan karakterler ve !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
noktalama işaretlerinden oluşmalıdır.
Dosya adları normal biçimde göreli yol adları olmalıdır. Yani, eğik çizgiyle başlamamalı veya bitmemelidir (örneğin, /foo
ve foo/
yasaktır) ve yol ayırıcı olarak birden fazla eğik çizgi içermemelidir (ör. foo//bar
). Benzer şekilde, üst düzey referanslar (..
) ve geçerli dizin referansları (./
) da yasaktır.
Yanlış: Diğer paketlerdeki dosyalara atıfta bulunmak için ".." kullanmayın
Doğru — `//package-name:filename` ifadesini kullanın
Dosya hedefi adında /
kullanımı yaygın olsa da kural adlarında /
kullanımından kaçının. Özellikle de bir etiketin kısaltma
biçimi kullanıldığında okuyucunun kafasını karıştırabilir. //foo/bar/wiz
etiketi, foo/bar/wiz
paketi olmasa bile her zaman //foo/bar/wiz:wiz
kelimesinin kısaltmasıdır. Bu hedef mevcut olsa bile hiçbir zaman //foo:bar/wiz
anlamına gelmez.
Bununla birlikte, eğik çizgi kullanmanın kullanışlı veya bazen gerekli olduğu bazı durumlar da vardır. Örneğin, belirli kuralların adı, paketin bir alt dizininde bulunabilecek ana kaynak dosyasıyla eşleşmelidir.
Paket adları: //package-name:target-name
Paket adı, paketin bulunduğu deponun en üst düzey dizinine göre içindeki BUILD
dosyasını içeren dizinin adıdır.
Örneğin: my/app
.
Paket adları tamamen A
-Z
, a
–z
, 0
-9
, "/
", "-
", ".
", "@
" ve "_
" kümesinden alınmış karakterlerden oluşmalı ve eğik çizgiyle başlayamaz.
Modül sistemi için önemli olan dizin yapısına sahip bir dil (ör. Java) söz konusu dilde geçerli tanımlayıcılar olan dizin adlarını seçmek önemlidir.
Bazel, çalışma alanının kök paketindeki hedefleri (örneğin, //:foo
) desteklese de tüm anlamlı paketlerin açıklayıcı adlarının olması için bu paketi boş bırakmak en iyisidir.
Paket adları //
alt dizesini içeremez ve eğik çizgiyle bitemez.
Kurallar
Kural, girdiler ile çıkışlar arasındaki ilişkiyi ve çıktıları oluşturma adımlarını belirtir. Kurallar, Ancyclopedia Derleme bölümünde açıklandığı gibi derlenmiş yürütülebilir dosyalar ve kitaplıklar üreten, yürütülebilir dosyaları ve desteklenen diğer çıkışları test eden çok sayıda farklı türden (bazen kural sınıfı da denir) olabilir.
BUILD
dosyaları, kuralları çağırarak hedefleri bildirir.
Aşağıdaki örnekte, cc_binary
kuralı kullanılarak my_app
hedefinin bildirilmesi gösterilmektedir.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
Her kural çağrısının, BUILD
dosyasının paketi içindeki bir hedefi tanımlayan bir name
özelliği (geçerli bir hedef ad olmalıdır) bulunur.
Her kuralın bir özellik grubu vardır. Belirli bir kural için geçerli özellikler ve her özelliğin önem ve anlamsal bilgisi, kural türünün bir işlevidir. Kural listesi ve bunlara karşılık gelen özellikler için Ansiklopedi Oluşturma bölümüne bakın. Her özelliğin bir adı ve türü vardır. Bir özelliğin sahip olabileceği yaygın türlerden bazıları tam sayı, etiket, etiket listesi, dize, dize listesi, çıkış etiketi ve çıkış etiketleri listesidir. Her kuralda tüm özelliklerin belirtilmesi gerekmez. Böylece özellikler, anahtarlardan (adlardan) isteğe bağlı, yazılan değerlere kadar bir sözlük oluşturur.
Birçok kuralda bulunan srcs
özelliği "etiket listesi" türüne sahiptir. Bu özelliğin değeri (varsa), her biri bu kuralın girdisi olan bir hedefin adı olan bir etiket listesidir.
Bazı durumlarda, kural türünün adı biraz rastgele olur ve kural tarafından oluşturulan dosyaların adları daha ilgi çekicidir. Bu durum, genrules için de geçerlidir. Daha fazla bilgi için Genel Kurallar: genrule bölümüne bakın.
Diğer durumlarda da ad önem taşır: Örneğin, *_binary
ve *_test
kuralları için kural adı, derleme tarafından üretilen yürütülebilir dosyanın adını belirler.
Hedefler üzerinde yönlendirilmiş olan bu döngüsel grafiğe hedef grafik veya bağımlılık grafiği oluştur adı verilir ve Bazel Sorgu aracının üzerinde çalıştığı alan budur.
Hedefler | DERLEME dosyaları |