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ı |