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 |