Tüm hedefler tam olarak bir pakete aittir. Hedef adı etiketini adlandırdı. Her etiket bir hedefi benzersiz şekilde tanımlar. Standart biçimdeki tipik bir etiket şöyle görünür:
@myrepo//my/app/main:app_binary
Etiketin ilk kısmı, @myrepo// kod deposu adıdır.
Tipik bir durumda, bir etiket aynı depoya başvuruda bulunurken
depo tanımlayıcısı // olarak kısaltılabilir.
Bu nedenle, @myrepo içinde bu etiket genellikle şu şekilde yazılır:
//my/app/main:app_binary
Etiketin ikinci kısmı, paketin depo köküne göre yolu olan niteliksiz paket adıdırmy/app/main. Depo adı ve niteliksiz paket adı birlikte tam nitelikli paket adını@myrepo//my/app/main oluşturur. Etiket, kullanıldığı paketi ifade ettiğinde paket adı (ve isteğe bağlı olarak iki nokta üst üste) atlanabilir. Bu nedenle, @myrepo//my/app/main içinde bu etiket aşağıdaki yöntemlerden biriyle yazılabilir:
app_binary
:app_binary
Genel olarak, iki nokta üst üste işareti dosyalarda çıkarılır. ancak kurallar için saklanır ancak başka şekilde önemli değildir.
Etiketin iki nokta üst üste işaretinden sonraki bölümü (app_binary), uygun olmayan hedeftir
dokunun. Paket yolunun son bileşeniyle eşleştiğinde ve
iki nokta üst üste işareti koyulabilir. 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 yoludur
kök dizin (BUILD dosyasını içeren dizin) ile ilişkilidir. Bu dosya, deponunun my/app/main/testdata alt dizinindedir:
//my/app/main:testdata/input.txt
//my/app ve @some_repo//my/app gibi dizelerin anlamları, kullanıldıkları bağlama göre değişir: Bazel bir etiket beklediğinde bu dizelerin anlamı sırasıyla //my/app:app ve @some_repo//my/app:app olur. Ancak, Bazel
bir paket beklediğinde (ör. package_group spesifikasyonlarında)
paketinin içeriğini ele alalım.
BUILD dosyalarında yaygın olarak yapılan bir hata, bir pakete veya paketteki tüm hedeflere atıfta bulunmak için //my/app kullanılmasıdır. Unutmayın,
//my/app:app ile eşdeğerdir; dolayısıyla, app hedefini my/app
paketinin tüm özellikleri dahil edilir.
Ancak, paket adının mutlak olduğunu ve çalışma alanının üst düzey dizininde köklendiğini açıkça belirttiği için package_group veya .bzl dosyalarında bir pakete atıfta bulunmak için //my/app kullanılması önerilir.
Göreli etiketler, diğer paketlerdeki hedeflere başvuruda bulunmak için kullanılamaz; "the"
depo tanımlayıcısı ve paket adı bu durumda her zaman belirtilmelidir.
Örneğin, kaynak ağacı 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. Burası
iki farklı şekilde (biri yanlış, biri doğru)
//my/app:BUILD:
Yanlış: testdata farklı bir paket olduğundan göreli yol kullanamazsınız.
testdata/testdepot.zip
Doğru: testdata dosyasını tam yoluyla referans olarak kullanın.
//my/app/testdata:testdepot.zip
@// ile başlayan etiketler ana depoya yapılan referanslardır ve harici depolardan bile çalışmaya devam eder.
Bu nedenle, harici bir depodan referans verildiğinde @//a/b/c, //a/b/c'ten farklıdır.
İlk depo ana depo, ikinci depo ise
harici depoda //a/b/c araması yapar.
Bu, özellikle de temel
ana depodaki hedeflere işaret eden ve
bu verileri kullanır.
Hedeflere atıfta bulunmanın farklı yolları hakkında bilgi için hedef kalıpları.
Bir etiketin söz dizimi özellikleri
Etiket söz dizimi, kabuk için özel anlamı olan meta karakterlerin kullanılmasını engeller. Bu, yanlışlıkla tırnak içine alma sorunlarını önlemeye yardımcı olur ve Bazel Sorgu Dili gibi etiketleri değiştiren araç ve komut dosyalarını oluşturmayı kolaylaştırır.
İzin verilen hedef adlarıyla ilgili ayrıntıları aşağıda bulabilirsiniz.
Hedef adlar: package-name:target-name
target-name, paketteki hedefin adıdır. Kuralın adı
BUILD kuralının bildirimindeki name özelliğinin değeridir
file; bir dosyanın adı,
BUILD dosyası.
Hedef adlar tamamen a-z,
A-Z, 0-9 kümesinden alınan karakterlerden ve !%-@^_"#$&'()*-+,;<=>?[]{|}~/. noktalama işaretlerinden oluşmalıdır.
Dosya adları normal biçimde göreli yol adları olmalıdır; diğer bir deyişle,
başında veya sonunda eğik çizgiyle geçmez (örneğin, /foo ve foo/
yasaklanmıştır) veya yol ayırıcı olarak art arda birden fazla eğik çizgi içermemelidir
(örneğin, foo//bar). Benzer şekilde, üst düzey referanslar (..) ve
current-dizin başvuruları (./) yasaktır.
Yanlış: Diğer paketlerdeki dosyaları belirtmek için ".." kullanmayın.
Doğru: Kullanın `//package-name:filename`
Dosya hedefi adında / yaygın olarak kullanılsa da
Kural adlarında /. Özellikle bir etiketin kısaltılmış biçimi
okuyucunun kafasını karıştırabilir. //foo/bar/wiz etiketi, böyle bir foo/bar/wiz paketi olmasa bile her zaman //foo/bar/wiz:wiz için kısaltmadır; hedef mevcut olsa bile hiçbir zaman //foo:bar/wiz'a atıfta bulunmaz.
Bununla birlikte, eğik çizgi kullanmanın kullanışlı olduğu bazı durumlar veya hatta bazen gerekli olabilir. Örneğin, belirli kuralların adı ana kaynak dosyaları oluşturun. Bu dosyalar, paketin bir alt dizininde bulunabilir.
Paket adları: //package-name:target-name
Paketin adı, BUILD dosyasını içeren dizinin adıdır.
dizinin en üst düzey diziniyle ilişkilidir.
Örnek: my/app.
Paket adları tamamen A-Z, a-z, 0-9, "/", "-", ".", "@" ve "_" kümesinden alınan karakterlerden oluşmalı ve eğik çizgiyle başlayamaz.
Modül sistemi için önemli bir dizin yapısına sahip bir dil (ör. Java) söz konusu olduğunda, dilde geçerli tanımlayıcı olan dizin adları seçmek önemlidir.
Bazel, çalışma alanının kök paketindeki hedefleri desteklese de (örneğin,
//:foo) olduğu durumlarda, tüm anlamlı paketlerin hepsi için bu paketi boş bırakmak
açıklayıcı adlara sahiptir.
Paket adları // alt dizesini içeremez ve eğik çizgiyle bitemez.
Kurallar
Bir kural, girişler ve çıkışlar arasındaki ilişkiyi belirtir ve bu adımları gözden geçirin. Kurallar birçok farklı olabilir kural sınıfı olarak da adlandırılır. yürütülebilir dosyalar ve kitaplıklar, yürütülebilir dosyaları test çıkışları Ansiklopedi Oluşturma konusunda açıklandığı gibidir.
BUILD dosyaları, kuralları çağırarak hedefleri tanımlar.
Aşağıdaki örnekte, cc_binary kuralı kullanılarak hedef my_app için bir bildirim görüyoruz.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
Her kural çağrısının bir name özelliği vardır (bu özellik geçerli bir
target name) içerir.
BUILD dosyasından oluşur.
Her kuralın bir özellik grubu vardır. Belirli bir kural için geçerli özellikler ve her bir özelliğin önemi ve semantiği, kuralın türüne bağlıdır. Kurallar ve ilgili özelliklerin listesi için Build Encyclopedia'ya bakın. Her özelliğin bir adı ve tür. Özniteliğin sahip olabileceği yaygın türlerden bazıları tamsayı, etiket, liste etiket listesi, dize, dize listesi, çıkış etiketi, çıkış etiketleri listesi. Değil her kuralda tüm özelliklerin belirtilmesi gerekir. Böylece özellikler anahtarlardan (adlardan) isteğe bağlı, yazılan değerlere kadar pek çok işlevi kullanıma sunduk.
Birçok kuralda bulunan srcs özelliğinin türü "etiket listesi"dir; varsa değeri, her biri bu kurala giriş olan bir hedefin adı olan etiketlerin listesidir.
Bazı durumlarda kural türünün adı biraz keyfidir ve daha ilginç olan, kural tarafından oluşturulan dosyaların adlarıdır. Bu durum genrules için de geçerlidir. Daha fazla bilgi için bkz. Genel Kurallar: genrule.
Diğer durumlarda ise ad önemlidir: Örneğin, *_binary ve *_test kurallarında kural adı, derleme tarafından üretilen 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ştur ve bağımlılığın Bazel Sorgu aracı çalışır.
| Hedefler | Dosya derleyin |