Tüm hedefler tam olarak bir pakete aittir. Hedefin adı etiketi olarak adlandırılır. 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.
Bir etiketin, kullanıldığı depoyu kastettiği tipik durumda 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 kısmı, paketin depo köküne göre yolu olan nitelendirilmemiş 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 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. Bu nedenle, aşağıdaki 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. Bu dosya, deponun 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), 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.
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 atıfta 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 referans vermenin iki yolu (biri yanlış, biri doğru) vardır:
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 @//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.
Bir etiketin söz dizimi özellikleri
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
, paket içindeki hedefin adıdır. Bir kuralın adı, BUILD
dosyasında kuralın tanımındaki name
özelliğinin değeridir; bir dosyanın adı, BUILD
dosyasını içeren dizinle ilişkili yol adıdır.
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çimdeki göreli yol adları olmalıdır. Yani dosya adları eğik çizgiyle başlamamalı veya bitmemelidir (örneğin, /foo
ve foo/
yasaktır) ve 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 geçerli dizin referansları (./
) yasaktır.
Yanlış: Diğer paketlerdeki dosyaları belirtmek için ".." kullanmayın.
Doğru: "//package-name:filename" 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ısaltması kullanıldığında okuyucunun kafası karışabilir. //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 uygun veya bazen gerekli olduğu bazı durumlar vardır. Örneğin, belirli kuralların adı, paketin bir alt dizininde bulunabilecek ana kaynak dosyaları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.
Örneğin: 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 (ör. //: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 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ında, BUILD
dosyasının paketinde bir hedefi belirten 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 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ü 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ğ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 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.
Hedefler üzerindeki bu yönlendirilmiş acyclic grafiğe hedef grafiği veya derleme bağımlılık grafiği denir ve Bazel Sorgu aracının çalıştığı alandır.
Hedefler | Dosya derleyin |