Bu sayfa, derleme bağımlılıklarını analiz etmek için bazel query
kullandığınızda kullanılan Bazel Sorgu Dili için referans kılavuzudur. Makalede, bazel query
tarafından desteklenen çıkış biçimleri de açıklanmıştır.
Pratik kullanım örnekleri için Bazel Sorgusu Kullanımı bölümüne bakın.
Ek sorgu referansı
Bazel, yükleme sonrası aşama hedef grafiğinde çalışan query
uygulamasına ek olarak, işlem grafiği sorgusu ve yapılandırılabilir sorgu içerir.
Eylem grafiği sorgusu
İşlem grafiği sorgusu (aquery
) analiz sonrası Yapılandırılmış Hedef Grafiği üzerinde çalışır ve İşlemler, Yapılar ve bunların ilişkileri hakkında bilgi sunar. aquery
, Yapılandırılmış Hedef Grafiği'nden oluşturulan İşlemlerin/Yapıların özellikleriyle ilgileniyorsanız faydalıdır.
Örneğin, gerçek komutlar, bunların girişleri, çıkışları ve anımsatıcılar.
Daha fazla bilgi için sorgu referansı bölümüne bakın.
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ırma ve bunlarla ilişkili kavramlar hakkında herhangi bir kavramı yoktur. Özellikle select ifadelerini doğru şekilde çözümlemez ve bunun yerine olası tüm seçim çözünürlüklerini döndürür. Ancak yapılandırılabilir sorgu ortamı cquery
, yapılandırmaları düzgün bir şekilde işler ancak bu orijinal sorgunun tüm işlevlerini sunmaz.
Daha fazla bilgi için cquery referansı sayfasına bakın.
Örnekler
Kullanıcılar bazel query
ürününü nasıl kullanıyor? Tipik örnekler şunlardır:
//foo
ağacı neden //bar/baz
kaynağına bağlı?
Yol göster:
somepath(foo/..., //bar/baz:all)
Tüm foo
testleri hangi C++ kitaplıklarının foo_bin
hedefinin gerektirmediğine bağlı olur?
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:
let
gibi anahtar kelimeler. Anahtar kelimeler, ilgili dil için ayrılmış kelimelerdir. Her biri aşağıda açıklanmıştır. Tüm anahtar kelime takımı şudur:Kelimeler, örneğin "
foo/...
", ".*test rule
" veya "//bar/baz:all
". Bir karakter dizisi "tırnak içine alınmış" ise (tek tırnak " ile başlayıp biter veya çift tırnak " ile başlarsa " kelimedir. Bir karakter dizisi tırnak içine alınmamışsa yine de bir kelime olarak ayrıştırılabilir. Tırnaklanmamış kelimeler; A-Za-z alfabe karakterlerinden, 0-9 rakamlarından ve*/@.-_:$~[]
özel karakterlerinden (yıldız, öne eğik çizgi, at, nokta, tire, alt çizgi, iki nokta üst üste, dolar işareti, yaklaşık işareti, sol köşeli ayraç, sağ köşeli parantez) oluşturulan karakter dizileridir. Bununla birlikte, göreli hedef adları bu karakterlerle başlasa da tırnak içinde olmayan kelimeler kısa çizgi-
veya yıldız*
ile başlayamaz.Tırnak içinde olmayan kelimelerde, hedef adlarda bu karakterlere izin verilse bile, artı
+
karakteri veya=
ifadesine eşittir işareti kullanılamaz. Sorgu ifadeleri oluşturan kod yazarken 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ı yazılırken alıntı yapılması 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 alıntının, kabuğunuzun gerektirdiği alıntılara ek olarak yazıldığını unutmayın. Örneğin:
bazel query ' "//foo:bar=wiz" ' # single-quotes for shell, double-quotes for Bazel.
Anahtar kelimeler ve operatörler, alıntılandığında sıradan kelimeler olarak kabul edilir. Örneğin,
some
bir anahtar kelimedir ancak "bazı" kelimesi bir kelimedir. Hemfoo
hem de "foo" kelimedir.Ancak, hedef adlarda tek veya çift tırnak kullanırken dikkatli olun. Bir veya daha fazla hedef adından alıntı yaparken yalnızca tek bir tırnak türü (tümü tek veya tamamı çift tırnak) kullanın.
Aşağıda, Java sorgu dizesinin ne olacağına dair örnekler 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
Bu söz dizimini, çoğu durumda tırnak işaretlerine gerek kalmaması için seçtik. (Olağan dışı)
".*test rule"
örneği tırnak işareti gerektirir: Noktayla başlar ve boşluk içerir."cc_library"
alıntısı yapmak gereksizdir ancak zararsızdır.Noktalama; ör.
()
, nokta.
ve virgül,
. Noktalama işareti içeren kelimeler (yukarıda listelenen istisnalar dışında) tırnak içine alınmalıdır.
Tırnak içine alınmış bir kelimenin dışındaki boşluk karakterleri yok sayılır.
Bazel sorgu dili kavramları
Bazel sorgu dili, ifadelerin dilidir. Her ifade, kısmen sıralanmış bir hedefler grubu veya buna eşdeğer bir hedef grafiği (DAG) olarak değerlendirilir. Tek veri türü budur.
Küme ve grafik aynı veri türüne atıfta bulunuyor ama farklı yönlerini vurguluyor. Örneğin:
- Ayarlama: Hedeflerin kısmi sırası ilginç değildir.
- Grafik: Hedeflerin kısmi sırası önemlidir.
Bağımlılık grafiğindeki döngüler
Derleme bağımlılık grafikleri döngüsel olmalıdır.
Sorgu dili tarafından kullanılan algoritmalar, döngüsel grafiklerde kullanılmak üzere tasarlanmıştır ancak döngülere karşı dayanıklıdır. Döngülerin nasıl işlendiğine ilişkin ayrıntılar belirtilmemiştir ve bu ayrıntılara güvenilmemelidir.
Örtülü bağımlılıklar
Bazel, BUILD
dosyalarında açıkça tanımlanan bağımlılıklar oluşturmaya ek olarak kurallara ek dolaylı bağımlılıklar ekler. Örtülü bağımlılıklar
şu şekilde tanımlanabilir:
Varsayılan olarak bazel query
, sorgu sonucunu hesaplarken örtülü bağımlılıkları dikkate alır. Bu davranış --[no]implicit_deps
seçeneğiyle değiştirilebilir.
Sorgu, yapılandırmaları dikkate almadığından potansiyel araç zinciri uygulamalarının bağımlılık olarak değil, yalnızca gerekli araç zinciri türleri olarak kabul edildiğini unutmayın. Araç zinciri belgelerini inceleyin.
Sağlamlık
Bazel sorgu dili ifadeleri, tüm BUILD
dosyalarındaki tüm kural bildirimleri tarafından dolaylı olarak tanımlanan derleme bağımlılığı grafiği üzerinde çalışır. Bu grafiğin biraz soyut olduğunu ve bir derlemenin tüm adımlarının nasıl gerçekleştirileceğine dair tam bir açıklama teşkil etmediğini anlamak önemlidir. Derleme gerçekleştirmek için bir yapılandırma da gereklidir. Daha fazla ayrıntı için Kullanıcı Kılavuzu'nun yapılandırmalar bölümüne bakın.
Bir ifadenin Bazel sorgu dilindeki değerlendirilmesinin sonucu tüm yapılandırmalar için doğrudur. Bu, tam olarak kesin olmayan ve konservatif bir aşırı yaklaşık tahmin olabileceği anlamına gelir. Sorgu aracını bir derleme sırasında gereken tüm kaynak dosya kümesini hesaplamak için kullanırsanız gerçekte gerekenden fazlasını raporlayabilir. Bunun nedeni, örneğin sorgu aracı, derlemenizde bu özelliği kullanmak istemeseniz bile mesaj çevirisini desteklemek için gereken tüm dosyaları içermesidir.
Grafik düzeninin 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 örneği düşünün: Belirli bir hedefin bağımlılıklarının geçişli olarak kapanmasını belirlemek için bir sorgu yayınlarsanız sonuç kümesi bağımlılık grafiğine göre sıralanır. Yalnızca file
türündeki hedefleri içerecek şekilde ayarlanan filtre uygularsanız ortaya çıkan alt kümedeki her hedef çifti arasında aynı geçişli kısmi sıralama ilişkisi korunur (bu çiftlerin hiçbiri orijinal grafikte doğrudan bağlı olmasa bile).
(Derleme bağımlılık grafiğinde dosya-dosya kenarı yoktur).
Bununla birlikte, tüm operatörler sırayı korusa da set işlemleri gibi bazı işlemler kendi sıralama kısıtlamalarını satmaz. Şu ifadeyi ele alalım:
deps(x) union y
Nihai sonuç kümesinin sırası, alt ifadelerinin tüm sıralama kısıtlamalarının korunacağı, diğer bir deyişle x
tüm geçişli bağımlılıklarının birbirine göre doğru şekilde sıralanacağı garanti edilir. Ancak sorgu, y
konumundaki hedeflerin sıralamasıyla ilgili veya deps(x)
konumundaki hedeflerin y
içindekilere göre sıralamasıyla ilgili hiçbir şey garanti etmez (y
içinde ve deps(x)
içinde olan hedefler hariç).
Sıralama kısıtlamalarına neden olan operatörler şunlardır: allpaths
, deps
, rdeps
, somepath
ve hedef kalıp joker karakterleri package:*
, dir/...
vb.
Gökyüzü sorgusu
Gökyüzü Sorgusu, belirli 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 evrenin kapsamı üzerinde çalışır (bu nedenle normal Sorgu için anlamlı değildir).
Evren kapsamı belirleme
Gökyüzü Sorgusu modu, şu iki işaret geçirilerek 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 kapanmasını önceden yüklemesini belirtir. Bu, hem toplama hem de çıkarma olabilir. Daha sonra tüm sorgular bu "kapsamda" değerlendirilir. Özellikle allrdeps
ve rbuildfiles
operatörleri yalnızca bu kapsamdan 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"]
olduğundan, Bazel bunu çağrıyla aynı şekilde ele alır:
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
özelliğinin ters bağımlılıklarının hiçbiri, yapı gereği evrende değildir. Öte yandan şunları 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, tanımı belirli bir .bzl
dosyası kullanan hedeflere geçişli olarak bağlı bazı dizinler altındaki hedeflerin tests
genişletmesindeki test hedeflerini hesaplamaya çalışan anlamlı bir sorgu çağrısıdır. Burada --infer_universe_scope
, özellikle --universe_scope
seçiminin sorgu ifadesini sizin ayrıştırmanızı gerektirdiği durumlarda kolaylık sağlar.
Bu nedenle, allrdeps
ve rbuildfiles
gibi evren kapsamlı operatörleri kullanan sorgu ifadeleri için --infer_universe_scope
işlevini yalnızca davranışının istediğiniz gibi olması durumunda kullanın.
Sky Query'nin, varsayılan sorguya göre bazı avantajları ve dezavantajları vardır. Başlıca dezavantajı, çıktısını grafik sırasına göre sıralayamaması ve bu nedenle belirli çıktı biçimlerinin yasaklanmasıdır. Avantajı, varsayılan sorguda bulunmayan iki operatör (allrdeps
ve rbuildfiles
) sağlamasıdır.
Ayrıca Sky Query, yeni bir grafik oluşturmak yerine, varsayılan olarak Skyframe grafiğini inceleyerek çalışır. Bu nedenle, daha hızlı olduğu ve daha az bellek kullandığı bazı durumlar vardır.
İfadeler: Dilbilgisinin söz dizimi ve anlamları
Bu, EBNF gösterimiyle ifade edilen Bazel sorgu dilinin dil bilgisidir:
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 gramerin her bir üretimi sırayla açıklanmaktadır.
Hedef kalıpları
expr ::= word
Sözdizimsel olarak, hedef kalıp yalnızca bir kelimeden oluşur. Bir dizi (sırasız)
hedefler 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 üzerinde joker karakterler eklemek için etiketleri genelleştirir. Örneğin, foo/...:all
(veya yalnızca foo/...
), foo
dizininin altında bulunan ve her paketteki tüm kuralları içeren bir kümeyi tekrarlayan bir şekilde değerlendiren bir hedef kalıptır. bar/baz:all
, bar/baz
paketindeki tüm kuralları içeren bir küme olarak değerlendirme yapan ancak alt paketlerini içermeyen bir kümedir.
Benzer şekilde foo/...:*
, foo
dizininin altında bulunan her paketteki tüm hedefleri (kurallar ve dosyaları) tekrarlayan bir şekilde bir küme olarak değerlendirme yapan bir hedef kalıbıdır. bar/baz:*
, bar/baz
paketindeki tüm hedefleri içeren, ancak alt paketlerini içeren bir küme olarak değerlendirme yapar.
:*
joker karakteri hem kurallar hem de dosyalarla 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ıplarında gizlidir) genellikle derlemeler için daha yararlıdır.
bazel query
hedef kalıbı, bazel build
derleme hedefleriyle aynı şekilde çalışır. Daha fazla bilgi için Hedef Kalıpları başlıklı makaleyi inceleyin veya bazel help target-syntax
yazın.
Hedef kalıpları, bir tekil küme (etikette), birçok öğe içeren bir küme (binlerce öğeye sahip foo/...
örneğinde olduğu gibi) veya hedef kalıbı hiçbir hedefle eşleşmediğinde boş küme olarak değerlendirilebilir.
Bir hedef kalıbı ifadesi sonucunda ortaya çıkan tüm düğümler, bağımlılık ilişkisine göre birbirine göre doğru şekilde sıralanır. Dolayısıyla, foo:*
sonucu, yalnızca foo
paketindeki hedefler grubundan ibaret değildir. Aynı zamanda bu hedefler üzerinde yer alan bir grafik de oluşturur. (Sonuç düğümlerinin diğer düğümlere göre göreli sıralamasıyla ilgili herhangi bir garanti verilmez.) Daha ayrıntılı 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. let
ifadesinin değerlendirilmesinin sonucu expr2 ile aynıdır ancak name değişkeninin tüm serbest oluşumları expr1 değeriyle değiştirilir.
Örneğin, let v = foo/... in allpaths($v, //common) intersect $v
, allpaths(foo/...,//common) intersect foo/...
ile eşdeğerdir.
Çevreleyen let name = ...
ifadesi dışında bir değişken referansı name
olması hatadır. Diğer bir deyişle, üst düzey sorgu ifadelerinin serbest değişkenleri olamaz.
Yukarıdaki dil bilgisi üretimlerinde name
, word gibidir ancak C programlama dilinde yasal tanımlayıcı olması gibi bir ek kısıtlama sahiptir. Değişken referanslarının başında "$" karakteri bulunmalıdır.
Her let
ifadesi yalnızca tek bir değişken tanımlar ancak bunları iç içe yerleştirebilirsiniz.
Hem hedef kalıplar hem de değişken referansları tek bir jeton veya kelimeden oluşur ve söz dizimi belirsizliği oluşturur. Bununla birlikte, herhangi bir anlam belirsizliği yoktur, çünkü yasal değişken adı olan kelimelerin alt kümesi, yasal hedef kalıpları olan kelime alt kümesinden ayrıdır.
Teknik açıdan konuşmak gerekirse let
ifadeleri, sorgu dilinin ifade gücünü artırmaz. Söz konusu dilde ifade edilebilen sorgular, bunlar olmadan da ifade edilebilir. Ancak bu yöntem, birçok sorgunun daha kısa ve öz olmasını sağlar ve sorgu değerlendirmesinin daha verimli olmasını sağlayabilir.
Parantez içindeki ifadeler
expr ::= (expr)
Parantezler bir değerlendirme sırasını zorlamak için alt ifadeleri ilişkilendirir. Parantez içindeki ifadeler, kendi bağımsız değişkeninin değerini belirler.
Cebirsel küme işlemleri: kesişim, bütünleşme, farkı ayarlama
expr ::= expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
Bu üç operatör, olağan set işlemlerini kendi bağımsız değişkenleri üzerinden hesaplar.
Her bir operatörün, intersect
gibi nominal bir biçim ve ^
gibi sembolik bir biçim olmak üzere iki biçimi vardır. 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 biçimler kullanılmıştır.)
Örneğin,
foo/... except foo/bar/...
foo/...
ile eşleşen, ancak foo/bar/...
ile eşleşmeyen hedef grubunu değerlendirir.
Aynı sorguyu şu şekilde yazabilirsiniz:
foo/... - foo/bar/...
intersect
(^
) ve union
(+
) işlemleri değişimli (simetrik) olup except
(-
) asimetriktir. Ayrıştırıcı, üç operatörün tümünü sol ilişkilendirici ve eşit önceliğe sahip olarak ele alır. Bu nedenle parantez kullanmak isteyebilirsiniz. Örneğin, bu ifadelerden ilk ikisi eşdeğerdir, ancak üçüncüsü eşdeğer değildir:
x intersect y union z
(x intersect y) union z
x intersect (y union z)
Harici kaynaktan okuma hedefleri: ayarlayın
expr ::= set(word *)
set(a b c ...)
operatörü, boşlukla (virgül kullanmadan) ayrılmış sıfır veya daha fazla hedef kalıbı grubunun birleşimini hesaplar.
Bourne kabuğunun $(...)
özelliğiyle birlikte set()
, bir sorgunun sonuçlarını normal bir metin dosyasında kaydetme, bu metin dosyasını diğer programları (standart UNIX kabuk araçları gibi) kullanarak değiştirme ve daha sonra, sonucu daha ileri işlem için bir değer olarak sorgu aracına tekrar sunma yöntemi sağlar. Örneğin:
bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"
Sonraki örnekte kind(cc_library, deps(//some_dir/foo:main, 5))
,bir awk
programı kullanılarak maxrank
değerlerine göre filtrelenerek hesaplanı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)
için bir kısaltmadır ancak önceki awk
komutu gibi cat
dışındaki kabuk komutları da kullanılabilir.
İşlevler
expr ::= word '(' int | word | expr ... ')'
Sorgu dili birkaç işlev tanımlar. İşlevin adı, işlevin 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çici olarak kapatılması: 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ının oluşturduğu grafiği değerlendirir. Örneğin, deps(//foo)
değeri, tüm bağımlılıkları dahil olmak üzere foo
adlı tek düğümde kökü bulunan bağımlılık grafiğidir. deps(foo/...)
değeri, foo
dizininin altındaki her pakette kökleri tüm kurallardan oluşan 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ı burada yer almamıştır. Bunun için buildfiles
operatörünü kullanmanız gerekir.
Elde edilen grafik, bağımlılık ilişkisine göre sıralanır. Daha fazla 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şkeni kabul eder. Bu bağımsız değişken, aramanın derinliğine ilişkin bir üst sınırı belirten bir tam sayıdır. Dolayısıyla, deps(foo:*, 0)
, foo
paketindeki tüm hedefleri döndürürken deps(foo:*, 1)
, foo
paketindeki herhangi bir hedefin doğrudan ön koşullarını içerir ve deps(foo:*, 2)
, deps(foo:*, 1)
içindeki düğümlerden doğrudan erişilebilen düğümleri de içerir ve bu şekilde devam eder. (Bu sayılar, minrank
çıktı biçiminde gösterilen sıralamalara karşılık gelir.)
depth parametresi atlanırsa arama sınırsız olur: Ön koşulların yansıtmalı geçişli kapanmasını hesaplar.
Ters bağımlılıkların geçici olarak kapatılması: rdeps
expr ::= rdeps(expr, expr)
| rdeps(expr, expr, depth)
rdeps(u, x)
operatörü, u evren kümesinin geçişli kapanması dahilinde x bağımsız değişkeni grubunun ters bağımlılıklarını değerlendirir.
Elde edilen grafik, bağımlılık ilişkisine göre sıralanır. Daha fazla ayrıntı için grafik sırası ile ilgili bölüme bakın.
rdeps
operatörü, isteğe bağlı üçüncü bir bağımsız değişkeni kabul eder. Bu bağımsız değişken, aramanın derinliğine ilişkin bir üst sınırı belirten bir tam sayıdır. Ortaya çıkan grafik, yalnızca bağımsız değişken grubundaki herhangi bir düğümden belirtilen derinlik mesafesi dahilinde olan düğümleri içerir. Dolayısıyla rdeps(//foo, //common, 1)
, //foo
'nin geçişli kapanmasında doğrudan //common
öğesine bağlı olan 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ız olur.
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ü ile aynı şekilde davranır ancak "evren grubu", --universe_scope
işaretinin değerlendirildiği değerdir ve ayrı olarak belirtilmez. Dolayısıyla, --universe_scope=//foo/...
iletildiyse allrdeps(//bar)
, rdeps(//foo/..., //bar)
ile eşdeğerdir.
Aynı pakette doğrudan ters bağımlılıklar: same_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 olan ve doğrudan buna bağımlı olan hedeflerin tamamını değerlendirir.
Bir hedefin paketiyle ilgilenme: kardeşler
expr ::= siblings(expr)
siblings(x)
operatörü, bağımsız değişken kümesindeki bir hedef olarak aynı paketteki hedeflerin tamamını değerlendirir.
Rastgele seçim: bazı
expr ::= some(expr)
| some(expr, count )
some(x, k)
operatörü, x bağımsız değişken kümesinden rastgele en fazla k hedef seçer ve yalnızca bu hedefleri içeren bir küme olarak değerlendirme yapar. k parametresi isteğe bağlıdır. Eksikse sonuç, rastgele seçilen yalnızca bir hedef içeren bir tekil küme olur. x bağımsız değişken grubunun boyutu k değerinden küçükse x bağımsız değişken grubunun tamamı döndürülür.
Örneğin, some(//foo:main union //bar:baz)
ifadesi, //foo:main
veya //bar:baz
içeren bir tekil küme olarak değerlendirilir (ancak bu değerler 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 bir tekilleştirilmişse some
, kimlik işlevini hesaplar: some(//foo:main)
, //foo:main
değerine eşdeğerdir.
some(//foo:main intersect //bar:baz)
ifadesinde olduğu gibi, belirtilen bağımsız değişken grubu boşsa bu bir hatadır.
Yol operatörleri: somepath, allpaths
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 sorguda da S başlangıç noktası ve E bitiş noktası olmak üzere iki bağımsız değişken kabul edilir. somepath
, S bölgesindeki bir hedeften E bölgesindeki bir hedefe bazı rastgele bir yoldaki düğümlerin grafiğini döndürür. allpaths
, S bölgesindeki herhangi bir hedeften gelen tüm yollardaki düğümler grafiğini E içindeki herhangi bir hedefe döndürür.
Ortaya çıkan grafikler bağımlılık ilişkisine göre sıralanır. Daha fazla ayrıntı için grafik sırası ile ilgili bölüme bakın.
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 atar. pattern parametresi, ne tür bir hedefin eşleneceğini belirtir.
Örneğin, aşağıda gösterilen BUILD
dosyası tarafından tanımlanan dört hedefin (p
paketi için) türleri tabloda gösterilmektedir:
Kod | Hedef | Tür |
---|---|---|
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", ) |
//p:a |
genrule 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ın geçişli olarak kapanmasındaki tüm kaynak dosyaları kümesini değerlendirir.
pattern bağımsız değişkeninin tırnak içine alınması genellikle gereklidir. Çünkü bu bağımsız değişken olmadan source
file
ve .*_test
gibi birçok normal ifade ayrıştırıcı tarafından kelime olarak kabul edilmez.
package group
ile biten hedeflerken, :all
ile biten hedefler 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 atar; girdilerinin bir alt kümesini değerlendirir.
Birinci bağımsız değişken olan pattern, hedef adlar üzerinde normal ifade içeren bir kelimedir. Bir filter
ifadesi, x tüm hedeflerini içeren küme olarak değerlendirilir. Bu durumda x, input kümesinin üyesidir ve x etiketi (mutlak biçimde //foo:bar
gibi) pattern normal ifadesi için (bağlanmamış) bir eşleşme içerir. Tüm hedef adları //
ile başladığından ^
normal ifade bağlantısı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 sağlar. Örneğin, //foo:foo
hedefinin tüm bar
bağımlılıklarını görmek için,
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ş ve alakasız BUILD
dosyalarında hatalara neden olabilir. Bunun bir alternatifi şöyle olabilir:
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ı //bar
alt dize olarak içeren hedefleri filtreler.
filter(pattern,
expr)
operatörünün yaygın bir diğer kullanımı da 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 bir listesini sağlayacak.
Kural özelliği filtreleme: attr
expr ::= attr(word, word, expr)
attr(name, pattern, input)
operatörü, bir hedef grubuna filtre uygular ve kural olmayan hedefleri, name özelliğinin tanımlı olmayan kural hedeflerini veya özellik değerinin sağlanan normal ifadeyle pattern eşleşmediği kural hedeflerini atar ve girdilerinin 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 olan pattern, özellik değerlerine göre normal bir ifadedir. Bir attr
ifadesi, tüm hedefleri içeren x kümesini içeren küme olarak değerlendirilir. Burada x
input kümesinin üyesidir, name
özelliğine sahip bir kuraldır ve özellik değeri,
pattern normal ifadesi için (bağlanmamış) eşleşme içerir. name isteğe bağlı bir özellikse ve kural bunu açık bir şekilde belirtmiyorsa karşılaştırma için varsayılan özellik değeri kullanılır. Örneğin,
attr(linkshared, 0, deps(//foo))
bir linkshared özelliğine (cc_binary
kuralı gibi) izin verilen tüm //foo
bağımlılıklarını seçer ve açık bir şekilde 0'a ayarlanır veya varsayılan değer 0 dışında hiç ayarlamaz (ör. cc_binary
kurallarında).
Liste türü özellikler (ör. srcs
, data
vb.) [
ayracı ile başlayıp ]
paranteziyle biten ve birden çok değeri sınırlamak için ",
" (virgül, boşluk) kullanılarak [value<sub>1</sub>, ..., value<sub>n</sub>]
biçiminde dizelere dönüştürülür.
Etiketler, etiketin mutlak biçimi kullanılarak dizelere dönüştürülür. Örneğin, bir 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ıklar
arasından tüm kuralları seçer,
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).
Bir liste türü özelliğinde belirli bir value
içeren //foo
bağımlılıkları arasından tüm kuralları seçmek için
attr("tags", "[\[ ]value[,\]]", deps(//foo))
Bu yöntem, value
öncesindeki karakter [
veya bir boşluk, value
sonrasındaki karakter ise virgül ya da ]
olacağı için çalışır.
Kural görünürlüğü filtreleme: görünür
expr ::= visible(expr, expr)
visible(predicate, input)
operatörü, bir hedef grubuna filtre uygular ve gerekli görünürlüğe sahip olmayan hedefleri siler.
İlk bağımsız değişken olan predicate, çıkıştaki tüm hedeflerin görünür olması gereken bir hedef kümesidir. Bir visible ifadesi, x adlı tüm hedefleri içeren küme olarak değerlendirilir. Bu şekilde x, input kümesinin bir üyesi olur ve x predicate içindeki tüm y hedefleri y tarafından görülebilir. Örneğin:
visible(//foo, //bar:*)
görünürlük kısıtlamalarını ihlal etmeden //bar
paketindeki //foo
ürününün 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 bazı kurallarda "label" 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 grubunu döndürür. Ayarlanan inputs öğesinde srcs
özelliklerine sahip birden fazla kural varsa srcs
özelliklerinin birleşimi döndürülür.
test_suites: testlerini genişletme ve 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şvuruda bulundukları bağımsız test grubuna genişletir ve tag
ile size
ölçütüne göre filtreleme uygular.
Varsayılan olarak, sorgu değerlendirmesi tüm test_suite
kurallarındaki test dışı hedefleri yoksayar. Bu değer, --strict_test_suite
seçeneği kullanılarak 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 olarak) foo
paketinin üyeleridir. Öte yandan, tests(foo:*)
sorgusu, bazel test
foo:*
tarafından yürütülecek tüm bağımsız testleri döndürür: Buna, test_suite
kuralları aracılığıyla doğrudan veya dolaylı olarak başvurulan diğer paketlere ait testler de dahil olabilir.
Paket tanımı dosyaları: buildfiles
expr ::= buildfiles(expr)
buildfiles(x)
operatörü, x kümesindeki her bir hedefin paketlerini tanımlayan dosya grubunu döndürür. Diğer bir deyişle, her paket için BUILD
dosyasını ve load
aracılığıyla referans verdiği .bzl dosyalarını döndürür. Bunun, load
oluşturulan dosyaları içeren paketlerin BUILD
dosyalarını da döndürdüğünü unutmayın.
Bu operatör, genellikle belirli bir hedef oluşturmak için hangi dosyaların veya paketlerin gerekli olduğunu belirlerken kullanılır. Bu yöntem, çoğu zaman 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ğımlı olduğu tüm paketlerin kümesini 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ı olan 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 BUILD
dosyalarının hedeflerini döndürür
--universe_scope
işaretiyle belirtilen evrendir. BUILD
ve .bzl
dosyalarına doğrudan karşılık gelmeyen dosyalar sonuçları etkilemez. Örneğin, kaynak dosyalar (foo.cc
gibi) BUILD
dosyasında açıkça belirtilse bile yoksayılır. Ancak sembolik bağlantılara riayet edilir. Yani foo/BUILD
, bar/BUILD
için kullanılan bir sembolik bağlantıysa rbuildfiles(bar/BUILD)
, sonuçlarına //foo:BUILD
ifadesini ekler.
rbuildfiles
operatörü, ahlaki açıdan buildfiles
operatörünün tam tersidir. Bununla birlikte, bu ahlaki tersine çevirme, tek bir yönde daha güçlüdür: rbuildfiles
çıktıları, buildfiles
girdileri gibidir; ilki, paketlerde yalnızca BUILD
dosya hedeflerini içerir ve ikincisi, bu tür hedefleri içerebilir. Diğer yönde, yazışma daha zayıftır. buildfiles
operatörünün çıkışları, tüm paketlere ve .bzl
dosya gerektirir. 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ümesindeki her bir hedefin paketlerini yüklemek için gereken Starlark dosya grubunu döndürür. Diğer bir deyişle, her paket için BUILD
dosyalarından başvurulan.bzl dosyalarını döndürür.
Çıkış biçimleri
bazel query
bir grafik oluşturur.
bazel query
ürününün bu grafiği sunduğu içeriği, biçimi ve sıralamayı --output
komut satırı seçeneği aracılığıyla belirtirsiniz.
Sky Query ile çalışırken, yalnızca sıralanmamış çıkışla uyumlu çıkış biçimlerine izin verilir. Özellikle graph
, minrank
ve maxrank
çıkış biçimleri yasaktır.
Bazı çıkış biçimleri ek seçenekleri kabul eder. Her bir çıkış seçeneğinin adının önüne, geçerli olduğu çıkış biçimi eklenir. Bu nedenle --graph:factored
, yalnızca --output=graph
kullanılırken geçerli olur. graph
dışında bir çıkış biçimi kullanıldığında herhangi bir etkisi olmaz. Benzer şekilde --xml:line_numbers
, yalnızca --output=xml
kullanılırken geçerlidir.
Sonuçların sıralamasında
Sorgu ifadeleri her zaman "grafik sırasının korunumu yasası"na uygun olsa da, sonuçların sunulması bağımlılık sıralı veya sırasız bir şekilde yapılabilir. Bu, sonuç kümesindeki hedefleri veya sorgunun nasıl hesaplandığını etkilemez. Yalnızca sonuçların Stdout'a nasıl yazdırılacağını etkiler. Ayrıca, bağımlılık sırasına eş değer olan düğümler alfabetik olarak sıralanabilir veya sıralanmayabilir.
--order_output
işareti, bu davranışı kontrol etmek için kullanılabilir.
(--[no]order_results
işareti, --order_output
işaretinin işlevlerinin bir alt kümesine sahiptir ve kullanımdan kaldırılmıştır.)
Bu işaretin varsayılan değeri auto
olup sonuçları sözlüğe göre sıraya göre yazdırır. Ancak somepath(a,b)
kullanıldığında sonuçlar deps
sırasına göre yazdırılır.
Bu işaret no
ve --output
işareti build
, label
, label_kind
, location
, package
, proto
veyaxml
olduğunda çıktılar rastgele sırayla yazdırılır. Bu genellikle en hızlı seçenektir. Ancak --output
; graph
, minrank
veya maxrank
değerlerinden biri olduğunda desteklenmez: Bu biçimlerde Bazel her zaman sonuçları bağımlılık sırasına veya sıralamasına göre sıralar.
Bu işaret deps
olduğunda Bazel baskıları bir topolojik sıralamayla (önce bağımlılar, sonrasında bağımlılıklar) sonuç getirir. Bununla birlikte, bağımlılık sırasına göre sırası olmayan düğümler (ikisinden diğerine yol olmadığından) herhangi bir sırada yazdırılabilir.
Bu işaret full
olduğunda Bazel, düğümleri tamamen belirleyici (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 ardışık düğümlerin alfabetik sırasına göre geçtiği bir post-order (derinlik) öncelikli aramanın başlangıcı olarak kullanılır. Son olarak, düğümler ziyaret edildiklerinin
tersine yazdırılır.
Bu sıradaki düğümleri yazdırma daha yavaş olabilir. Bu nedenle, yalnızca determinizm önemli olduğunda kullanılmalıdır.
Hedeflerin kaynak biçimini, BUILD aracında görünecekleri şekilde yazdırın
--output build
Bu seçenekte, her hedefin temsili BUILD dilinde elle yazılmış gibi olur. Tüm değişkenler ve işlev çağrıları (glob, makrolar gibi) genişletildiğinden, Starlark makrolarının etkisini görebilirsiniz. Buna ek olarak, her bir geçerli kural, geçerli kuralı oluşturmak için değerlendirilen makronun adını vererek bir generator_name
ve/veya generator_function
değeri bildirir.
Çıkış, BUILD
dosyalarıyla aynı söz dizimini kullansa da geçerli bir BUILD
dosyası üretileceği garanti edilmez.
Her bir hedefin etiketini yazdır
--output label
Bu seçenekte, elde edilen grafikteki her bir hedefin ad grubu (veya etiketleri) topolojik sırada, her satırda bir etiket olacak şekilde yazdırılır (--noorder_results
belirtilmemişse sonuçların sıralamasıyla ilgili notlara bakın).
(Topolojik sıralama, bir grafik düğümünün sonraki tüm sıralarından önce göründüğü sıralamadır.) Elbette bir grafiğin pek çok olası topolojik sıralaması vardır (ters postorder yalnızca bir tanedir); hangi sıralamanın seçileceği belirtilmemiştir.
Bir somepath
sorgusunun çıkışını yazdırırken, düğümlerin yazdırılma sırası yolun sırasıdır.
Uyarı: Bazı durumlarda, aynı etikete sahip iki ayrı hedef olabilir. Örneğin, sh_binary
kuralı ve tek (dolaylı) srcs
dosyası foo.sh
olarak adlandırılabilir. Sorgu sonucu bu hedeflerin her ikisini de içeriyorsa çıkış (label
biçiminde) yinelenen bir sonuç içeriyormuş gibi görünür. label_kind
(aşağıya bakın) biçimi kullanıldığında, aradaki fark nettir: İki hedef aynı ada sahipken bir hedef sh_binary rule
türüne ve source file
türüne sahiptir.
Her hedefin etiketini ve türünü yazdırın
--output label_kind
label
gibi, bu çıktı biçimi de sonuçta ortaya çıkan grafikteki her bir hedefin etiketlerini topolojik sırada yazdırır, ancak ek olarak etiketin önüne hedefin tür etiketinden önce gelir.
Hedefleri protokol arabelleği biçiminde yazdır
--output proto
Sorgu çıktısını QueryResult
protokol arabelleği olarak yazdırır.
Hedefleri uzunlukla ayrılmış protokol arabelleği biçiminde yazdır
--output streamed_proto
Target
protokol arabellekleri için uzunlukla sınırlandırılmış bir akış yazdırır. Bu, (i) tek bir QueryResult
'a sığmayacak kadar çok hedef olduğunda protokol arabelleklerinin boyut sınırlamalarını atlatmak veya (ii) Bazel hâlâ çıkış yaparken işlemeye başlanması için (ii) faydalıdır.
Hedefleri metin protokolü biçiminde yazdır
--output textproto
--output proto
operatörüne 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 arabellekleri akışını, ancak ndjson biçiminde yazdırır.
Her hedefin etiketini sıralama sırasına göre yazdırın
--output minrank --output maxrank
label
gibi, minrank
ve maxrank
çıkış biçimleri de ortaya çıkan grafikte her bir hedefin etiketlerini yazdırır, ancak bunlar topolojik sırada görünmek yerine, sıra numarasından önce sıralı olarak gösterilir. Bunlar, sonuç sıralaması --[no]order_results
işaretinden etkilenmez (sonuçların sıralamasıyla ilgili notlar).
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. sırada, takipçileri 1. sıradadır. (Her zaman olduğu gibi, kenarlar hedeften önkoşullarına, yani bağlı olduğu hedeflere işaret eder.)
maxrank
, her düğümü bir kök düğümden kendisine giden en uzun yolun uzunluğuna göre sıralar. "Köklerin" sıralaması 0, diğer tüm düğümlerin sıralaması ise önceki tüm düğümlerinin maksimum sıralamasından bir daha yüksektir.
Bir döngüdeki tüm düğümlerin sıralaması eşit olarak kabul edilir. (Çoğu grafik döngüseldir ancak BUILD
dosyaları hatalı döngüler içerdiği için döngüler basitçe gerçekleşir.)
Bu çıkış biçimleri, bir grafiğin ne kadar derin olduğunun keşfedilmesinde yararlıdır. Bir deps(x)
, rdeps(x)
veya allpaths
sorgusu sonucu için kullanılırsa sıralama numarası, x
ile ilgili düğümden ilgili düğüme kadar olan en kısa (minrank
ile) veya en uzun (maxrank
ile) yolun uzunluğuna eşit olur. maxrank
, bir hedef oluşturmak için gereken en uzun derleme adımı sırasını belirlemek amacıyla kullanılabilir.
Örneğin, soldaki grafik sırasıyla --output minrank
ve --output maxrank
belirtildiğinde sağdaki çıktıları verir.
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 bir hedefin konumunu yazdır
--output location
label_kind
işlevinde olduğu gibi, bu seçenek de sonuçtaki her hedef için hedefin türünü ve etiketini yazdırır ancak ön ek olarak söz konusu hedefin konumunu bir dosya adı ve satır numarası olarak açıklayan bir dize bulunur. Biçim, grep
çıkışına benzemektedir. Bu nedenle, ikinci aracı ayrıştırabilen araçlar (Emacs veya vi gibi) sorgu çıkışını bir dizi eşleşmeyi adım adım görmek için de kullanabilir. Böylece, Bazel sorgu aracı, bağımlılık-grafiğe duyarlı bir "DERLEME dosyaları için grep" olarak kullanılabilir.
Konum bilgileri hedef türe göre değişir (tür operatörüne bakın). Kurallar söz konusu olduğunda, kural bildiriminin BUILD
dosyası içindeki konumu yazdırılır.
Kaynak dosyalarda, gerçek dosyanın 1. satırının konumu yazdırılır. Oluşturulan bir 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 bir derleme gerçekleştirilmediyse her durumda söz konusu dosya mevcut olmayabilir.)
Paket grubunu yazdır
--output package
Bu seçenek, sonuç kümesindeki bazı hedeflerin ait olduğu tüm paketlerin adını yazdırır. Adlar sözlük sıralamasına göre yazdırılır; kopyalar hariç tutulur. Resmi olarak bu, etiket grubundan (paket, hedef) paketlere yapılan bir projeksiyondur.
Harici depolardaki paketler @repo//foo/bar
, ana depodaki paketler ise foo/bar
olarak biçimlendirilir.
Bu çıkış seçeneği, deps(...)
sorgusu ile birlikte belirli bir hedef kümesinin oluşturulması için kontrol edilmesi gereken paket kümesini bulmak amacıyla kullanılabilir.
Sonucun grafiğini görüntüleme
--output graph
Bu seçenek, sorgu sonucunun popüler AT&T GraphViz biçiminde yönlendirilen grafik olarak yazdırılmasına neden olur. Genellikle sonuç .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 allpaths
, deps
veya rdeps
sorguları için kullanışlıdır. Sonuçta, --output label
gibi doğrusal bir biçimde oluşturulduktan sonra kolayca görselleştirilemeyen bir yol grubu bulunur.
Grafik, varsayılan olarak faktörlü biçimde oluşturulur. Yani topolojik olarak eşdeğer düğümler birden fazla etikete sahip tek bir düğümde birleştirilir. Tipik sonuç grafikleri çok tekrar eden kalıplar içerdiğinden, bu işlem grafiği daha kompakt 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, tüm bu dosyalar tek bir düğümle gösterilir. Bu davranış, --nograph:factored
seçeneğiyle 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. Daha uzun etiketler kısaltılır; -1 değeri kısaltmayı devre dışı bırakır. Grafiklerin genellikle yazdırıldığı dikkate alınan 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ılmıyorsa bu seçeneğin hiçbir etkisi yoktur.
--[no]graph:factored
Grafikler, varsayılan olarak yukarıda açıklandığı gibi çarpanlara ayrılmış biçimde görüntülenir.
--nograph:factored
belirtildiğinde grafikler çarpanlara ayırmadan yazdırılır. Bu, GraphViz kullanarak görselleştirmeyi pratik hale getirir ancak daha basit biçim, diğer araçlar (grep gibi) tarafından işlemeyi kolaylaştırabilir. --output=graph
kullanılmıyorsa bu seçeneğin etkisi yoktur.
XML
--output xml
Bu seçenek, sonuç olarak elde edilen hedeflerin XML biçiminde yazdırılmasına neden olur. Çıkış şunun gibi bir XML üstbilgisiyle başlar:
<?xml version="1.0" encoding="UTF-8"?>
<query version="2">
ve daha sonra, sonuç grafiğindeki her hedef için topolojik sırada bir XML öğesiyle devam eder (sırasız sonuçlar istenmediği sürece) ve ardından bir sonlandırma
</query>
file
türündeki hedefler için basit girişler yayınlanır:
<source-file name='//foo:foo_main.cc' .../>
<generated-file name='//foo:libfoo.so' .../>
Ancak kurallar için XML yapılandırılmıştır ve değeri, kuralın BUILD
dosyasında açıkça belirtilmemiş olanlar da dahil olmak üzere kuralın tüm özelliklerinin tanımlarını içerir.
Buna ek olarak sonuç, rule-input
ve rule-output
öğelerini içerir. Böylece bağımlılık grafiğinin topolojisi, örneğin srcs
özelliği öğelerinin ileriye bağımlılıklar (önkoşullar) ve outs
özelliğinin içeriklerinin geriye dönük bağımlılıklar (tüketiciler) olduğu bilinmeden yeniden oluşturulabilir.
--noimplicit_deps
belirtilirse dolaylı 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 hedefe ait her XML öğesi, değeri hedefin etiketi olan bir name
özelliği ve değeri hedefin --output location
tarafından yazdırılan konumu olan bir location
özelliği içerir.
--[no]xml:line_numbers
Varsayılan olarak, XML çıkışında görüntülenen konumlar satır numaralarını içerir.
--noxml:line_numbers
belirtildiğinde satır numaraları yazdırılmaz.
--[no]xml:default_values
Varsayılan olarak XML çıkışı, değeri söz konusu özellik türünün varsayılan değeri olan kural özelliğini içermez (örneğin, BUILD
dosyasında belirtilmemişse 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. Böylece java.util.regex.Pattern
için tam söz dizimini kullanabilirsiniz.
Harici kod depolarıyla sorgulama
Derleme harici depolardaki kurallara dayanıyorsa sorgu sonuçları bu bağımlılıkları içerir. Örneğin, //foo:bar
değeri @other-repo//baz:lib
değerine bağlıysa bazel query 'deps(//foo:bar)'
, @other-repo//baz:lib
öğesini bağımlılık olarak listeler.