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 |