Bu sayfa, derleme bağımlılıkları analiz etmek için bazel query
kullanırken kullanılan Bazel Sorgu Dili için referans kılavuzudur. Ayrıca, bazel query
'ün desteklediği çıkış biçimlerini de açıklar.
Pratik kullanım alanları için Bazel Sorgusu Nasıl Kullanılır? başlıklı makaleyi inceleyin.
Ek sorgu referansı
Bazel, yükleme sonrası aşama hedef grafiğinde çalışan query
'e ek olarak işlem grafiği sorgusu ve yapılandırılabilir sorguyu içerir.
İşlem grafiği sorgusu
İşlem grafiği sorgusu (aquery
), analiz sonrası yapılandırılmış hedef grafikte çalışır ve işlemler, öğeler ve bunların ilişkileri hakkında bilgi gösterir. aquery
, yapılandırılmış hedef grafiğinden oluşturulan işlemler/yapıların özellikleriyle ilgilendiğinizde kullanışlıdır.
Örneğin, gerçek komutların yanı sıra bunların girişleri, çıkışları ve anımsatıcıları çalışır.
Daha ayrıntılı bilgi için sorgu referansı bölümünü inceleyin.
Yapılandırılabilir sorgu
Geleneksel Bazel sorgusu, yükleme sonrası aşama hedef grafiğinde çalıştırılır. Bu nedenle, yapılandırmalar ve bunlarla ilgili kavramlar yoktur. Bu durum, select ifadeleri doğru şekilde çözümlemez ve bunun yerine seçimlerin olası tüm çözümlerini döndürür. Bununla birlikte, yapılandırılabilir sorgu ortamı cquery
, yapılandırmaları düzgün şekilde işler ancak bu orijinal sorgunun tüm işlevlerini sunmaz.
Daha fazla bilgi için sorgu referansı bölümüne bakın.
Örnekler
Kullanıcılar bazel query
'ü nasıl kullanıyor? Aşağıda tipik örnekler verilmiştir:
//foo
ağacı neden //bar/baz
bağımlılığına bağlıdır?
Bir yol göster:
somepath(foo/..., //bar/baz:all)
Tüm foo
testleri, foo_bin
hedefinin kullanmadığı hangi C++ kitaplıklarına bağlı?
kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))
Jetonlar: Söz dizimi
Sorgu dilindeki ifadeler aşağıdaki jetonlardan oluşur:
Anahtar kelimeler (ör.
let
). Anahtar kelimeler, dilin ayrılmış kelimeleridir ve her biri aşağıda açıklanmıştır. Anahtar kelimelerin tam listesi şunlardır:"
foo/...
" veya ".*test rule
" ya da "//bar/baz:all
" gibi kelimeler. Bir karakter dizisi "tırnak içine alınmışsa" (tek tırnak işareti ' ile başlar ve bitiyorsa veya çift tırnak işareti " ile başlar ve bitiyorsa) kelimedir. Bir karakter dizisi tırnak içine alınmasa bile kelime olarak ayrıştırılabilir. Tırnak içine alınmayan kelimeler, A-Za-z alfabe harfleri, 0-9 rakamları ve*/@.-_:$~[]
özel karakterlerinden (yıldız, eğik çizgi, yer işareti, nokta, tire, alt çizgi, iki nokta, dolar işareti, yaklaşık işareti, sol köşeli parantez, sağ köşeli parantez) oluşan karakter dizileridir. Ancak, göreli hedef adlar bu karakterlerle başlayabilse de tırnak içine alınmamış kelimeler kısa çizgi-
veya yıldız işareti*
ile başlayamaz.Ayrıca, hedef adlarda bu karakterlere izin verilse bile, tırnak içine alınmayan kelimeler artı işareti
+
veya eşittir=
işaretini içeremez. Sorgu ifadeleri oluşturan kod yazılırken hedef adlar tırnak içine alınmalıdır.Kullanıcı tarafından sağlanan değerlerden Bazel sorgu ifadeleri oluşturan komut dosyaları yazarken tırnak içine almak gerekir.
//foo:bar+wiz # WRONG: scanned as //foo:bar + wiz. //foo:bar=wiz # WRONG: scanned as //foo:bar = wiz. "//foo:bar+wiz" # OK. "//foo:bar=wiz" # OK.
Bu tırnak işaretlerinin, kabuğunuz tarafından gerekebilecek tırnak işaretlerine ek olduğunu unutmayın. Örneğin:
bazel query ' "//foo:bar=wiz" ' # single-quotes for shell, double-quotes for Bazel.
Anahtar kelimeler ve operatörler, tırnak içine alındığında normal kelimeler olarak kabul edilir. Örneğin,
some
bir anahtar kelimedir ancak "bazı" bir kelimedir. Hemfoo
hem de "foo" kelimedir.Ancak hedef adlarında tek veya çift tırnak kullanırken dikkatli olun. Bir veya daha fazla hedef adından alıntı yaparken yalnızca bir tür tırnak işareti (tümü tek veya çift tırnak) kullanın.
Java sorgu dizesinin nasıl görüneceğine dair örnekler aşağıda verilmiştir:
'a"'a' # WRONG: Error message: unclosed quotation. "a'"a" # WRONG: Error message: unclosed quotation. '"a" + 'a'' # WRONG: Error message: unexpected token 'a' after query expression '"a" + ' "'a' + "a"" # WRONG: Error message: unexpected token 'a' after query expression ''a' + ' "a'a" # OK. 'a"a' # OK. '"a" + "a"' # OK "'a' + 'a'" # OK
Çoğu durumda tırnak işaretlerine gerek olmaması için bu söz dizimini seçtik. (Sıra dışı)
".*test rule"
örneğinde tırnak işareti kullanılmalıdır: Noktayla başlar ve boşluk içerir."cc_library"
değerini tırnak içine almak gereksizdir ancak zararsızdır.Noktalama işaretleri (ör.
()
parantezleri,.
. nokta ve,
). Noktalama işareti içeren kelimeler (yukarıda belirtilen istisnalar dışında) tırnak içine alınmalıdır.
Tırnak içine alınan kelimenin dışındaki boşluk karakterleri yoksayılır.
Bazel sorgu dili kavramları
Bazel sorgu dili, bir ifade dilidir. Her ifade, kısmi olarak sıralanmış bir hedef grubunu veya eşdeğer olarak bir hedef grafiği (DAG) olarak değerlendirilir. Tek veri türü budur.
Set ve grafik aynı veri türüne işaret eder, ancak farklı yönlerini vurgulayın. Örneğin:
- Ayarla: Hedeflerin kısmi sırası ilgi çekici değildir.
- Grafik: Hedeflerin kısmi sırası önemlidir.
Bağımlılık grafiğindeki döngüler
Derleme bağımlılığı grafikleri döngüsel olmamalıdır.
Sorgu dili tarafından kullanılan algoritmalar, döngüsel olmayan grafiklerde kullanılmak üzere tasarlanmıştır ancak döngülere karşı dayanıklıdır. Döngülerin nasıl ele alındığına dair ayrıntılar belirtilmez ve bu ayrıntılara güvenilmemelidir.
Örtük bağımlılıklar
Bazel, BUILD
dosyalarında açık bir şekilde tanımlanan bağımlılıkları derlemenin yanı sıra kurallara ek dolaylı bağımlılıklar da ekler. Örneğin, her Java kuralı dolaylı olarak JavaBuilder'a bağlıdır. Örtük bağımlılıklar, $
ile başlayan özellikler kullanılarak oluşturulur ve BUILD
dosyalarında geçersiz kılınamaz.
Varsayılan olarak bazel query
, sorgu sonucunu hesaplarken gizli bağımlılıkları hesaba katar. Bu davranış, --[no]implicit_deps
seçeneğiyle değiştirilebilir. Sorguda yapılandırmayı dikkate almadığı için potansiyel araç zincirlerinin hiçbir zaman dikkate alınmadığını unutmayın.
Sağlamlık
Bazel sorgu dili ifadeleri, derleme bağımlılığı grafiği üzerinde çalışır. Bu grafik, tüm BUILD
dosyalarındaki tüm kural bildirimlerinin dolaylı olarak tanımladığı grafiktir. Bu grafiğin biraz soyut olduğunu ve derleme adımlarının tümünün nasıl uygulanacağına dair tam bir açıklama içermediğini anlamak önemlidir. Bir derleme gerçekleştirmek için yapılandırma da gerekir. Ayrıntılı bilgi için Kullanıcı Kılavuzu'nun configurations bölümüne bakın.
Bir ifadenin Bazel sorgu dilinde değerlendirilmesinin sonucu tüm yapılandırmalar için doğrudur. Bu, tam olarak kesin olmayan konservatif bir aşırı tahmin olabileceği anlamına gelir. Derleme sırasında gereken tüm kaynak dosyaların kümesini hesaplamak için sorgu aracını kullanırsanız sorgu aracı, derlemenizde bu özelliği kullanmayı düşünmeseniz bile mesaj çevirisini desteklemek için gereken tüm dosyaları içereceğinden, aslında gerekenden daha fazla dosya raporlanabilir.
Grafik sırasının korunması hakkında
İşlemler, alt ifadelerinden devralınan tüm sıralama kısıtlamalarını korur. Bunu "kısmi düzenin korunumu yasası" olarak düşünebilirsiniz. Bir örnek verelim: Belirli bir hedefin bağımlılıklarının geçişli kapatmasını belirlemek için bir sorgu gönderirseniz elde edilen küme, bağımlılık grafiğine göre sıralanır. Yalnızca file
türündeki hedefleri içerecek şekilde ayarlanan bir filtre uygularsanız, elde edilen alt kümedeki her hedef çifti arasında aynı geçişli kısmi sıralama ilişkisi geçerlidir (bu çiftlerin hiçbiri aslında orijinal grafikte doğrudan bağlı olmasa bile).
(Derleme bağımlılık grafiğinde dosya-dosya kenarları yoktur).
Ancak tüm operatörler sıralamayı korusa ancak set işlemleri gibi bazı işlemler kendi sıralama kısıtlamalarını kullanıma sunmaz. Şu ifadeye dikkat edin:
deps(x) union y
Nihai sonuç kümesinin sırasının, alt ifadelerinin tüm sıralama kısıtlamalarının korunması, diğer bir deyişle x
işlevinin tüm geçişli bağımlılıklarının birbirine göre doğru bir şekilde sıralanacağı garanti edilir. Ancak sorgu, y
'teki hedeflerin sıralaması veya deps(x)
'teki hedeflerin y
'teki hedeflere göre sıralaması hakkında hiçbir garanti vermez (y
'teki ve deps(x)
'teki hedeflerin aynı olması durumu hariç).
Sıralama kısıtlamaları getiren operatörler şunlardır:
allpaths
, deps
, rdeps
, somepath
ve hedef desen joker karakterleri
package:*
, dir/...
vb.
Gökyüzü sorgusu
Gökyüzü Sorgusu, belirtilen bir evren kapsamı üzerinde çalışan bir sorgu modudur.
Yalnızca SkyQuery'de kullanılabilen özel işlevler
Gökyüzü Sorgusu modunda allrdeps
ve rbuildfiles
ek sorgu işlevleri bulunur. Bu işlevler tüm evren kapsamında çalışır (bu nedenle normal Sorgu için bir anlam ifade etmezler).
Evren kapsamını belirtme
Gökyüzü sorgusu modu, aşağıdaki iki işaretin iletilmesi ile etkinleştirilir:
(--universe_scope
veya --infer_universe_scope
) ve
--order_output=no
.
--universe_scope=<target_pattern1>,...,<target_patternN>
, sorguya, hedef kalıplar tarafından belirtilen hedef kalıbın geçişli kapanışını önceden yüklemesini söyler. Bu işlem hem ekleme hem de çıkarmalı olabilir. Daha sonra tüm sorgular bu "kapsama" göre değerlendirilir. Özellikle allrdeps
ve rbuildfiles
operatörleri yalnızca bu kapsamdaki sonuçları döndürür.
--infer_universe_scope
, Bazel'a sorgu ifadesinden --universe_scope
için bir değer çıkarmasını söyler. Tahmin edilen bu değer, sorgu ifadesindeki benzersiz hedef kalıplarının listesidir ancak istediğiniz bu olmayabilir. Örneğin:
bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"
Bu sorgu ifadesindeki benzersiz hedef kalıplarının listesi ["//my:target"]
şeklindedir. Bu nedenle Bazel, bunu çağrıyla aynı şekilde değerlendirir:
bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"
Ancak --universe_scope
ile yapılan bu sorgunun sonucu yalnızca //my:target
olur. //my:target
öğesinin ters bağımlılıklarının hiçbiri yapı gereği evrende yoktur. Diğer yandan, şunu da göz önünde bulundurun:
bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"
Bu, bazı dizinlerdeki hedeflerin tests
genişletmesinde test hedeflerini hesaplamaya çalışan, tanımı belirli bir .bzl
dosyası kullanan hedeflere geçişli olarak bağlı olan anlamlı bir sorgu çağrısıdır. Burada --infer_universe_scope
, özellikle --infer_universe_scope
seçiminin sorgu ifadesini kendinizin ayrıştırmanızı gerektirdiği durumlarda kolaylık sağlar.
Bu nedenle, allrdeps
ve rbuildfiles
gibi evren kapsamlı operatörler kullanan sorgu ifadelerinde --infer_universe_scope
'u yalnızca davranışını istediğiniz gibi olduğunda kullandığınızdan emin olun.
Sky Query'nin, varsayılan sorguyla karşılaştırıldığında bazı avantajları ve dezavantajları vardır. Ana dezavantajı, çıktısını grafik sırasına göre sıralayamaması ve bu nedenle belirli çıktı biçimlerinin yasaklanmasıdır. Avantajları, varsayılan sorguda bulunmayan iki operatör (allrdeps
ve rbuildfiles
) sağlamasıdır.
Ayrıca Sky Query, varsayılan uygulamanın yaptığı gibi yeni bir grafik oluşturmak yerine Skyframe grafiğini inceleyerek çalışır. Dolayısıyla, ekibinizin daha hızlı olduğu
ve daha az bellek kullandığı bazı durumlar da vardır.
İfadeler: Dilbilgisinin söz dizimi ve anlamı
EBNF biçiminde ifade edilen Bazel sorgu dilinin dil bilgisi şöyledir:
expr ::= word
| let name = expr in expr
| (expr)
| expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
| set(word *)
| word '(' int | word | expr ... ')'
Aşağıdaki bölümlerde bu dilbilgisinin tüm üretimleri sırayla açıklanmaktadır.
Hedef kalıpları
expr ::= word
Söz dizimi açısından, hedef desen yalnızca bir kelimedir. Bu, bir (sıralı olmayan) hedef grubu olarak yorumlanır. En basit hedef kalıbı, tek bir hedefi (dosya veya kural) tanımlayan bir etikettir. Örneğin, //foo:bar
hedef kalıbı bir öğe, hedef ve bar
kuralını içeren bir küme olarak değerlendirilir.
Hedef kalıpları, paketler ve hedefler yerine joker karakterleri içerecek şekilde etiketleri genelleştirir. Örneğin, foo/...:all
(veya yalnızca foo/...
), foo
dizininin altındaki her pakette bulunan tüm kuralları içeren bir küme olarak değerlendirilen bir hedef kalıptır; bar/baz:all
ise bar/baz
paketindeki tüm kuralları (alt paketleri hariç) içeren bir küme olarak değerlendirilen bir hedef kalıptır.
Benzer şekilde foo/...:*
, foo
dizininin altında bulunan her paketteki tüm hedefleri (kurallar ve dosyaları) içeren bir küme olarak değerlendirilen bir hedef kalıptır. bar/baz:*
ise bar/baz
paketindeki tüm hedefleri içeren ancak alt paketlerini içermeyen bir küme olarak değerlendirilir.
:*
joker karakteri, kuralların yanı sıra dosyalarla da eşleştiğinden, sorgular için :all
karakterinden genellikle daha yararlıdır. Buna karşılık, :all
joker karakteri (foo/...
gibi hedef kalıplarda örtülü), genellikle derlemeler için daha yararlıdır.
bazel query
hedef kalıpları, bazel build
derleme hedeflerinin çalışmalarıyla aynı şekilde çalışır.
Daha ayrıntılı bilgi için Hedef Kalıplar'a bakın veya bazel help target-syntax
yazın.
Hedef kalıplar, tek öğeli bir küme (etiket durumunda), çok sayıda öğe içeren bir küme (binlerce öğe içeren foo/...
durumunda olduğu gibi) veya hedef kalıp hiçbir hedefle eşleşmezse boş küme olarak değerlendirilebilir.
Bir hedef kalıbı ifadesinin sonucundaki tüm düğümler, bağımlılık ilişkisine göre birbirine göre doğru şekilde sıralanır. Yani foo:*
sonucunun sonucu yalnızca foo
paketindeki hedef kümesi değildir, aynı zamanda bu hedeflerin üzerindeki grafiktir. (Sonuç düğümlerinin diğer düğümlere göre göreli sıralamasıyla ilgili herhangi bir garanti verilmez.) Daha fazla bilgi için grafik sırası bölümüne bakın.
Değişkenler
expr ::= let name = expr1 in expr2
| $name
Bazel sorgu dili, değişkenlerin tanımlanmasına ve bunlara referans verilmesine olanak tanır. Bir let
ifadesinin değerlendirilmesinin sonucu, name değişkeninin tüm bağımsız kullanımlarının expr1 değerine değiştirilmesiyle expr2 ile aynıdır.
Örneğin let v = foo/... in allpaths($v, //common) intersect $v
, allpaths(foo/...,//common) intersect foo/...
ile eşdeğerdir.
name
değişken referansının, kapsayıcı let name = ...
ifadesi dışında kullanılması hatadır. Diğer bir deyişle, üst düzey sorgu ifadelerinde serbest değişkenler olamaz.
Yukarıdaki dil bilgisi üretimlerinde name
, kelime gibidir ancak C programlama dilinde yasal bir tanımlayıcı olması ek kısıtlaması vardır. Değişken referanslarına "$" karakteri eklenmelidir.
Her let
ifadesi yalnızca tek bir değişkeni tanımlar, ancak bunları iç içe yerleştirebilirsiniz.
Hem hedef kalıplar hem de değişken referansları yalnızca tek bir jetondan (kelime) oluştuğu için söz dizimi belirsizliği oluşturur. Ancak, yasal değişken adları olan kelime alt kümesi, yasal hedef kalıpları olan kelime alt kümesinden ayrı olduğundan anlamsal belirsizlik yoktur.
Teknik açıdan bakıldığında let
ifadeleri, sorgu dilinin ifade gücünü artırmaz: Bir dilde ifade edilebilen herhangi bir sorgu, söz konusu dil kullanılmadan da ifade edilebilir. Ancak bu işlevler, birçok sorgunun kısalığını iyileştirir ve daha verimli sorgu değerlendirmesine yol açabilir.
Parantez içine alınmış ifadeler
expr ::= (expr)
Parantezler, değerlendirme sırasını zorlamak için alt ifadeleri ilişkilendirir. Parantez içine alınmış bir ifade, bağımsız değişkeninin değerine göre değerlendirilir.
Cebirsel küme işlemleri: kesişim, bütünleşme, fark belirleme
expr ::= expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
Bu üç operatör, bağımsız değişkenleri yerine normal set işlemlerini hesaplar.
Her operatörün iki biçimi vardır: intersect
gibi nominal form ve ^
gibi sembolik form. Her iki biçim de eşdeğerdir; sembolik biçimler
daha hızlı yazılır. (Daha net bir ifadeyle, bu sayfanın geri kalanında nominal formlar kullanılmaktadır.)
Örneğin,
foo/... except foo/bar/...
foo/...
ile eşleşen, ancak foo/bar/...
ile eşleşmeyen hedef kümesini değerlendirir.
Aynı sorguyu şu şekilde yazabilirsiniz:
foo/... - foo/bar/...
intersect
(^
) ve union
(+
) işlemleri değişmeli (simetrik);
except
(-
) asimetriktir. Ayrıştırıcı, üç operatörü de sol-ilişkili ve eşit öncelikli olarak ele aldığından parantez isteyebilirsiniz. Örneğin, bu ifadelerin ilk ikisi eşdeğerdir ancak üçüncüsü değildir:
x intersect y union z
(x intersect y) union z
x intersect (y union z)
Harici bir kaynaktan hedefleri okuma: ayarlandı
expr ::= set(word *)
set(a b c ...)
operatörü, boşluklarla ayrılmış (virgülle değil) sıfır veya daha fazla hedef kalıbın birleşimini hesaplar.
Bourne kabuğunun $(...)
özelliği ile birlikte, set()
bir sorgunun sonuçlarını normal bir metin dosyasına kaydetmek, bu metin dosyasını başka programlar (standart UNIX kabuk araçları gibi) kullanarak değiştirmek ve daha sonra daha fazla işlem yapmak için sonucu sorgu aracına tekrar sunmak anlamına gelir. Örneğin:
bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"
Bir sonraki örnekte kind(cc_library, deps(//some_dir/foo:main, 5))
,bir awk
programı kullanılarak maxrank
değerleri filtrelenerek hesaplanmıştır.
bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"
Bu örneklerde $(<foo)
, $(cat foo)
ifadesinin kısaltmasıdır ancak önceki awk
komutu gibi cat
dışındaki kabuk komutları da kullanılabilir.
İşlevler
expr ::= word '(' int | word | expr ... ')'
Sorgu dili çeşitli işlevler tanımlar. İşlevin adı, gerektirdiği bağımsız değişkenlerin sayısını ve türünü belirler. Aşağıdaki işlevler kullanılabilir:
allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible
Bağımlılıkların geçişli kapatması: deps
expr ::= deps(expr)
| deps(expr, depth)
deps(x)
operatörü, x bağımsız değişken grubunun bağımlılıklarının geçişli olarak kapatılmasıyla oluşturulan grafiği değerlendirir. Örneğin, deps(//foo)
değeri, tüm bağımlılıkları dahil olmak üzere foo
tek düğümüne dayanan bağımlılık grafiğidir. deps(foo/...)
değeri, kökleri foo
dizininin altındaki her pakette bulunan tüm kurallar olan bağımlılık grafikleridir. Bu bağlamda "bağımlılıklar" yalnızca kural ve dosya hedefleri anlamına gelir. Dolayısıyla bu hedefleri oluşturmak için gereken BUILD
ve Starlark dosyaları buraya dahil edilmemiştir. Bunun için buildfiles
operatörünü kullanmanız gerekir.
Elde edilen grafik, bağımlılık ilişkisine göre sıralanır. Ayrıntılı bilgi için grafik sırası bölümüne bakın.
deps
operatörü, isteğe bağlı ikinci bir bağımsız değişken kabul eder. Bu bağımsız değişken, aramanın derinliği için üst sınırı belirten bir tam sayı değişmez ifadesidir. Dolayısıyla deps(foo:*, 0)
, foo
paketindeki tüm hedefleri döndürürken deps(foo:*, 1)
ayrıca foo
paketindeki herhangi bir hedefin doğrudan ön koşullarını içerir ve deps(foo:*, 2)
ayrıca deps(foo:*, 1)
içindeki düğümlerden doğrudan erişilebilen düğümleri içerir. (Bu sayılar, minrank
çıkış biçiminde gösterilen sıralamalara karşılık gelir.)
depth parametresi atlanırsa arama sınırsızdır: ön koşulların yansıtmalı geçişli kapatmasını hesaplar.
Ters bağımlılıkların geçişli kapatması: rdeps
expr ::= rdeps(expr, expr)
| rdeps(expr, expr, depth)
rdeps(u, x)
operatörü, u evren kümesinin geçişli kapatma kümesi içinde x bağımsız değişken kümesinin ters bağımlılıkları olarak değerlendirilir.
Ortaya çıkan grafik, bağımlılık ilişkisine göre sıralanır. Daha ayrıntılı bilgi için grafik sırası bölümüne bakın.
rdeps
operatörü, isteğe bağlı bir üçüncü bağımsız değişkeni kabul eder. Bu bağımsız değişken, aramanın derinliği için bir üst sınır belirten bir tam sayı değişmez ifadesidir. Sonuçta ortaya çıkan grafik, yalnızca bağımsız değişken grubundaki herhangi bir düğümden belirtilen derinliğe kadar olan mesafedeki düğümleri içerir. Dolayısıyla rdeps(//foo, //common, 1)
, doğrudan //common
öğesine bağlı olan //foo
öğesinin geçişli kapanmasındaki tüm düğümleri değerlendirir. (Bu sayılar, minrank
çıkış biçiminde gösterilen sıralamalara karşılık gelir.) depth parametresi atlanırsa arama sınırsızdır.
Tüm ters bağımlılıkların geçici olarak kapatılması: allrdeps
expr ::= allrdeps(expr)
| allrdeps(expr, depth)
allrdeps
operatörü, rdeps
operatörü gibi davranır. Tek fark, "evre kümesi"nin ayrı olarak belirtilmesi yerine --universe_scope
işaretinin değerlendirildiği değer olmasıdır. Bu nedenle, --universe_scope=//foo/...
geçildiyse allrdeps(//bar)
, rdeps(//foo/..., //bar)
ile eşdeğerdir.
Aynı paketteki doğrudan ters bağımlılıklar: Aynı_pkg_direct_rdeps
expr ::= same_pkg_direct_rdeps(expr)
same_pkg_direct_rdeps(x)
operatörü, bağımsız değişken grubundaki bir hedefle aynı pakette bulunan ve doğrudan ona bağlı olan tüm hedef kümesini değerlendirir.
Bir hedefin paketiyle başa çıkma: kardeşler
expr ::= siblings(expr)
siblings(x)
operatörü, bağımsız değişken grubundaki bir hedefle aynı pakette bulunan tüm hedef grubunu değerlendirir.
İsteğe bağlı seçim: bazı
expr ::= some(expr)
| some(expr, count )
some(x, k)
operatörü, bağımsız değişken kümesi x'den rastgele en fazla k hedef seçer ve yalnızca bu hedefleri içeren bir küme olarak değerlendirilir. k parametresi isteğe bağlıdır. Eksik
olursa sonuç, rastgele seçilmiş tek bir hedef içeren bir tekil grup olur. x bağımsız değişken kümesinin boyutu k bağımsız değişken kümesinden küçükse x bağımsız değişken kümesinin tamamı döndürülür.
Örneğin, some(//foo:main union //bar:baz)
ifadesi, //foo:main
veya //bar:baz
içeren bir singleton kümesi olarak değerlendirilir ancak bu küme tanımlanmamıştır. some(//foo:main union //bar:baz, 2)
veya some(//foo:main union //bar:baz, 3)
ifadesi hem //foo:main
hem de //bar:baz
değerini döndürür.
Bağımsız değişken tekil ise some
, kimlik işlevini hesaplar: some(//foo:main)
, //foo:main
ile eşdeğerdir.
Belirtilen bağımsız değişken grubu boşsa (some(//foo:main intersect //bar:baz)
ifadesinde olduğu gibi) hata oluşur.
Yol operatörleri: biryol, tümyollar
expr ::= somepath(expr, expr)
| allpaths(expr, expr)
somepath(S, E)
ve allpaths(S, E)
operatörleri, iki hedef grubu arasındaki yolları hesaplar. Her iki sorgu da iki bağımsız değişkeni kabul eder: bir başlangıç noktası S grubu ve bir bitiş noktası E grubu. somepath
, S'daki bir hedeften E'daki bir hedefe giden belirli bir yoldaki düğümlerin grafiğini döndürür; allpaths
ise S'daki herhangi bir hedeften E'daki herhangi bir hedefe giden tüm yollardaki düğümlerin grafiğini döndürür.
Elde edilen grafikler, bağımlılık ilişkisine göre sıralanır. Daha fazla bilgi için grafik sırası ile ilgili bölümü inceleyin.
Hedef tür filtreleme: tür
expr ::= kind(word, expr)
kind(pattern, input)
operatörü, bir hedef grubuna filtre uygular ve beklenen türde olmayan hedefleri siler. pattern
parametresi, eşlenecek hedefin türünü belirtir.
Örneğin, aşağıda gösterilen BUILD
dosyası (p
paketi için) tarafından tanımlanan dört hedefin türleri tabloda gösterilmiştir:
Kod | Hedef | Tür |
---|---|---|
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", ) |
//p:a |
genel kuralı |
//p:a.in |
kaynak dosya | |
//p:a.out |
oluşturulan dosya | |
//p:BUILD |
kaynak dosya |
Bu nedenle, kind("cc_.* rule", foo/...)
, foo
altındaki tüm cc_library
, cc_binary
vb. kural hedeflerinin kümesini, kind("source file", deps(//foo))
ise //foo
hedefinin bağımlılıkların geçişli kapatma kümesinde bulunan tüm kaynak dosyalarının kümesini değerlendirir.
pattern bağımsız değişkeninin tırnak işareti kullanımı, bu bağımsız değişkenin ayrıştırıcı tarafından kelime olarak kabul edilmediği source
file
ve .*_test
gibi birçok normal ifade olmadığı için çoğu zaman gereklidir.
package group
için eşleşirken :all
ile biten hedefler hiçbir sonuç vermeyebilir. Bunun yerine :all-targets
politikasını kullanın.
Hedef adı filtreleme: filtre
expr ::= filter(word, expr)
filter(pattern, input)
operatörü, bir hedef grubuna filtre uygular ve etiketleri (mutlak biçimde) kalıpla eşleşmeyen hedefleri siler; girişlerinin bir alt kümesi olarak değerlendirilir.
İlk bağımsız değişken pattern, hedef adlar üzerinde bir normal ifade içeren bir kelimedir. Bir filter
ifadesi, tüm x hedeflerini içeren küme olarak değerlendirilir. Burada, x input kümesinin üyesi olur ve x etiketinin etiketi (//foo:bar
gibi mutlak biçimde) pattern normal ifadesi için (bağlanmamış) bir eşleşme içerir. Tüm hedef adlar //
ile başladığından //
normal ifade ankrasına alternatif olarak kullanılabilir.
Bu operatör genellikle intersect
operatörüne kıyasla çok daha hızlı ve daha güçlü bir alternatif sunar. Örneğin, //foo:foo
hedefinin tüm bar
bağımlılıklarını görmek için şunları değerlendirebilirsiniz:
deps(//foo) intersect //bar/...
Ancak bu ifade, bar
ağacındaki tüm BUILD
dosyalarının ayrıştırılmasını gerektirir. Bu işlem yavaştır ve alakasız BUILD
dosyalarında hatalara açıktır. Alternatif olarak:
filter(//bar, deps(//foo))
Bu işlem önce //foo
bağımlılıkları kümesini hesaplar, ardından yalnızca sağlanan kalıpla eşleşen hedefleri filtreler. Diğer bir deyişle, adlarında alt dize olarak //bar
bulunan hedefleri filtreler.
filter(pattern,
expr)
operatörünün yaygın olarak kullanılan bir diğer işlevi, belirli dosyaları adlarına veya uzantılarına göre filtrelemektir. Örneğin,
filter("\.cc$", deps(//foo))
//foo
derlemek için kullanılan tüm .cc
dosyalarının listesini sağlar.
Kural özelliği filtreleme: attr
expr ::= attr(word, word, expr)
attr(name, pattern, input)
operatörü, bir dizi hedefe filtre uygular ve kural olmayan hedefleri, name özelliğinin tanımlı olmadığı kural hedeflerini veya özellik değerinin sağlanan normal ifadeyle pattern eşleşmediği kural hedeflerini siler. Girişin bir alt kümesini değerlendirir.
Birinci bağımsız değişken olan name, sağlanan normal ifade kalıbıyla eşleştirilmesi gereken kural özelliğinin adıdır. İkinci bağımsız değişken pattern, özellik değerleri için bir düzenli ifadedir. Bir attr
ifadesi, x input kümesinin bir üyesi olacak şekilde tüm x hedeflerini içeren küme olarak değerlendirilir. Bu ifade, tanımlanmış name özelliğine sahip bir kuraldır ve özellik değeri, pattern normal ifadesiyle bir (sabitlenmemiş) eşleşme içerir. name isteğe bağlı bir özellikse ve kuralda açıkça belirtilmezse karşılaştırma için varsayılan özellik değeri kullanılır. Örneğin,
attr(linkshared, 0, deps(//foo))
linkshared özelliğine sahip olmasına izin verilen tüm //foo
bağımlılıkları (cc_binary
kuralı gibi) seçer ve bu özelliği açıkça 0 olarak ayarlar veya hiç ayarlamaz ancak varsayılan değer 0 olur (cc_binary
kuralları için olduğu gibi).
Liste türündeki özellikler (srcs
, data
vb.), [
köşeli paranteziyle başlayan, ]
köşeli paranteziyle biten ve birden fazla değeri ayırmak için ",
" (virgül, boşluk) kullanılan [value<sub>1</sub>, ..., value<sub>n</sub>]
biçimindeki dizelere dönüştürülür.
Etiketler, etiketin mutlak biçimi kullanılarak dizelere dönüştürülür. Örneğin, deps=[":foo",
"//otherpkg:bar", "wiz"]
özelliği [//thispkg:foo, //otherpkg:bar, //thispkg:wiz]
dizesine dönüştürülür.
Köşeli parantezler her zaman mevcuttur. Bu nedenle, boş listede eşleştirme amacıyla []
dize değeri kullanılır. Örneğin,
attr("srcs", "\[\]", deps(//foo))
boş bir srcs
özelliğine sahip //foo
bağımlılık
arasındaki tüm kuralları seçerken
attr("data", ".{3,}", deps(//foo))
//foo
bağımlılıkları arasından data
özelliğinde en az bir değer belirten tüm kuralları seçer (//
ve :
nedeniyle her etiket en az 3 karakter uzunluğundadır).
Liste türü özelliğinde belirli bir value
içeren //foo
bağımlılıkları arasındaki tüm kuralları seçmek için şunu kullanın:
attr("tags", "[\[ ]value[,\]]", deps(//foo))
Bu, value
karakterinden önceki karakterin [
veya boşluk, value
karakterinden sonraki karakterin ise virgül veya ]
olması nedeniyle işe yarar.
Kural görünürlüğü filtreleme: görünür
expr ::= visible(expr, expr)
visible(predicate, input)
operatörü, bir dizi hedefe filtre uygular ve gerekli görünürlüğe sahip olmayan hedefleri siler.
Birinci bağımsız değişken olan predicate, çıkıştaki tüm hedeflerin görünür olması gereken bir hedef grubudur. Bir visible ifadesi, x input kümesinin bir üyesi olacak şekilde tüm x hedeflerini içeren küme olarak değerlendirilir ve predicate içindeki tüm y hedefleri için x, y tarafından görülebilir. Örneğin:
visible(//foo, //bar:*)
//bar
paketindeki //foo
'ın görünürlük kısıtlamalarını ihlal etmeden bağımlı olabileceği tüm hedefleri seçer.
Etiket türü kural özelliklerinin değerlendirilmesi: etiketler
expr ::= labels(word, expr)
labels(attr_name, inputs)
operatörü, inputs kümesindeki bir kuraldaki "etiket" veya "etiket listesi" türündeki attr_name özelliğinde belirtilen hedef grubunu döndürür.
Örneğin, labels(srcs, //foo)
, //foo
kuralının srcs
özelliğinde görünen hedef grubu döndürür. inputs grubunda srcs
özelliklerine sahip birden fazla kural varsa srcs
özelliklerinin birleşimi döndürülür.
test_suites: tests öğesini genişletip filtreleme
expr ::= tests(expr)
tests(x)
operatörü, x kümesindeki tüm test kuralları grubunu döndürür, tüm test_suite
kurallarını başvurdukları bağımsız testler kümesine genişletir ve tag
ile size
ölçütlerine göre filtreleme uygular.
Sorgu değerlendirmesi varsayılan olarak tüm test_suite
kurallarındaki test dışı hedefleri yoksayar. Bu, --strict_test_suite
seçeneğiyle hata olarak değiştirilebilir.
Örneğin, kind(test, foo:*)
sorgusu foo
paketindeki tüm *_test
ve test_suite
kurallarını listeler. Tüm sonuçlar (tanım gereği) foo
paketinin üyeleridir. Buna karşılık, tests(foo:*)
sorgusu bazel test
foo:*
tarafından yürütülecek tüm bağımsız testleri döndürür: Bu, test_suite
kuralları aracılığıyla doğrudan veya dolaylı olarak referans verilen, diğer paketlere ait testleri içerebilir.
Paket tanımı dosyaları: buildfiles
expr ::= buildfiles(expr)
buildfiles(x)
operatörü, x kümesindeki her bir hedefin paketlerini tanımlayan dosya grubunu; diğer bir deyişle her bir paketin BUILD
dosyasını ve load
aracılığıyla başvurduğu tüm .bzl dosyalarını döndürür. Bu işlemin, bu load
ed dosyalarını içeren paketlerin BUILD
dosyalarını da döndürdüğünü unutmayın.
Bu operatör genellikle belirli bir hedefi oluşturmak için hangi dosyaların veya paketlerin gerekli olduğunu belirlerken ve genellikle aşağıdaki --output package
seçeneğiyle birlikte kullanılır. Örneğin,
bazel query 'buildfiles(deps(//foo))' --output package
//foo
öğesinin geçişli olarak bağlı olduğu tüm paketlerin grubunu döndürür.
Paket tanımı dosyaları: rbuildfiles
expr ::= rbuildfiles(word, ...)
rbuildfiles
operatörü, yol parçalarının virgülle ayrılmış listesini alır ve bu yol parçalarına geçişli olarak bağımlı BUILD
dosya grubunu döndürür. Örneğin, //foo
bir paketse rbuildfiles(foo/BUILD)
, //foo:BUILD
hedefini döndürür. foo/BUILD
dosyasında load('//bar:file.bzl'...
varsa rbuildfiles(bar/file.bzl)
, //foo:BUILD
hedefini ve //bar:file.bzl
yükleyen diğer tüm BUILD
dosyalarının hedeflerini döndürür.
--universe_scope
işaretçisi tarafından belirtilen evrendir. Doğrudan BUILD
dosyalarına ve .bzl
dosyalarına karşılık gelmeyen dosyalar sonuçları etkilemez. Örneğin, BUILD
dosyasında açıkça belirtilmiş olsalar bile kaynak dosyalar (foo.cc
gibi) yoksayılır. Ancak sembol bağlantılara uyulur. Dolayısıyla foo/BUILD
, bar/BUILD
ile sembolik bağlantıysa rbuildfiles(bar/BUILD)
sonuçları //foo:BUILD
ifadesini içerir.
rbuildfiles
operatörü, buildfiles
operatörünün neredeyse ahlaki olarak tersidir. Ancak bu ahlaki ters çevirme, bir yönde daha güçlüdür: rbuildfiles
'ün çıkışları buildfiles
'ün girişlerine benzer; önceki yalnızca paketlerde BUILD
dosya hedefleri içerir ve ikincisi bu tür hedefler içerebilir. Diğer yönde ise bu ilişki daha zayıftır. buildfiles
operatörünün çıkışları, tüm paketlere ve .bzl
Belirli bir giriş için gereken dosyalar. Bununla birlikte, rbuildfiles
operatörünün girişleri bu hedefler değil, bu hedeflere karşılık gelen yol parçalarıdır.
Paket tanımı dosyaları: loadfiles
expr ::= loadfiles(expr)
loadfiles(x)
operatörü, x kümesinde her hedefin paketlerini yüklemek için gereken Starlark dosyalarını döndürür. Diğer bir deyişle, her paket için BUILD
dosyalarından referans verilen .bzl dosyalarını döndürür.
Çıkış biçimleri
bazel query
bir grafik oluşturur.
bazel query
tarafından bu grafiği sunmak için kullanılan içeriği, biçimi ve sıralamayı --output
komut satırı seçeneğini kullanarak belirtirsiniz.
Sky Query ile çalışırken yalnızca sırasız çıkışla uyumlu olan çıkış biçimlerine izin verilir. Özellikle, graph
, minrank
ve maxrank
çıkış biçimleri yasaktır.
Çıkış biçimlerinden bazıları ek seçenekleri kabul eder. Her çıkış seçeneğinin adı, geçerli olduğu çıkış biçimiyle başlar. Bu nedenle --graph:factored
yalnızca --output=graph
kullanıldığında geçerli olur; graph
dışında bir çıkış biçimi kullanıldığında etkisi yoktur. Benzer şekilde, --xml:line_numbers
yalnızca --output=xml
kullanıldığında geçerlidir.
Sonuçların sıralaması
Sorgu ifadeleri her zaman "grafik sırasının korunması yasası"na uysa da sonuçların sunulması, bağımlılık sırasına göre veya sırasız olarak yapılabilir. Bu, sonuç kümesindeki hedefleri veya sorgunun nasıl hesaplandığını etkilemez. Yalnızca sonuçların stdout'a yazdırılma şeklini etkiler. Ayrıca, bağımlılık sırasına göre eşdeğer olan düğümler alfabetik olarak sıralanabilir veya sıralanmayabilir.
Bu davranışı kontrol etmek için --order_output
işaretçisi kullanılabilir.
(--[no]order_results
işareti, --order_output
işaretinin işlevlerinin bir alt kümesini içerir ve desteği sonlandırılmıştır.)
Bu işaretin varsayılan değeri auto
şeklindedir ve sonuçları sözlüksel sıralama ile yazdırır. Ancak somepath(a,b)
kullanıldığında, sonuçlar bunun yerine deps
sırasına göre yazdırılır.
Bu işaret no
olduğunda ve --output
build
, label
, label_kind
, location
, package
, proto
veya xml
arasından biri olduğunda çıkışlar rastgele sırayla yazdırılır. Bu genellikle en hızlı seçenektir. Ancak --output
değeri graph
, minrank
veya maxrank
değerlerinden biri olduğunda desteklenmez: Bu biçimlerde, Bazel her zaman bağımlılık sırasına veya sıralamasına göre sıralanmış sonuçları yazdırır.
Bu işaret deps
olduğunda Bazel, sonuçları topolojik bir sırada (yani önce bağımlılıklar) yazdırır. Ancak bağımlılık sırasına göre sıralandırılmayan düğümler (birinden diğerine yol olmadığı için) herhangi bir sırada basılabilir.
Bu işaret full
olduğunda Bazel, düğümleri tamamen deterministik (toplam) bir sırada yazdırır.
Öncelikle, tüm düğümler alfabetik olarak sıralanır. Daha sonra listedeki her bir düğüm, ziyaret edilmemiş düğümlere giden kenarların alfabetik olarak sıradaki düğümlerin tanıtıldığı bir sipariş sonrası derinlik öncelikli aramanın başlangıcı olarak kullanılır. Son olarak, düğümler ziyaret edildikleri sıranın tersine göre yazdırılır.
Düğümleri bu sırada yazdırma işlemi daha yavaş olabilir. Bu nedenle, yalnızca determinizm önemli olduğunda kullanılmalıdır.
Hedeflerin kaynak biçimini BUILD'da görünecekleri şekilde yazdırın
--output build
Bu seçenekte, her hedefin temsili BUILD dilinde elle yazılmış gibidir. Tüm değişkenler ve işlev çağrıları (glob, makrolar gibi) genişletilir. Bu, Starlark makrolarının etkisini görmek açısından yararlıdır. Ayrıca her etkili kural, etkili kuralı oluşturmak için değerlendirilen makronun adını vererek bir generator_name
ve/veya generator_function
değeri bildirir.
Çıktı, BUILD
dosyalarıyla aynı söz dizimini kullansa da geçerli bir BUILD
dosyası oluşturması garanti edilmez.
Her hedefin etiketini yazdırma
--output label
Bu seçenekle, elde edilen grafikteki her hedefin ad grubu (veya etiketleri), satır başına bir etiket olacak şekilde topolojik sırada yazdırılır (--noorder_results
belirtilmediği sürece sonuçların sıralanmasıyla ilgili notlara bakın).
(Topolojik sıralama, bir grafik düğümünün tüm haleflerinden önce göründüğü sıralamadır.) Elbette bir grafiğin birçok topolojik sıralaması vardır (ters sondan önce bunlardan yalnızca biridir). Hangisinin seçildiği belirtilmez.
somepath
sorgusunun çıktısı yazdırılırken düğümlerin yazdırılma sırası, yolun sırasıdır.
Uyarı: Bazı uç durumlarda, aynı etikete sahip iki farklı hedef olabilir. Örneğin, bir sh_binary
kuralı ve tek (dolaylı) srcs
dosyası foo.sh
olarak adlandırılabilir. Bir sorgunun sonucu bu hedeflerin ikisini de içeriyorsa çıkış (label
biçiminde) bir kopya içeriyormuş gibi görünür. label_kind
(aşağıya bakın) biçimi kullanıldığında bu fark net bir şekilde anlaşılır: İki hedefin adı aynıdır ancak birinin türü sh_binary rule
, diğerinin türü source file
'dir.
Her hedefin etiketini ve türünü yazdırma
--output label_kind
label
gibi bu çıkış biçimi de sonuçta elde edilen grafikteki her hedefin etiketlerini topolojik sırayla yazdırır ancak etiketten önce hedefin türünü de ekler.
Hedefleri protokol arabelleği biçiminde yazdırma
--output proto
Sorgu çıkışını QueryResult
protokol arabelleği olarak yazdırır.
Hedefleri uzunlukla sınırlandırılmış protokol arabelleği biçiminde yazdır
--output streamed_proto
Target
protokol arabelleklerinin uzunluk sınırlandırılmış akışını yazdırır. Bu, (i) tek bir QueryResult
'e sığmayacak kadar çok hedef olduğunda protokol arabelleklerinin boyut sınırlamalarını aşmak veya (ii) Bazel hâlâ çıkış verirken işlemeyi başlatmak için kullanışlıdır.
Hedefleri metin protokolü biçiminde yazdır
--output textproto
--output proto
'e benzer şekilde, QueryResult
protokol arabelleğini metin biçiminde yazdırır.
Hedefleri ndjson biçiminde yazdır
--output streamed_jsonproto
--output streamed_proto
'e benzer şekilde, Target
protokol arabelleklerinin akışını ndjson biçiminde yazdırır.
Her hedefin etiketini sıralama sırasına göre yazdır
--output minrank --output maxrank
label
gibi, minrank
ve maxrank
çıkış biçimleri de elde edilen grafikte her hedefin etiketlerini yazdırır. Ancak bu etiketler topolojik sırada görünmek yerine sıralama numarasından önce gelen sırada görünür. Bunlar, sonuç sıralama
--[no]order_results
işaretinden etkilenmez (sonuçların sıralamasıyla ilgili
notlara bakın).
Bu biçimin iki varyantı vardır: minrank
her düğümü bir kök düğümden kendisine giden en kısa yolun uzunluğuna göre sıralar.
"Kök" düğümler (gelen kenarları olmayanlar) 0, sonrakileri ise 1. sıradadır vb. (Her zaman olduğu gibi kenarlar, bir hedefin ön koşullarına işaret eder: hedeflerin bağımlı olduğu hedefler.)
maxrank
, her düğümü bir kök düğümden kendisine giden en uzun yolun uzunluğuna göre sıralar. Yine, "kökler" 0 sırasına sahiptir, diğer tüm düğümler ise önceki tüm düğümlerin maksimum sırasından bir fazla sıraya sahiptir.
Bir döngüdeki tüm düğümler eşit rütbeye sahiptir. (Çoğu grafik döngüseldir ancak BUILD
dosyaları hatalı döngüler içerdiği için döngüler kolayca gerçekleşir.)
Bu çıkış biçimleri, bir grafiğin ne kadar derin olduğunu keşfetmek için yararlıdır. deps(x)
, rdeps(x)
veya allpaths
sorgusunun sonucu için kullanılırsa sıralama numarası, x
ile bu sıralamadaki bir düğüm arasında kalan en kısa (minrank
ile) ya da en uzun (maxrank
ile) yolun uzunluğuna eşittir. maxrank
, bir hedef oluşturmak için gereken en uzun oluşturma adımları dizisini belirlemek amacıyla kullanılabilir.
Örneğin, soldaki grafikte sırasıyla --output minrank
ve --output maxrank
belirtildiğinde sağdaki çıkışlar elde edilir.
minrank 0 //c:c 1 //b:b 1 //a:a 2 //b:b.cc 2 //a:a.cc |
maxrank 0 //c:c 1 //b:b 2 //a:a 2 //b:b.cc 3 //a:a.cc |
Her hedefin konumunu yazdırma
--output location
label_kind
gibi bu seçenek de sonuçtaki her bir hedef için hedefin türünü ve etiketini yazdırır. Ancak bu seçenek, hedefin konumunu dosya adı ve satır numarası olarak açıklayan bir dizeyle öne çıkarılır. Biçim, grep
çıktısına benzemektedir. Böylece, ikincisini (Emacs veya vi gibi) ayrıştırabilen araçlar, bir dizi eşleşme arasında gezinmek için sorgu çıkışını da kullanabilir. Böylece, Bazel sorgu aracı, bağımlılık grafiğine duyarlı "BUILD dosyaları için grep" olarak kullanılabilir.
Konum bilgileri, hedef türüne göre değişiklik gösterir (tür operatörüne bakın). Kurallar için, kuralın BUILD
dosyasındaki beyanının konumu yazdırılır.
Kaynak dosyalar için asıl dosyanın 1. satırının konumu yazdırılır. Oluşturulan bir dosya için, dosyayı oluşturan kuralın konumu yazdırılır. (Sorgu aracı, oluşturulan dosyanın gerçek konumunu bulmak için yeterli bilgiye sahip değildir ve henüz derleme yapılmadıysa her durumda mevcut olmayabilir.)
Paket grubunu yazdırma
--output package
Bu seçenek, sonuç kümesinde bir hedefin ait olduğu tüm paketlerin adını yazdırır. Adlar sözlük sırasına göre yazdırılır; kopyalar hariç tutulur. Resmî olarak bu, etiket grubundan (paket, hedef) paketlere uygulanan bir projeksiyondur.
Harici depolardaki paketler @repo//foo/bar
olarak biçimlendirilirken ana depodaki paketler foo/bar
olarak biçimlendirilir.
deps(...)
sorgusuyla birlikte bu çıkış seçeneği, belirli bir hedef grubu oluşturmak için kontrol edilmesi gereken paket grubunu bulmak için kullanılabilir.
Sonucun grafiğini görüntüleme
--output graph
Bu seçenek, sorgu sonucunun popüler AT&T GraphViz biçiminde yönlendirilmiş bir grafik olarak yazdırılmasına neden olur. Sonuç genellikle .png
veya .svg
gibi bir dosyaya kaydedilir.
(dot
programı iş istasyonunuzda yüklü değilse sudo apt-get install graphviz
komutunu kullanarak yükleyebilirsiniz.) Örnek bir çağrı için aşağıdaki örnek bölümüne bakın.
Bu çıkış biçimi, özellikle --output label
gibi doğrusal bir biçimde oluşturulduğunda kolayca görselleştirilemeyen bir yol grubu içeren allpaths
, deps
veya rdeps
sorguları için kullanışlıdır.
Grafik varsayılan olarak çarpanı parantez dışına alınmış biçimde oluşturulur. Yani topolojik olarak eşdeğer olan düğümler, birden çok etikete sahip tek bir düğüm halinde birleştirilir. Tipik sonuç grafikleri yüksek oranda tekrar eden kalıplar içerdiğinden, grafiği daha küçük ve okunabilir hale getirir. Örneğin bir java_library
kuralı, tümü aynı genrule
tarafından oluşturulan yüzlerce Java kaynak dosyasına bağlı olabilir. Faktörlü grafikte bu dosyaların tamamı tek bir düğümle temsil edilir. Bu çalışma biçimi, --nograph:factored
seçeneği ile devre dışı bırakılabilir.
--graph:node_limit n
Bu seçenek, çıkıştaki bir grafik düğümü için etiket dizesinin maksimum uzunluğunu belirtir. Uzun etiketler kısaltılır; -1 değeri ise kısaltmayı devre dışı bırakır. Grafiklerin genellikle basıldığı faktörlü biçim nedeniyle düğüm etiketleri çok uzun olabilir. GraphViz, bu seçeneğin varsayılan değeri olan 1024 karakteri aşan etiketleri işleyemez. --output=graph
kullanılmadığı sürece bu seçeneğin hiçbir etkisi yoktur.
--[no]graph:factored
Varsayılan olarak grafikler, yukarıda açıklandığı gibi faktörlü biçimde gösterilir.
--nograph:factored
belirtildiğinde, grafikler dikkate alınmadan yazdırılır. Bu durum, GraphViz'i kullanarak görselleştirmeyi zorlaştırır ancak daha basit biçim, diğer araçlar (ör. grep) tarafından işlemeyi kolaylaştırabilir. --output=graph
kullanılmadığı sürece bu seçeneğin etkisi yoktur.
XML
--output xml
Bu seçenek, sonuçta elde edilen hedeflerin XML biçiminde yazdırılmasına neden olur. Çıkış şuna benzer bir XML üstbilgisiyle başlar:
<?xml version="1.0" encoding="UTF-8"?>
<query version="2">
ve ardından sonuç grafiğindeki her hedef için topolojik sırada (sıralı olmayan sonuçlar istenmediği sürece) bir XML öğesiyle devam eder ve ardından sonlandırıcı bir
</query>
Basit girişler file
türündeki hedefler için yayınlanır:
<source-file name='//foo:foo_main.cc' .../>
<generated-file name='//foo:libfoo.so' .../>
Ancak kurallar için XML yapılandırılır ve değerinin kuralın BUILD
dosyasında açıkça belirtilmediği özellikler de dahil olmak üzere kuralın tüm özelliklerinin tanımlarını içerir.
Ayrıca, sonuçta rule-input
ve rule-output
öğeleri bulunur. Böylece, bağımlılık grafiğinin topolojisi, örneğin srcs
özelliğinin öğelerinin ileriye dönük bağımlılıklar (önkoşullar) ve outs
özelliğinin içeriğinin geriye dönük bağımlılıklar (kullanıcı) olduğunu bilmek zorunda kalmadan yeniden oluşturulabilir.
--noimplicit_deps
belirtilirse örtülü bağımlılıklar için rule-input
öğeleri atlanır.
<rule class='cc_binary rule' name='//foo:foo' ...>
<list name='srcs'>
<label value='//foo:foo_main.cc'/>
<label value='//foo:bar.cc'/>
...
</list>
<list name='deps'>
<label value='//common:common'/>
<label value='//collections:collections'/>
...
</list>
<list name='data'>
...
</list>
<int name='linkstatic' value='0'/>
<int name='linkshared' value='0'/>
<list name='licenses'/>
<list name='distribs'>
<distribution value="INTERNAL" />
</list>
<rule-input name="//common:common" />
<rule-input name="//collections:collections" />
<rule-input name="//foo:foo_main.cc" />
<rule-input name="//foo:bar.cc" />
...
</rule>
Bir hedefin her XML öğesi, değeri hedefin etiketi olan bir name
özelliği ve değeri, --output location
tarafından yazdırılan hedef konumu olan bir location
özelliği içerir.
--[no]xml:line_numbers
XML çıkışında görüntülenen konumlar varsayılan olarak satır numaraları içerir.
--noxml:line_numbers
belirtildiğinde satır numaraları yazdırılmaz.
--[no]xml:default_values
XML çıkışı varsayılan olarak, değeri bu tür bir özellik için varsayılan değer olan kural özelliğini içermez (örneğin, BUILD
dosyasında belirtilmediyse veya varsayılan değer açıkça sağlandıysa). Bu seçenek, bu tür özellik değerlerinin XML çıkışına eklenmesine neden olur.
Normal ifadeler
Sorgu dilindeki normal ifadeler Java normal ifade kitaplığını kullanır. Bu nedenle, java.util.regex.Pattern
için tam söz dizimini kullanabilirsiniz.
Harici depolarla sorgulama
Derleme, harici depolardaki (WORKSPACE dosyasında tanımlanan) kurallara dayanıyorsa sorgu sonuçları bu bağımlılıkları içerir. Örneğin, //foo:bar
, //external:some-lib
'e bağlıysa ve //external:some-lib
, @other-repo//baz:lib
'ye bağlıysa bazel query 'deps(//foo:bar)'
, hem @other-repo//baz:lib
hem de //external:some-lib
'ü bağımlılık olarak listeler.
Harici depoların kendisi bir derlemenin bağımlılığı değildir. Yani yukarıdaki örnekte //external:other-repo
bir bağımlılık değildir. Ancak //external
paketinin bir üyesi olarak da sorgulanabilir. Örneğin:
# Querying over all members of //external returns the repository.
bazel query 'kind(http_archive, //external:*)'
//external:other-repo
# ...but the repository is not a dependency.
bazel query 'kind(http_archive, deps(//foo:bar))'
INFO: Empty results