Tüm hedefler tam olarak bir pakete aittir. Bir hedefin adına etiket adı verilir. Her etiket bir hedefi benzersiz ş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ü, @myrepo//
kod deposudur.
Genellikle bir etiketin, kullanıldığı depoya referans verdiği durumlarda depo tanımlayıcısı //
olarak kısaltılabilir.
Dolayısıyla, @myrepo
içinde bu etiket genellikle
//my/app/main:app_binary
Etiketin ikinci bölümü, uygun olmayan paket adı olan my/app/main
olur. Bu ad, 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ığı aynı 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 şekillerde yazılabilir:
app_binary
:app_binary
Genel bir kural olarak, iki nokta üst üste dosyalar için çıkarılır, ancak kurallar için tutulur, ancak başka şekilde önemli değildir.
Etiketin iki nokta üst üste işaretinden sonraki kısmı (app_binary
), uygun olmayan hedef adıdır. Paket yolunun son bileşeniyle eşleştiğinde bu bileşen ve iki nokta atlanabilir. Dolayısıyla, şu iki etiket eşdeğerdir:
//my/app/lib
//my/app/lib:lib
Paketin bir alt dizinindeki dosya hedefinin adı, dosyanın paket köküne (BUILD
dosyasını içeren dizin) göre izlediği yoldur. Yani bu dosya, deponun my/app/main/testdata
alt dizinindedir:
//my/app/main:testdata/input.txt
//my/app
ve @some_repo//my/app
gibi dizelerin, kullanıldıkları bağlama bağlı olarak iki anlamı vardır: Bazel bir etiket beklediğinde, bunların 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 sık yapılan bir hata, bir pakete başvurmak için //my/app
kullanılması veya bir paketteki tüm hedeflerin kullanılmasıdır. Aksi takdirde. //my/app:app
ile eşdeğer olduğunu unutmayın. Bu nedenle, app
hedefini geçerli deponun my/app
paketinde adlandırır.
Bununla birlikte, paket adının mutlak olduğunu ve çalışma alanının üst düzey dizinine dayalı olduğunu açıkça belirttiğinden, bir pakete atıfta bulunmak için //my/app
kullanımı package_group
veya .bzl
dosyalarda belirtilmesinde teşvik edilir.
Göreli etiketler, diğer paketlerdeki hedeflere başvuruda bulunmak 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 dizinden her birinin kendi BUILD
dosyası vardır) sonraki paket, testdepot.zip
adlı bir dosya içerir. //my/app:BUILD
içinde bu dosyaya atıfta bulunmanın iki yolu vardır (biri yanlış, biri doğru):
Yanlış: testdata
farklı bir paket olduğundan göreli yol kullanamazsınız
testdata/testdepot.zip
Doğru: Tam yoluyla testdata
için bakın
//my/app/testdata:testdepot.zip
@//
ile başlayan etiketler, harici depolarda bile çalışmaya devam edecek olan ana depoya referanslardır.
Bu nedenle @//a/b/c
, harici bir depodan referans verildiğinde //a/b/c
ürününden farklıdır.
Birincisi, ana depoyu ifade ederken ikinci depo ise harici deponun kendisinde //a/b/c
değerini arar.
Bu, özellikle ana depoda, ana depodaki hedeflere işaret eden ve harici depolardan kullanılacak kurallar yazarken geçerlidir.
Hedeflere atıfta bulunmanın farklı yolları hakkında bilgi için hedef kalıpları bölümüne bakın.
Etiketin sözcüksel spesifikasyonu
Etiket söz dizimi, kabuk için özel anlamı olan meta karakterlerin kullanımını engeller. Bu, yanlışlıkla alıntılama sorunlarının önlenmesine yardımcı olur ve Bazel Sorgu Dili gibi etiketleri manipüle eden araçlar ve komut dosyaları oluşturmayı kolaylaştırır.
İzin verilen hedef adlarının tam ayrıntıları aşağıda verilmiştir.
Hedef adlar — package-name:target-name
target-name
, paketteki hedefin adıdır. Bir kuralın adı, BUILD
dosyasındaki kuralın bildirimindeki name
özelliğinin değeridir. Bir dosyanın adı, BUILD
dosyasını içeren dizine göre yol adıdır.
Hedef adlar tamamen a
-z
,
A
-Z
, 0
-9
kümeleri ve !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
noktalama işaretlerinden oluşturulmuş karakterlerden oluşmalıdır.
Dosya adları normal biçimdeki göreli yol adları olmalıdır. Yani, eğik çizgiyle başlamamalı veya bitmemelidir (örneğin, /foo
ve foo/
yasaktır) ya da yol ayırıcı olarak birden fazla eğik çizgi içermemelidir (örneğin, foo//bar
). Benzer şekilde, üst düzey referanslar (..
) ve geçerli dizin referansları (./
) da yasaktır.
Yanlış: Diğer paketlerdeki dosyalara referans vermek 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 bir etiketin kısaltılmış biçimi kullanıldığında, okuyucunun kafası karışabilir. //foo/bar/wiz
etiketi, foo/bar/wiz
paketi olmasa bile her zaman //foo/bar/wiz:wiz
için kullanılan bir kısaltmadır. Bu hedef mevcut olsa bile hiçbir zaman //foo:bar/wiz
anlamına gelmez.
Bununla birlikte, eğik çizgi kullanmanın uygun veya bazen gerekli olduğu bazı durumlar vardır. Örneğin, belirli kuralların adları, paketin alt dizininde bulunabilecek ana kaynak dosyasıyla eşleşmelidir.
Paket adları — //package-name:target-name
Paketin adı, içeren deponun en üst düzey dizinine göre BUILD
dosyasını içeren dizinin adıdır.
Örnek: my/app
.
Paket adları tamamen A
-Z
, a
-z
, 0
-9
, "/
", "-
", ".
", "@
" ve "_
" kümelerinden alınmış karakterlerden oluşmalı ve eğik çizgiyle başlamamalıdır.
Modül sistemi açısından önemli olan bir dizin yapısına sahip bir dil (ör. Java) için, dilde geçerli tanımlayıcılar olan dizin adlarını seçmeniz önemlidir.
Bazel, çalışma alanının kök paketindeki hedefleri (örneğin, //:foo
) desteklese de tüm anlamlı paketlerin açıklayıcı adlara sahip olması için bu paketi boş bırakmak en iyisidir.
Paket adları //
alt dizesini içeremez veya eğik çizgiyle bitemez.
Kurallar
Kurallar, girişler ile çıkışlar arasındaki ilişkiyi ve çıktıları oluşturma adımlarını belirtir. Kurallar, derlenen yürütülebilir dosyalar ve kitaplıklar, yürütülebilir dosyaları test eden ve Ansiklopedi Geliştirme bölümünde açıklandığı üzere desteklenen diğer çıkışlar üreten birçok farklı türden (bazen kural sınıfı olarak da adlandırılır) olabilir.
BUILD
dosyaları, kuralları çağırarak hedefleri bildirir.
Aşağıdaki örnekte, cc_binary
kuralı kullanılarak my_app
hedefinin beyanını görüyoruz.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
Her kural çağrısının, BUILD
dosyası paketi içinde bir hedef tanımlayan bir name
özelliği vardır (geçerli bir hedef adı olmalıdır).
Her kuralın bir dizi özellikleri vardır. Belirli bir kural için geçerli özellikler ile her özelliğin önemi ve anlamı, kuralın türüne ait bir işlevdir. Kurallar ve bunlara karşılık gelen özelliklerin listesi 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ış etiketi listesi olabilir. 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ündedir. Varsa değeri, her biri bu kurala giriş olan bir hedefin adını ifade eden bir etiketler listesidir.
Bazı durumlarda, kural türünün adı biraz tesadüfi olabilir. Kural tarafından oluşturulan dosyaların adları daha ilgi çekicidir. Bu, genrule'lar için de geçerlidir. Daha fazla bilgi için Genel Kurallar: genrule bölümünü inceleyin.
Diğer durumlarda ad önemlidir: Örneğin, *_binary
ve *_test
kuralları için kural adı, derleme tarafından oluşturulan yürütülebilir dosyanın adını belirler.
Hedeflerin üzerindeki bu yönlendirilmiş grafik, hedef grafik veya bağımlılık grafiği oluşturma olarak adlandırılır ve Bazel Sorgu aracının üzerinde çalıştığı alandır.
Hedefler | Dosya derleyin |