बेज़ल क्वेरी का रेफ़रंस

ग्राफ़ ऑर्डर का संरक्षण पर

कार्रवाइयां, उनके सब-एक्सप्रेशन से इनहेरिट की गई सभी क्रम की शर्तों को सुरक्षित रखती हैं. इसे "कुछ हद तक ऑर्डर को सुरक्षित रखने वाला कानून" माना जा सकता है. उदाहरण के तौर पर: अगर आप किसी खास टारगेट के आधार पर, डिपेंडेंसी को ट्रांज़िट समय के तौर पर तय करने के लिए क्वेरी जारी करते हैं, तो सेट का क्रम डिपेंडेंसी ग्राफ़ के हिसाब से लिया जाता है. अगर आप सिर्फ़ file के टारगेट को शामिल करने के लिए सेट किए गए फ़िल्टर को फ़िल्टर करते हैं, तो नतीजे के सबसेट में टारगेट की हर जोड़ी के बीच, एक ही ट्रांज़िट का क्रम होता है. भले ही, इनमें से कोई भी जोड़ी असल में मूल ग्राफ़ में सीधे तौर पर नहीं जुड़ी होती है. (बिल्डिंग निर्भरता ग्राफ़ में कोई फ़ाइल-फ़ाइल किनारे नहीं हैं).

हालांकि, सभी ऑपरेटर ऑर्डर को सुरक्षित रखते हैं, लेकिन सेट करने से जुड़ी कार्रवाइयों जैसे कुछ ऑपरेशंस, ऑर्डर करने से जुड़ी किसी भी शर्त को पेश नहीं करते. इस एक्सप्रेशन पर विचार करें:

deps(x) union y

फ़ाइनल सेट के क्रम की गारंटी, सब-एक्सप्रेशन के क्रम में आने वाली सभी रुकावटों को बनाए रखती है. जैसे, xकी कुछ समय के लिए जो डिपेंडेंसी होती हैं, वे एक-दूसरे के हिसाब से सही होती हैं. हालांकि, क्वेरी में y में टारगेट के क्रम के बारे में और न ही y में टारगेट से जुड़े टारगेट के क्रम के बारे में कोई गारंटी दी जाती है (y में मौजूद टारगेट को छोड़कर, जो deps(x) में भी होते हैं).

ऑर्डर देने से जुड़ी शर्तों को लागू करने वाले ऑपरेटर में ये शामिल हैं: allpaths, deps, rdeps, somepath, और टारगेट पैटर्न वाइल्डकार्ड package:*, dir/... वगैरह.

Sky क्वेरी

Sky Query, क्वेरी का एक ऐसा मोड है जो किसी खास यूनिवर्सल स्कोप पर काम करता है.

विशेष फ़ंक्शन केवल SkyQuery में उपलब्ध हैं

Sky Query मोड में अन्य क्वेरी फ़ंक्शन allrdeps और rbuildfiles हैं. ये फ़ंक्शन, पूरे यूनिवर्स के दायरे में काम करते हैं (इसलिए, इन्हें सामान्य क्वेरी का कोई मतलब नहीं बनता).

ब्रह्मांड का दायरा तय करना

इन दो फ़्लैग को पास करके, Sky Query मोड को चालू किया जाता है: (--universe_scope या --infer_universe_scope) और --order_output=no. --universe_scope=<target_pattern1>,...,<target_patternN> में क्वेरी को टारगेट पैटर्न के लिए तय किए गए टारगेट पैटर्न के स्थायी बंद होने के बारे में बताया जाता है. यह योग अलग-अलग हो सकता है और घटा भी सकता है. इसके बाद, सभी क्वेरी का आकलन इस "दायरे" में किया जाता है. खास तौर पर, allrdeps और rbuildfiles ऑपरेटर सिर्फ़ इस दायरे से नतीजे दिखाते हैं. --infer_universe_scope, बेज़ल को क्वेरी एक्सप्रेशन से --universe_scope के लिए कोई वैल्यू तय करने का निर्देश देती है. यह अनुमानित मान, क्वेरी एक्सप्रेशन में खास टारगेट पैटर्न की सूची है, लेकिन यह आपकी पसंद का नहीं है. उदाहरण के लिए :

bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"

इस क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची ["//my:target"] है, इसलिए बेज़ल इसे शुरू करने वाले के तौर पर मानेंगे:

bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"

हालांकि, --universe_scope वाली क्वेरी का नतीजा सिर्फ़ //my:target है. //my:target का कोई भी रिवर्स डिपेंडेंसी, ब्रह्मांड में है! दूसरी ओर, इन पर विचार करें:

bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"

यह एक क्वेरी का अनुरोध करने की सुविधा है, जो tests कुछ डायरेक्ट्री में मौजूद टारगेट के एक्सपैंशन में टेस्ट टारगेट की गिनती करने की कोशिश करती है. यह टारगेट, कुछ समय के लिए उन टारगेट पर निर्भर करता है जिनकी परिभाषा में .bzl की एक खास फ़ाइल का इस्तेमाल किया गया हो. यहां, --infer_universe_scope की सुविधा इस्तेमाल की जा सकती है. खास तौर पर, ऐसा तब होता है, जब --universe_scope के विकल्प के लिए, आपको खुद क्वेरी एक्सप्रेशन को पार्स करना पड़ता है.

इसलिए, allrdeps और rbuildfiles जैसे स्कोप के इस्तेमाल वाले क्वेरी एक्सप्रेशन के लिए, --infer_universe_scope का इस्तेमाल सिर्फ़ तब करें, जब इसका व्यवहार आपकी पसंद के मुताबिक हो.

डिफ़ॉल्ट क्वेरी की तुलना में स्काई क्वेरी के कुछ फ़ायदे और नुकसान हैं. इसका मुख्य नुकसान यह है कि यह ग्राफ़ के क्रम के हिसाब से आउटपुट नहीं देता, इसलिए कुछ आउटपुट फ़ॉर्मैट इस्तेमाल नहीं किए जा सकते. इसका फ़ायदा यह है कि यह दो ऑपरेटर (allrdeps और rbuildfiles) को उपलब्ध कराता है जो डिफ़ॉल्ट क्वेरी में उपलब्ध नहीं होते. इसी तरह, Sky Query एक नया ग्राफ़ बनाने के बजाय, Skyframe ग्राफ़ के बारे में जानकारी देकर, अपना काम करता है, जो डिफ़ॉल्ट तरीके से किया जाता है. इसलिए, कुछ स्थितियों में यह ज़्यादा तेज़ हो जाता है और कम मेमोरी का इस्तेमाल करता है.

एक्सप्रेशन: व्याकरण के सिंटैक्स और सिमेंटिक

यह Bazel क्वेरी भाषा का व्याकरण है, जिसे EBNF नोटेशन में दिखाया गया है:

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 ... ')'

नीचे दिए गए सेक्शन में, व्याकरण के हर प्रोडक्शन के बारे में जानकारी दी गई है.

टारगेट पैटर्न

expr ::= word

वाक्य में, टारगेट पैटर्न सिर्फ़ एक शब्द है. इसे टारगेट (बिना क्रम वाले) के सेट के तौर पर देखा जाता है. सबसे आसान टारगेट पैटर्न एक लेबल होता है. इससे, किसी एक टारगेट (फ़ाइल या नियम) की पहचान होती है. उदाहरण के लिए, टारगेट पैटर्न //foo:bar किसी ऐसे सेट का आकलन करता है जिसमें एक एलिमेंट, टारगेट, bar नियम शामिल होता है.

टारगेट पैटर्न, लेबल को सामान्य बनाते हैं, ताकि पैकेज और टारगेट के बजाय वाइल्डकार्ड शामिल किए जा सकें. उदाहरण के लिए, foo/...:all (या सिर्फ़ foo/...) एक टारगेट पैटर्न है, जो ऐसे सेट का आकलन करता है जिसमें foo डायरेक्ट्री के नीचे मौजूद सभी पैकेज के सभी नियम शामिल होते हैं. bar/baz:all ऐसा टारगेट पैटर्न है जो bar/baz पैकेज के सभी नियमों वाले सेट का आकलन करता है, न कि सब-पैकेज का.

इसी तरह, टारगेट करने का पैटर्न foo/...:* होता है. यह ऐसे सेट का आकलन करता है जिसमें foo पैकेज के हर पैकेज में, सभी टारगेट (नियम और फ़ाइलें) बार-बार शामिल होता है. bar/baz:*, bar/baz पैकेज में मौजूद सभी टारगेट वाले सेट का आकलन करता है, न कि सब-पैकेज का.

:* वाइल्डकार्ड, फ़ाइलों के साथ-साथ नियमों से भी मेल खाता है, इसलिए अक्सर क्वेरी के लिए :all के मुकाबले इसका इस्तेमाल ज़्यादा होता है. इसके उलट, :all वाइल्डकार्ड (foo/... जैसे टारगेट पैटर्न में इंप्लिसिट) आम तौर पर बिल्ड के लिए ज़्यादा काम का होता है.

bazel query टारगेट पैटर्न, bazel build बिल्ड टारगेट की तरह ही काम करते हैं. ज़्यादा जानकारी के लिए, टारगेट पैटर्न देखें या bazel help target-syntax टाइप करें.

टारगेट पैटर्न, किसी सिंगलटन सेट (किसी लेबल के मामले में) से लेकर, कई एलिमेंट वाले सेट पर जांच कर सकते हैं (जैसे कि foo/... के मामले में, जिसमें हज़ारों एलिमेंट हैं) या किसी सेट के लिए, अगर टारगेट पैटर्न किसी टारगेट से मेल नहीं खाता है.

टारगेट पैटर्न एक्सप्रेशन के नतीजे में मौजूद सभी नोड, डिपेंडेंसी रिलेशनशिप के हिसाब से एक-दूसरे के मुताबिक सही क्रम में लगाए जाते हैं. इसलिए, foo:* का नतीजा, सिर्फ़ पैकेज foo में टारगेट का सेट नहीं है, बल्कि उन टारगेट के लिए ग्राफ़ भी है. (नतीजों के नोड के मुकाबले दूसरे नोड के क्रम के बारे में कोई गारंटी नहीं दी जाती है.) ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम सेक्शन देखें.

वैरिएबल

expr ::= let name = expr1 in expr2
       | $name

Bazel क्वेरी भाषा की मदद से, वैरिएबल की परिभाषा और उनसे जुड़ी जानकारी देखी जा सकती है. let एक्सप्रेशन का मूल्यांकन, expr₂ के नतीजे से मिलता-जुलता है, जिसमें वैरिएबल name की सभी मुफ़्त मेट्रिक को expr₁ की वैल्यू से बदला जाता है.

उदाहरण के लिए, let v = foo/... in allpaths($v, //common) intersect $v, allpaths(foo/...,//common) intersect foo/... के बराबर है.

let name = ... एक्सप्रेशन के पास name एक्सप्रेशन के पाए जाने की वजह से कोई गड़बड़ी होती है. दूसरे शब्दों में, टॉप-लेवल के क्वेरी एक्सप्रेशन में मुफ़्त वैरिएबल नहीं हो सकते.

ऊपर दिए गए व्याकरण के प्रोडक्शन में, name शब्द जैसा होता है, लेकिन अतिरिक्त सीमा के साथ कि यह C प्रोग्रामिंग भाषा में एक कानूनी पहचानकर्ता है. वैरिएबल के रेफ़रंस के पहले में "$" वर्ण होना चाहिए.

हर let एक्सप्रेशन सिर्फ़ एक वैरिएबल के बारे में बताता है, लेकिन आप उन्हें नेस्ट कर सकते हैं.

टारगेट पैटर्न और वैरिएबल पहचान, दोनों में सिर्फ़ एक टोकन, एक शब्द, और वाक्य-विज्ञान की अस्पष्टता पैदा होती है. हालांकि, कोई मतलब नहीं होता, क्योंकि शब्दों के सबसेट, कानूनी वैरिएबल के नाम होते हैं, जो कानूनी टारगेट पैटर्न वाले शब्दों के सबसेट से अलग होते हैं.

तकनीकी रूप से, let एक्सप्रेशन क्वेरी भाषा की अभिव्यक्ति को नहीं बढ़ाते हैं: भाषा में एक्सप्रेस करने लायक कोई भी क्वेरी उनके बिना भी दिखाई जा सकती है. हालांकि, इससे कई क्वेरी के नतीजों को सटीक बनाने में मदद मिलती है. साथ ही, इससे क्वेरी का बेहतर तरीके से मूल्यांकन भी हो सकता है.

ब्रैकेट में दिए गए एक्सप्रेशन

expr ::= (expr)

कोष्ठक में सब-एक्सप्रेशन, आकलन के क्रम को लागू करने के लिए ज़रूरी है. ब्रैकेट में मौजूद एक्सप्रेशन अपने आर्ग्युमेंट की वैल्यू का आकलन करता है.

बीजीय सेट संचालन: चौराहा, यूनियन, सेट अंतर

expr ::= expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr

ये तीन ऑपरेटर अपने तर्कों पर सामान्य सेट ऑपरेशन की गणना करते हैं. हर ऑपरेटर के दो फ़ॉर्म होते हैं, एक नामात्मक, जैसे कि intersect, और एक सिंबॉलिक फ़ॉर्म, जैसे कि ^. दोनों फ़ॉर्म एक जैसे हैं. सिंबल फ़ॉर्म तेज़ी से टाइप किए जा सकते हैं. (इसकी जानकारी देने के लिए, इस पेज के बाकी हिस्से में नाम वाले फ़ॉर्म इस्तेमाल किए जाते हैं.)

उदाहरण के लिए,

foo/... except foo/bar/...

foo/... के हिसाब से टारगेट के सेट का आकलन करता है, लेकिन foo/bar/... से नहीं.

ऐसी ही क्वेरी लिखी जा सकती है:

foo/... - foo/bar/...

intersect (^) और union (+) ऑपरेशन एक साथ काम करने वाले होते हैं; except (-) की गिनती मुश्किल होती है. पार्सर, तीनों ऑपरेटर को लेफ़्ट-असोसिएटिव और बराबर प्राथमिकता वाला मानता है, इसलिए हो सकता है कि आपको ब्रैकेट की ज़रूरत पड़े. उदाहरण के लिए, इनमें से पहले दो एक्सप्रेशन एक जैसे हैं, लेकिन तीसरा नहीं है:

x intersect y union z
(x intersect y) union z
x intersect (y union z)

किसी बाहरी स्रोत से लक्ष्य पढ़ें: सेट करें

expr ::= set(word *)

set(a b c ...) ऑपरेटर, शून्य या उससे ज़्यादा टारगेट पैटर्न के सेट की गिनती करता है. इन खाली जगहों को खाली सफ़ेद जगह (कोई कॉमा नहीं) से अलग किया जाता है.

बॉर्न शेल की $(...) सुविधा के साथ-साथ, set() से एक क्वेरी के नतीजों को सामान्य टेक्स्ट फ़ाइल में सेव करने के तरीके मिलते हैं. इस तरह, वह टेक्स्ट फ़ाइल को दूसरे प्रोग्राम (जैसे कि स्टैंडर्ड UNIX शेल टूल) का इस्तेमाल करके बदल देता है. इसके बाद, नतीजे को क्वेरी टूल में वापस प्रोसेस करता है, ताकि उसे आगे की प्रोसेस के लिए वैल्यू के तौर पर इस्तेमाल किया जा सके. उदाहरण के लिए :

bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"

अगले उदाहरण में,kind(cc_library, deps(//some_dir/foo:main, 5)) की गणना awk मान का उपयोग करके maxrank मानों पर फ़िल्टर करके की जाती है.

bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"

इन उदाहरणों में, $(<foo), $(cat foo) के लिए शॉर्टहैंड है. हालांकि, cat के अलावा, शेल से जुड़े निर्देश भी इस्तेमाल किए जा सकते हैं. जैसे, पिछला awk निर्देश.

फ़ंक्शन

expr ::= word '(' int | word | expr ... ')'

क्वेरी लैंग्वेज से कई फ़ंक्शन के बारे में पता चलता है. फ़ंक्शन का नाम, आर्ग्युमेंट की ज़रूरत की संख्या और टाइप को तय करता है. ये सुविधाएं उपलब्ध हैं:

• allpaths
• attr
• buildfiles
• rbuildfiles
• deps
• filter
• kind
• labels
• loadfiles
• rdeps
• allrdeps
• same_pkg_direct_rdeps
• siblings
• some
• somepath
• tests
• visible

डिपेंडेंसी का सस्पेंशन बंद होना: Deps

expr ::= deps(expr)
       | deps(expr, depth)

deps(x) ऑपरेटर के ग्राफ़ का मूल्यांकन इस बात से होता है कि उसके आर्ग्युमेंट सेट की डिपेंडेंसी, ट्रांज़िशनल क्लोज़िंग के आधार पर बनती है x. उदाहरण के लिए, deps(//foo) की वैल्यू एक डिपेंडेंसी ग्राफ़ पर निर्भर करती है. यह ग्राफ़ foo पर निर्भर करता है. deps(foo/...) की वैल्यू इस डिपेंडेंसी ग्राफ़ को दिखाती है. इसके रूट में, foo डायरेक्ट्री के नीचे दिए गए हर पैकेज के सभी नियम दिए गए हैं. इस संदर्भ में, 'निर्भर निर्भरता' का मतलब है सिर्फ़ नियम और फ़ाइल टारगेट, इसलिए इन टारगेट को बनाने के लिए ज़रूरी BUILD और Starlark फ़ाइलों को यहां शामिल नहीं किया जाता है. इसके लिए, आपको buildfiles ऑपरेटर का इस्तेमाल करना चाहिए.

नतीजे के तौर पर दिखने वाला ग्राफ़, डिपेंडेंसी से जुड़े संबंध के हिसाब से क्रम में लगाया जाता है. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम सेक्शन देखें.

deps ऑपरेटर, विकल्प के तौर पर एक वैकल्पिक आर्ग्युमेंट स्वीकार करता है. यह आर्ग्युमेंट, पूर्णांक होता है. इसकी मदद से, खोज के नतीजों की ऊपरी सीमा को तय किया जाता है. इसलिए, deps(foo:*, 0), foo पैकेज के सभी टारगेट दिखाता है, जबकि deps(foo:*, 1) में foo पैकेज के किसी भी टारगेट के लिए, सीधे तौर पर तय की गई शर्तें शामिल होती हैं. साथ ही, deps(foo:*, 2) में deps(foo:*, 1) के नोड से सीधे पहुंचने वाले नोड भी शामिल होते हैं. (ये संख्याएं, minrank आउटपुट फ़ॉर्मैट में दिखाई गई रैंक से मेल खाती हैं.) अगर depth पैरामीटर को शामिल नहीं किया जाता है, तो खोज को बिना किसी प्रतिबंध के बनाया जाता है: यह पूर्वापेक्षाओं के रिफ़्लेक्सिव ट्रांज़िटिव ट्रांज़िशन की गिनती करता है.

रिवर्स डिपेंडेंसी को कुछ समय के लिए बंद करना: आरडीपी

expr ::= rdeps(expr, expr)
       | rdeps(expr, expr, depth)

rdeps(u, x)ऑपरेटर, सेट किए गए आर्ग्युमेंट सेट की रिवर्स डिपेंडेंसी x की जांच करता है. यह ब्रह्मांड सेट के ट्रांज़िट समय में,u के अंदर होता है.

नतीजे के तौर पर दिखने वाला ग्राफ़, डिपेंडेंसी से जुड़े संबंध के हिसाब से क्रम में लगाया जाता है. ज़्यादा जानकारी के लिए ग्राफ़ का क्रम सेक्शन देखें.

rdeps ऑपरेटर, विकल्प के तौर पर एक वैकल्पिक आर्ग्युमेंट स्वीकार करता है. यह आर्ग्युमेंट एक लिटरल होता है, जिसमें खोज के लिए ऊपर की तरफ़ की सीमा तय होती है. नतीजे वाले ग्राफ़ में, आर्ग्युमेंट सेट में सिर्फ़ किसी नोड से बताई गई डेप्थ की दूरी वाले नोड शामिल होते हैं. इसलिए, rdeps(//foo, //common, 1) //foo के ट्रांज़िट समय में सभी नोड का मूल्यांकन करता है, जो सीधे //common पर निर्भर होता है. (ये संख्याएं, minrank आउटपुट फ़ॉर्मैट में दिखाई गई रैंक से मेल खाती हैं.) अगर depth पैरामीटर को शामिल नहीं किया जाता है, तो खोज को जोड़ा नहीं जाता.

सभी रिवर्स डिपेंडेंसी को ट्रांज़िट समय के लिए बंद करना: Allrdeps

expr ::= allrdeps(expr)
       | allrdeps(expr, depth)

allrdeps ऑपरेटर, rdeps ऑपरेटर की तरह ही काम करता है. हालांकि, इसमें "यूनिवर्स सेट" वह होता है जिसके बारे में --universe_scope फ़्लैग का आकलन किया जाता है, न कि अलग से बताए जाने पर. इसलिए, अगर --universe_scope=//foo/... पास हो गया है, तो allrdeps(//bar) rdeps(//foo/..., //bar) के बराबर होगा.

एक ही पैकेज में डायरेक्ट रिवर्स डिपेंडेंसी: same_pkg_direct_rdeps

expr ::= same_pkg_direct_rdeps(expr)

same_pkg_direct_rdeps(x) ऑपरेटर, टारगेट के ऐसे पूरे सेट से जांच करता है जो आर्ग्युमेंट सेट में टारगेट के समान पैकेज में होता है और जो इस पर सीधे तौर पर निर्भर होता है.

टारगेट के पैकेज से निपटना: भाई-बहन

expr ::= siblings(expr)

siblings(x) ऑपरेटर, टारगेट के पूरे सेट से मेल खाते हैं. ये सेट, आर्ग्युमेंट सेट के टारगेट के बराबर होते हैं.

वैकल्पिक विकल्प: कुछ

expr ::= some(expr)
       | some(expr, count )

some(x, k) ऑपरेटर, अपने तर्क के आधार पर सेट किए गए x वैल्यू में से, ज़्यादा से ज़्यादा k टारगेट को अपने हिसाब से चुनता है और ऐसे सेट का आकलन करता है जिनमें सिर्फ़ वही टारगेट होते हैं. पैरामीटर k ज़रूरी नहीं है. अगर यह मौजूद नहीं है, तो सिंगलटन सेट को सिर्फ़ एक टारगेट के साथ चुना जाएगा. अगर आर्ग्युमेंट सेट का साइज़ x k से कम है, तो पूरा आर्ग्युमेंट सेट x दिखाया जाएगा.

उदाहरण के लिए, एक्सप्रेशन some(//foo:main union //bar:baz) किसी सिंगलटन सेट के लिए मूल्यांकन करता है, जिसमें //foo:main या //bar:baz शामिल होते हैं—हालांकि, इनमें से किसी के बारे में नहीं बताया गया है. एक्सप्रेशन some(//foo:main union //bar:baz, 2) या some(//foo:main union //bar:baz, 3), //foo:main और //bar:baz, दोनों दिखाता है.

अगर आर्ग्युमेंट सिंगलटन है, तो some पहचान फ़ंक्शन का आकलन करता है: some(//foo:main), //foo:main के बराबर है.

अगर बताए गए आर्ग्युमेंट सेट खाली हैं, तो यह एक गड़बड़ी है, जैसा कि एक्सप्रेशन some(//foo:main intersect //bar:baz) में हुआ है.

पाथ ऑपरेटर: ऐम्पपाथ, सभी पाथ

expr ::= somepath(expr, expr)
       | allpaths(expr, expr)

somepath(S, E) और allpaths(S, E) ऑपरेटर टारगेट के दो सेट के बीच के पाथ की गिनती करते हैं. दोनों क्वेरी में दो आर्ग्युमेंट स्वीकार किए जाते हैं, शुरुआती पॉइंट का एक सेट S होता है और एंड पॉइंट का एक सेट E होता है. somepath, कुछ आर्बिट्रेरी पाथ में मौजूद नोड के ग्राफ़ को, S में मौजूद टारगेट से E के टारगेट में दिखाता है. allpaths, सभी पाथ पर मौजूद नोड के ग्राफ़ को, S में मौजूद किसी भी टारगेट से E के किसी टारगेट को दिखाता है.

नतीजे के तौर पर दिखने वाले ग्राफ़, डिपेंडेंसी से जुड़े संबंध के हिसाब से क्रम में लगाए जाते हैं. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम वाला सेक्शन देखें.

टारगेट टाइप फ़िल्टर करने की सुविधा: टाइप

expr ::= kind(word, expr)

kind(pattern, input)ऑपरेटर टारगेट के सेट पर फ़िल्टर लागू करता है और उन टारगेट को खारिज कर देता है जो अनुमानित तरह के नहीं होते. pattern पैरामीटर बताता है कि किस तरह का टारगेट मैच करना है.

उदाहरण के लिए, BUILD फ़ाइल (पैकेज p के लिए) में बताए गए चार टारगेट के टाइप, टेबल में दिखाए गए हैं:

        genrule(
            name = "a",
            srcs = ["a.in"],
            outs = ["a.out"],
            cmd = "...",
        )
      

इस तरह, kind("cc_.* rule", foo/...), सभी cc_library, cc_binary वगैरह के नियम सेट का आकलन करता है, foo के तहत नियम के टारगेट का होता है, और kind("source file", deps(//foo)) //foo टारगेट की डिपेंडेंसी के लिए, कुछ समय के लिए बंद होने वाली सभी सोर्स फ़ाइलों के सेट का आकलन करता है.

pattern आर्ग्युमेंट का कोटेशन अक्सर ज़रूरी होता है, क्योंकि इसके बिना, source file और .*_test जैसे कई रेगुलर एक्सप्रेशन पार्सर नहीं माने जाते.

package group के लिए मैच करने पर, :all से खत्म होने वाले टारगेट शायद कोई नतीजा न दें. इसके बजाय, :all-targets का इस्तेमाल करें.

टारगेट नाम फ़िल्टर करना: फ़िल्टर

expr ::= filter(word, expr)

filter(pattern, input)ऑपरेटर, टारगेट के सेट पर फ़िल्टर लागू करता है और उन टारगेट को खारिज कर देता है जिनके लेबल पैटर्न से मैच नहीं करते हैं. यह अपने इनपुट के सबसेट का आकलन करता है.

पहला आर्ग्युमेंट, pattern वह शब्द होता है जिसमें टारगेट नेम पर रेगुलर एक्सप्रेशन होता है. filter एक्सप्रेशन सभी सेट वाले x सेट का आकलन करता है, जैसे कि x, सेट input का सदस्य हो और x (निरंतर रूप में, जैसे कि x) के लेबल में रेगुलर एक्सप्रेशन pattern का (ऐंकर वाला) मैच हो. सभी टारगेट नाम // से शुरू होते हैं, इसलिए इसे ^ रेगुलर एक्सप्रेशन ऐंकर के विकल्प के तौर पर इस्तेमाल किया जा सकता है.

यह ऑपरेटर, अक्सर intersect ऑपरेटर को ज़्यादा तेज़ और बेहतर विकल्प देता है. उदाहरण के लिए, //foo:foo टारगेट की सभी bar डिपेंडेंसी देखने के लिए,

deps(//foo) intersect //bar/...

हालांकि, इस स्टेटमेंट को bar ट्री में मौजूद सभी BUILD फ़ाइलों को पार्स करना होगा. इससे, BUILD फ़ाइलें धीमी गति से लोड होंगी और गड़बड़ियों की संभावना बढ़ जाएगी. एक विकल्प यह होगा:

filter(//bar, deps(//foo))

जो पहले //foo डिपेंडेंसी के सेट का हिसाब लगाता है. इसके बाद, सिर्फ़ दिए गए पैटर्न से मेल खाने वाले टारगेट को फ़िल्टर करता है. दूसरे शब्दों में, सबस्ट्रिंग के तौर पर //bar के नाम वाले टारगेट को फ़िल्टर करता है.

filter(pattern, expr) ऑपरेटर का एक और इस्तेमाल, खास फ़ाइलों को उनके नाम या एक्सटेंशन के हिसाब से फ़िल्टर करना है. उदाहरण के लिए,

filter("\.cc$", deps(//foo))

//foo बनाने के लिए इस्तेमाल की गई सभी .cc फ़ाइलों की सूची उपलब्ध कराएगा.

नियम विशेषता फ़िल्टर: attr

expr ::= attr(word, word, expr)

attr(name, pattern, input) ऑपरेटर, टारगेट के सेट पर फ़िल्टर लागू करता है. साथ ही, ऐसे टारगेट को खारिज कर देता है जो नियम नहीं हैं, नियम के ऐसे टारगेट को खारिज कर देते हैं जिनमें name एट्रिब्यूट तय नहीं होता या जो टारगेट वैल्यू दी गई रेगुलर एक्सप्रेशन pattern से मेल नहीं खाती. यह इनपुट के सबसेट को जांचती है.

पहला आर्ग्युमेंट, name एट्रिब्यूट का नाम है, जो दिए गए रेगुलर एक्सप्रेशन पैटर्न से मेल खाना चाहिए. दूसरा आर्ग्युमेंट, pattern एट्रिब्यूट की वैल्यू पर रेगुलर एक्सप्रेशन है. attr एक्सप्रेशन में सभी टारगेट वाले सेट का आकलन किया जाता है x, जैसे कि x, सेट किए गए input का सदस्य होता है. यह तय किए गए एट्रिब्यूट name के साथ नियम होता है. इसके एट्रिब्यूट की वैल्यू में, रेगुलर एक्सप्रेशन का pattern(ऐंकर ऐंकर) मैच होता है. अगर name एक वैकल्पिक एट्रिब्यूट है और नियम में इसके बारे में साफ़ तौर पर नहीं बताया गया है, तो तुलना करने के लिए डिफ़ॉल्ट एट्रिब्यूट वैल्यू का इस्तेमाल किया जाएगा. उदाहरण के लिए,

attr(linkshared, 0, deps(//foo))

ऐसे सभी //foo डिपेंडेंसी चुन लेगा जिनके लिए, शेयर की गई एट्रिब्यूट की अनुमति है (जैसे कि cc_binary नियम). साथ ही, इसे साफ़ तौर पर 0 पर सेट किया जाना चाहिए या सेट नहीं किया जाना चाहिए, लेकिन डिफ़ॉल्ट वैल्यू 0 है (जैसे, cc_binary नियमों के लिए).

सूची-टाइप एट्रिब्यूट (जैसे, srcs, data वगैरह) को [value<sub>1</sub>, ..., value<sub>n</sub>] फ़ॉर्म की स्ट्रिंग में बदल दिया जाता है. ये [ ब्रैकेट से शुरू होते हैं और ] ब्रैकेट पर खत्म होते हैं. साथ ही, कई वैल्यू को सीमित करने के लिए, "," (कॉमा, स्पेस) का इस्तेमाल करते हैं. लेबल, लेबल के संपूर्ण रूप का उपयोग करके स्ट्रिंग में बदले जाते हैं. जैसे, एट्रिब्यूट deps=[":foo", "//otherpkg:bar", "wiz"] को स्ट्रिंग [//thispkg:foo, //otherpkg:bar, //thispkg:wiz] में बदला जाएगा. ब्रैकेट हमेशा मौजूद होते हैं, इसलिए खाली सूची मैच करने के लिए [] वैल्यू का इस्तेमाल करती है. उदाहरण के लिए,

attr("srcs", "\[\]", deps(//foo))

//foo डिपेंडेंसी के सभी नियमों को चुनेगा, लेकिन इसमें srcs एट्रिब्यूट खाली है

attr("data", ".{3,}", deps(//foo))

data डिपेंडेंसी में, कम से कम एक वैल्यू तय करने वाली //foo डिपेंडेंसी के सभी नियम चुने जाएंगे. // और : की वजह से, हर लेबल कम से कम तीन वर्ण लंबा होगा.

सूची-प्रकार विशेषता में विशेष value के साथ //foo निर्भरता के सभी नियम चुनने के लिए, इनका उपयोग करें

attr("tags", "[\[ ]value[,\]]", deps(//foo))

यह इसलिए काम करता है, क्योंकि value से पहले के वर्ण [ होंगे या स्पेस और value के बाद का वर्ण कॉमा या ] होगा.

नियम किसको दिखे फ़िल्टर करना: दिख रहा है

expr ::= visible(expr, expr)

visible(predicate, input) ऑपरेटर, टारगेट के किसी सेट पर कोई फ़िल्टर लागू करता है. साथ ही, सेट किए गए टारगेट को हटा देता है.

पहला तर्क, predicate टारगेट का एक सेट है, जिसे आउटपुट में सभी टारगेट को दिखना चाहिए. visible एक्सप्रेशन उस सेट का आकलन करता है जिसमें सभी टारगेट x शामिल होते हैं, ताकि x सेट input का सदस्य हो. साथ ही, y को x में मौजूद सभी टारगेट के लिए y दिखता है. उदाहरण के लिए :

visible(//foo, //bar:*)

//bar के उन टारगेट को चुनेगा जिन पर //foo निर्भर करता है. हालांकि, ये विज़िबिलिटी से जुड़ी पाबंदियों के बिना होते हैं.

टाइप लेबल के नियम एट्रिब्यूट का आकलन: लेबल

expr ::= labels(word, expr)

labels(attr_name, inputs) ऑपरेटर inputs के कुछ नियम में "label" या "लेबल की सूची" प्रकार की विशेषता attr_name में तय किए गए लक्ष्यों का सेट देता है.

उदाहरण के लिए, labels(srcs, //foo) //foo नियम के srcs एट्रिब्यूट में दिखने वाले टारगेट का सेट दिखाता है. अगर inputs सेट में srcs एट्रिब्यूट वाले एक से ज़्यादा नियम हैं, तो उनके srcs को मिला दिया जाता है.

test_suites: फ़िल्टर को बड़ा और फ़िल्टर करें

expr ::= tests(expr)

tests(x) ऑपरेटर, सेट x में टेस्ट के सभी नियमों का सेट दिखाता है. इसके बाद, test_suite के सभी नियमों को निजी जांचों के सेट में बांटा जाता है और tag और size के मुताबिक फ़िल्टर किया जाता है.

डिफ़ॉल्ट रूप से, क्वेरी का मूल्यांकन सभी test_suite नियमों में बिना टेस्ट वाले टारगेट को अनदेखा करता है. इसे --strict_test_suite विकल्प की मदद से, गड़बड़ियों में बदला जा सकता है.

उदाहरण के लिए, क्वेरी kind(test, foo:*) में foo पैकेज के सभी *_test और test_suite नियम दिए गए हैं. सभी नतीजे, foo पैकेज के सदस्य होते हैं. इसके उलट, क्वेरी tests(foo:*) ऐसे सभी जांच के लिए नतीजे दिखाएगी जिन्हें bazel test foo:* से लागू किया जाएगा: इसमें दूसरे पैकेज से जुड़े ऐसे टेस्ट भी शामिल हो सकते हैं जिन्हें test_suite नियमों के ज़रिए सीधे तौर पर या किसी दूसरे तरीके से इस्तेमाल किया जाता है.

पैकेज की परिभाषा फ़ाइलें: buildfile

expr ::= buildfiles(expr)

buildfiles(x) ऑपरेटर, फ़ाइलों की उस सेट की वैल्यू दिखाता है जो सेट x में मौजूद हर टारगेट के पैकेज के बारे में जानकारी देता है. इसका मतलब है कि हर पैकेज के लिए, उसकी BUILD फ़ाइल और load के ज़रिए .bzl की सभी फ़ाइलों के पैकेज की जानकारी देता है. ध्यान दें कि यह loaded फ़ाइलों वाले पैकेज की BUILD फ़ाइलें भी दिखाता है.

आम तौर पर, इस ऑपरेटर का इस्तेमाल यह तय करने के लिए किया जाता है कि तय किया गया टारगेट बनाने के लिए किन फ़ाइलों या पैकेज की ज़रूरत है. आम तौर पर, इनका इस्तेमाल --output package विकल्प के साथ किया जाता है. उदाहरण के लिए,

bazel query 'buildfiles(deps(//foo))' --output package

ऐसे सभी पैकेज का सेट दिखाता है जिन पर //foo कुछ समय के लिए निर्भर करता है.

पैकेज की परिभाषा फ़ाइलें: rbuildfiles

expr ::= rbuildfiles(word, ...)

rbuildfiles ऑपरेटर, पाथ फ़्रैगमेंट की कॉमा-सेपरेटेड लिस्ट लेता है और उन BUILD फ़ाइलों का सेट दिखाता है जो कुछ समय के लिए इन फ़्रैगमेंट पर निर्भर करते हैं. उदाहरण के लिए, अगर //foo एक पैकेज है, तो rbuildfiles(foo/BUILD) से //foo:BUILD टारगेट वैल्यू मिलेगी. अगर foo/BUILD फ़ाइल में load('//bar:file.bzl'... मौजूद है, तो rbuildfiles(bar/file.bzl) से //foo:BUILD टारगेट के साथ-साथ ऐसी किसी भी दूसरी BUILD फ़ाइल के लिए टारगेट रिटर्न होगा जो //bar:file.bzl को लोड करता है

rbuildfiles ऑपरेटर का दायरा, यूनिवर्स के --universe_scope फ़्लैग में बताया गया है. जो फ़ाइलें सीधे BUILD फ़ाइलों और .bzl फ़ाइलों से मेल नहीं खातीं, उनके नतीजों पर कोई असर नहीं पड़ता. उदाहरण के लिए, सोर्स फ़ाइलों (जैसे, foo.cc) को अनदेखा किया जाता है, भले ही उनका नाम BUILD फ़ाइल में साफ़ तौर पर बताया गया हो. हालांकि, सिमलिंक का इस्तेमाल किया जाता है. इसलिए, अगर foo/BUILD को bar/BUILD के लिए सिमलिंक बनाया गया है, तो rbuildfiles(bar/BUILD), नतीजों में //foo:BUILD को शामिल करेगा.

rbuildfiles ऑपरेटर, नैतिक तौर पर, buildfiles ऑपरेटर के उलट है. हालांकि, यह नैतिक व्युत्क्रम एक दिशा में ज़्यादा मज़बूती से होल्ड करता है: rbuildfiles के आउटपुट ठीक buildfiles के इनपुट की तरह हैं; पहले वाले में पैकेज में सिर्फ़ BUILD फ़ाइल टारगेट होंगे, और बाद वाले में ऐसे टारगेट हो सकते हैं. दूसरी तरफ़, यह बातचीत कमज़ोर है. buildfiles ऑपरेटर के आउटपुट, सभी पैकेज और .bzl दिए गए इनपुट के हिसाब से फ़ाइलें. हालांकि, rbuildfiles ऑपरेटर के इनपुट, वे टारगेट नहीं होते हैं, बल्कि ये उस टारगेट फ़्रैगमेंट होते हैं जो टारगेट के मुताबिक होते हैं.

पैकेज परिभाषा फ़ाइलें: लोड फ़ाइलें

expr ::= loadfiles(expr)

loadfiles(x)ऑपरेटर, Starlark फ़ाइलों का सेट दिखाता है, जो xसेट में हर टारगेट के पैकेज को लोड करने के लिए ज़रूरी हैं. दूसरे शब्दों में, यह हर पैकेज के लिए उसकी .bzl फ़ाइलें दिखाता है जिनका रेफ़रंस BUILD फ़ाइलों से लिया जाता है.

आउटपुट फ़ॉर्मैट

bazel query एक ग्राफ़ जनरेट करता है. आपको --output कमांड लाइन विकल्प के ज़रिए, कॉन्टेंट, फ़ॉर्मैट, और ऑर्डर की जानकारी देनी होती है. इसकी मदद से, bazel query यह ग्राफ़ दिखाता है.

Sky Query के साथ चलते समय, सिर्फ़ ऐसे आउटपुट फ़ॉर्मैट इस्तेमाल किए जा सकते हैं जो बिना क्रम वाले आउटपुट के साथ काम करते हैं. खास तौर पर, graph, minrank, और maxrank आउटपुट फ़ॉर्मैट इस्तेमाल नहीं किए जा सकते.

कुछ आउटपुट फ़ॉर्मैट में ज़्यादा विकल्प स्वीकार किए जाते हैं. हर आउटपुट विकल्प के नाम के शुरू में उस आउटपुट फ़ॉर्मैट से जुड़ा होता है, जिस पर यह लागू होता है, इसलिए --graph:factored सिर्फ़ --output=graph के इस्तेमाल पर ही लागू होता है; इससे कोई असर नहीं होता कि graph के अलावा किसी दूसरे आउटपुट फ़ॉर्मैट का इस्तेमाल किया जाए. इसी तरह, --xml:line_numbers सिर्फ़ तब लागू होता है, जब --output=xml इस्तेमाल किया जा रहा हो.

नतीजों के क्रम में

हालांकि, क्वेरी एक्सप्रेशन हमेशा "ग्राफ़ क्रम के संरक्षण" का पालन करते हैं, फिर भी नतीजे दिखने के लिए निर्भरता या क्रम में किए जा सकते हैं. इससे न कि नतीजों के सेट में मौजूद टारगेट पर असर पड़ता है या क्वेरी की गिनती करने के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह पता चलता है कि नतीजों को stdout में कैसे प्रिंट किया जाता है. इसके अलावा, जो नोड डिपेंडेंसी ऑर्डर में बराबर होते हैं उन्हें वर्णमाला के क्रम में रखा जा सकता है या नहीं. इस व्यवहार को कंट्रोल करने के लिए, --order_output फ़्लैग का इस्तेमाल किया जा सकता है. (--[no]order_results फ़्लैग में --order_output फ़्लैग की काम करने की सुविधा का एक सबसेट होता है और उसे बंद कर दिया जाता है.)

इस फ़्लैग की डिफ़ॉल्ट वैल्यू auto है. इससे, जानकारी के हिसाब से क्रम मिलता है. हालांकि, जब somepath(a,b) का इस्तेमाल किया जाएगा, तब नतीजे deps के हिसाब से प्रिंट किए जाएंगे.

जब no का फ़्लैग, --output, build, label, label_kind, location, package, proto या xml में से कोई एक हो, तो आउटपुट को आर्बिट्रेरी ऑर्डर में प्रिंट किया जाएगा. आम तौर पर, यह सबसे तेज़ विकल्प है. हालांकि, यह --output के graph, minrank या maxrank में से किसी एक होने पर काम नहीं करता है. इन फ़ॉर्मैट में, बेज़ल हमेशा डिपेंडेंसी ऑर्डर या रैंक के हिसाब से नतीजों को प्रिंट करता है.

जब deps का फ़्लैग होता है, तो बैज़ेल नतीजों को समय के हिसाब से प्रिंट करता है. इसका मतलब है कि डिपेंडेंसी पहले है. हालांकि, ऐसे नोड जो डिपेंडेंसी ऑर्डर में ऑर्डर नहीं किए गए होते हैं (क्योंकि एक से दूसरे में कोई पाथ नहीं होता) किसी भी क्रम में प्रिंट किए जा सकते हैं.

full का फ़्लैग होने पर, बैज़ेल नोड को पूरी तरह से डेटरमिनिस्टिक (कुल) क्रम में प्रिंट करता है. सबसे पहले, सभी नोड को अंग्रेज़ी वर्णमाला के क्रम में लगाया जाता है. फिर, सूची में मौजूद हर नोड का इस्तेमाल, ऑर्डर के बाद सबसे पहले की जाने वाली खोज की शुरुआत के तौर पर किया जाता है. इस खोज में, जाने वाले नोड के आउटगोइंग किनारों को बाद वाले नोड के वर्णानुक्रम में पार किया जाता है. आखिर में, नोड उसी क्रम में प्रिंट किए जाते हैं जिस क्रम में उन्हें देखा गया था.

इस क्रम में नोड प्रिंट करने की प्रक्रिया धीमी हो सकती है. इसलिए इसका इस्तेमाल सिर्फ़ तब किया जाना चाहिए जब तय करने वाला नियम अहम हो.

टारगेट का सोर्स फ़ॉर्म प्रिंट करें, जैसा कि वे BUILD में दिखता है

--output build

इस विकल्प को चुनने पर, हर टारगेट इस तरह से दिखाया जाता है जैसे कि उसे BUILD भाषा में हाथ से लिखा गया हो. सभी वैरिएबल और फ़ंक्शन कॉल (जैसे कि ग्लोब, मैक्रो) को बड़ा कर दिया जाता है. इससे, स्टारलार्क मैक्रो का असर देखा जा सकता है. इसके अलावा, हर असरदार नियम एक generator_name और/या generator_function) वैल्यू की रिपोर्ट करता है. इससे उस मैक्रो का नाम मिलता है जिसका इस्तेमाल करके बेहतर नियम बनाया गया.

हालांकि, आउटपुट में वही सिंटैक्स इस्तेमाल किया जाता है जो BUILD फ़ाइलों में इस्तेमाल किया जाता है. हालांकि, इस बात की गारंटी नहीं है कि BUILD की सही फ़ाइल बनाई जाएगी.

हर टारगेट का लेबल प्रिंट करें

--output label

इस विकल्प की मदद से, नतीजे के तौर पर मौजूद ग्राफ़ में, हर टारगेट के नाम (या लेबल) का सेट प्रिंट किया जाता है. हर लाइन में एक लेबल होता है, वैक्सीन के हिसाब से, --noorder_results की जानकारी देने के लिए, नतीजों के क्रम में नोट देखें. (स्थलीय क्रम वह होता है, जिसमें ग्राफ़ अपने सभी उत्तराधिकारियों की तुलना में पहले दिखाई देता है.) बेशक, ग्राफ़ के कई संभावित टोपिकल क्रम हैं: रिवर्स पोस्टऑर्डर सिर्फ़ एक है; कौनसा चुना गया है, इसकी जानकारी नहीं दी गई है.

somepath क्वेरी का आउटपुट प्रिंट करते समय, नोड का प्रिंट किया गया क्रम, पाथ का क्रम होता है.

चेतावनी: कुछ कोने के मामलों में, एक ही लेबल वाले दो अलग-अलग टारगेट हो सकते हैं; उदाहरण के लिए, एक sh_binary नियम और उसका सोल (अप्रसिद्ध) srcs फ़ाइल दोनों को foo.sh कहा जा सकता है. अगर किसी क्वेरी के नतीजे में ये दोनों टारगेट शामिल होते हैं, तो आउटपुट label फ़ॉर्मैट में डुप्लीकेट के तौर पर दिखेगा. label_kind (नीचे देखें) फ़ॉर्मैट का इस्तेमाल करते समय, अंतर साफ़ हो जाता है: दोनों टारगेट का नाम एक जैसा होता है, लेकिन एक में sh_binary rule और दूसरी तरह का source file होता है.

लेबल और हर टारगेट का प्रकार प्रिंट करें

--output label_kind

label की तरह, यह आउटपुट फ़ॉर्मैट, ग्राफ़ के नतीजे के हिसाब से हर टारगेट के लेबल को टोपिक क्रम में प्रिंट करता है. हालांकि, यह टारगेट के तरह के लेबल से पहले भी मौजूद होता है.

हर टारगेट का लेबल, रैंक के हिसाब से प्रिंट करें

--output minrank --output maxrank

label की तरह, minrank और maxrank आउटपुट फ़ॉर्मैट, हर ग्राफ़ को टारगेट ग्राफ़ के नतीजों में प्रिंट करते हैं. हालांकि, टोपोलॉजिकल क्रम में दिखने के बजाय, ये रैंकिंग के क्रम में दिखते हैं. इनके आगे उनकी रैंकिंग संख्या होती है. नतीजों के क्रम पर इन बदलावों का कोई असर नहीं पड़ता --[no]order_results फ़्लैग (नतीजों के क्रम में नोट देखें).

इस फ़ॉर्मैट के दो वैरिएंट हैं: minrank हर नोड को रूट नोड से लेकर उसके सबसे छोटे पाथ की लंबाई के हिसाब से रैंक करता है. "रूट" नोड (जिनके कोई किनारे बिलकुल नहीं हैं) की रैंक 0 है, उनके बाद वाले क्रम की रैंक 1 है.

maxrank हर नोड को रूट नोड से लेकर उसमें सबसे लंबे पाथ के हिसाब से रैंक करता है. एक बार फिर, "रूट" की रैंक 0 है. अन्य सभी नोड की रैंक, उनके सभी पूर्ववर्ती की रैंक से ज़्यादा है.

एक चक्र में सभी नोड को समान रैंक माना जाता है. (ज़्यादातर ग्राफ़ साइकल के होते हैं, लेकिन कई बार ऐसा होता है क्योंकि BUILD फ़ाइल में गलत साइकल होती हैं.)

ये आउटपुट फ़ॉर्मैट, ग्राफ़ की गहराई के बारे में जानने के लिए उपयोगी होते हैं. अगर इसे deps(x), rdeps(x) या allpaths क्वेरी के नतीजे के लिए इस्तेमाल किया जाता है, तो रैंक की संख्या कम से कम minrank के साथ या maxrank की वैल्यू के हिसाब से, x की रैंक से लेकर उस रैंक के नोड के बराबर होती है. maxrank का इस्तेमाल यह तय करने के लिए किया जा सकता है कि टारगेट बनाने के लिए, चरणों का सबसे लंबा क्रम क्या होगा.

उदाहरण के लिए, बाईं ओर मौजूद ग्राफ़, --output minrank से --output maxrank बताए जाने पर दाईं ओर आउटपुट दिखाता है.

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

हर टारगेट की जगह की जानकारी प्रिंट करें

--output location

label_kind की तरह, इस विकल्प के नतीजे के तौर पर हर टारगेट के लिए प्रिंट किया जाता है, टारगेट का टाइप और लेबल होता है, लेकिन यह उस टारगेट की जगह को बताने वाली एक स्ट्रिंग से शुरू होता है, जैसे कि फ़ाइल का नाम और लाइन का नंबर. फ़ॉर्मैट, grep के आउटपुट जैसा दिखता है. इस तरह, बाद के नतीजों (जैसे, Emacs या vi) को पार्स करने वाले टूल भी मिलते-जुलते वीडियो की सीरीज़ पर जाने के लिए क्वेरी आउटपुट का इस्तेमाल कर सकते हैं. इससे, Bazel क्वेरी टूल का इस्तेमाल, "BUILD फ़ाइलों के लिए डिपेंडेंसी-ग्राफ़-अवेयर" ग्रेप के तौर पर किया जा सकता है.

टारगेट करने का तरीका, टारगेट करने के तरीके के हिसाब से अलग-अलग होता है (kind ऑपरेटर देखें). नियमों के लिए, BUILD फ़ाइल में नियम के एलान की जगह को प्रिंट किया जाता है. सोर्स फ़ाइलों के लिए, असल फ़ाइल की लाइन 1 की जगह प्रिंट की जाती है. जनरेट की गई फ़ाइल के लिए, उसे जनरेट करने वाले नियम की जगह की जानकारी प्रिंट की जाती है. (क्वेरी टूल में जनरेट की गई फ़ाइल का असल स्थान ढूंढने के लिए काफ़ी जानकारी नहीं है, और किसी भी स्थिति में यह मौजूद नहीं हो सकता है अगर बिल्ड का काम अभी तक नहीं हुआ है.)

पैकेज का सेट प्रिंट करें

--output package

यह विकल्प, ऐसे सभी पैकेज के नाम को प्रिंट करता है जो नतीजों के सेट में मौजूद कुछ टारगेट से जुड़े हैं. नामों को लेगसी क्रम में प्रिंट किया जाता है; डुप्लीकेट शामिल नहीं किए जाते हैं. औपचारिक रूप से, यह पैकेज पर (लेबल, टारगेट) सेट से पैकेज पर अनुमान है.

बाहरी डेटा स्टोर करने की जगह में पैकेज को @repo//foo/bar के तौर पर फ़ॉर्मैट किया जाता है, जबकि मुख्य डेटा स्टोर करने की जगह में पैकेज को foo/bar के तौर पर फ़ॉर्मैट किया जाता है.

deps(...) क्वेरी के साथ, इस आउटपुट विकल्प का इस्तेमाल करके पैकेज का एक सेट ढूंढा जा सकता है. टारगेट का कोई सेट बनाने के लिए, इस सेट के लिए चेकआउट करना ज़रूरी है.

नतीजे का ग्राफ़ दिखाएं

--output graph

इस विकल्प की वजह से, क्वेरी का नतीजा लोकप्रिय AT&T ग्राफ़वीज़ फ़ॉर्मैट में ग्राफ़ के रूप में प्रिंट होता है. आम तौर पर, नतीजे को फ़ाइल में सेव किया जाता है, जैसे कि .png या .svg. (अगर आपके वर्कस्टेशन पर dot प्रोग्राम इंस्टॉल नहीं किया गया है, तो sudo apt-get install graphviz निर्देश का इस्तेमाल करके उसे इंस्टॉल किया जा सकता है.) सैंपल शुरू करने के लिए, नीचे दिया गया उदाहरण देखें.

यह आउटपुट फ़ॉर्मैट खास तौर पर allpaths, deps या rdeps क्वेरी के लिए कारगर है, जिसके नतीजे में पाथ का सेट शामिल होता है. इसे लीनियर फ़ॉर्म में रेंडर करते समय, आसानी से विज़ुअलाइज़ नहीं किया जा सकता. जैसे, --output label के साथ रेंडर करना.

डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर किए गए रूप में रेंडर होता है. इसका मतलब है कि क्यूपोलॉजिकल तौर पर बराबर नोड को एक नोड में एक साथ लेबल कर दिया जाता है. यह ग्राफ़ को ज़्यादा छोटा और पढ़ने लायक बनाता है, क्योंकि आम तौर पर दिखने वाले नतीजों के ग्राफ़ में बहुत बार-बार एक ही पैटर्न होता है. उदाहरण के लिए, java_library नियम उन सभी Java सोर्स फ़ाइलों पर निर्भर हो सकता है जो एक ही genrule से जनरेट होती हैं. हालांकि, फ़ैक्टर के ग्राफ़ में ये सभी फ़ाइलें एक नोड से दिखती हैं. --nograph:factored विकल्प की मदद से, इस व्यवहार को बंद किया जा सकता है.

--graph:node_limit n

यह विकल्प, आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई बताता है. लंबे लेबल छोटे कर दिए जाएंगे; -1 काट-छांट बंद कर देता है. नोड के लेबल की लंबाई बहुत ज़्यादा होने की वजह से, आम तौर पर ग्राफ़ प्रिंट होते हैं. ग्राफ़वीज़ 1024 वर्णों से बड़े लेबल प्रबंधित नहीं कर सकता, जो इस विकल्प का डिफ़ॉल्ट मान है. इस विकल्प का तब तक असर नहीं होता, जब तक --output=graph का इस्तेमाल नहीं किया जाता.

--[no]graph:factored

डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर के रूप में दिखाए जाते हैं, जैसा कि ऊपर बताया गया है. --nograph:factored तय होने पर, ग्राफ़ को फ़ैक्टर किए बिना प्रिंट किया जाता है. इससे ग्राफ़वीज़ का इस्तेमाल करने वाला विज़ुअलाइज़ेशन मुश्किल होता है, लेकिन आसान फ़ॉर्मैट को दूसरे टूल (जैसे कि ग्रेप) से प्रोसेस करना आसान हो सकता है. इस विकल्प का कोई असर नहीं होता जब तक --output=graph का इस्तेमाल नहीं किया जाता.

एक्सएमएल

--output xml

इस विकल्प की वजह से नतीजे, टारगेट को एक्सएमएल फ़ॉर्म में प्रिंट होते हैं. आउटपुट किसी XML हेडर से शुरू होता है, जैसे कि

  <?xml version="1.0" encoding="UTF-8"?>
  <query version="2">

और उसके बाद यह ग्राफ़ में नतीजों के हर टारगेट के लिए, एक्सएमएल एलिमेंट के साथ जारी रहता है (जब तक बिना क्रम के नतीजे का अनुरोध न किया जाए) और फिर सेशन को खत्म करता है

</query>

file टाइप के टारगेट के लिए, आसान एंट्री की जाती हैं:

  <source-file name='//foo:foo_main.cc' .../>
  <generated-file name='//foo:libfoo.so' .../>

हालांकि, नियमों के लिए एक्सएमएल स्ट्रक्चर्ड होता है. इसमें नियम की सभी विशेषताओं की जानकारी होती है. इसमें वे मान भी शामिल होते हैं जिनके बारे में नियम की BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया था.

इसके अलावा, नतीजे में rule-input और rule-output एलिमेंट शामिल होते हैं, ताकि डिपेंडेंसी ग्राफ़ के टोपोलॉजी को नए तरीके से बनाया जा सकता है. उदाहरण के लिए, srcs एट्रिब्यूट के एलिमेंट, फ़ॉरवर्ड डिपेंडेंसी (ज़रूरी शर्तें) होते हैं और outs एट्रिब्यूट के कॉन्टेंट, पुराने डिपेंडेंसी होते हैं.

अगर --noimplicit_deps साफ़ तौर पर बताया गया है, तो निर्भर डिपेंडेंसी के लिए rule-input एलिमेंट छिपा दिए जाते हैं.

  <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>

टारगेट के हर एक्सएमएल एलिमेंट में एक name एट्रिब्यूट होता है, जिसकी वैल्यू टारगेट का लेबल होती है. साथ ही, एक location एट्रिब्यूट होता है, जिसकी वैल्यू टारगेट की गई जगह की जानकारी होती है, जिसे --output location ने प्रिंट किया है.

--[no]xml:line_numbers

डिफ़ॉल्ट रूप से, एक्सएमएल आउटपुट में दिखाई गई जगहों पर लाइन नंबर होते हैं. --noxml:line_numbers तय होने पर, लाइन नंबर प्रिंट नहीं किए जाते.

--[no]xml:default_values

डिफ़ॉल्ट रूप से, एक्सएमएल आउटपुट में वह नियम विशेषता शामिल नहीं होती जिसका मान उस तरह की विशेषता के लिए डिफ़ॉल्ट मान होता है (उदाहरण के लिए, अगर उसे BUILD फ़ाइल में बताया नहीं गया हो या डिफ़ॉल्ट मान साफ़ तौर पर दिया गया हो). इस विकल्प की वजह से, एक्सएमएल आउटपुट में ऐसे एट्रिब्यूट की वैल्यू शामिल हो जाती हैं.

रेगुलर एक्सप्रेशन

क्वेरी लैंग्वेज में रेगुलर एक्सप्रेशन, Java रेगुलर एक्सप्रेशन लाइब्रेरी का इस्तेमाल करते हैं, ताकि आप java.util.regex.Pattern के लिए, पूरे सिंटैक्स का इस्तेमाल कर सकें.

डेटा स्टोर करने की बाहरी जगह से क्वेरी करना

अगर बिल्ड एक्सटर्नल रिपॉज़िटरी (WorkSPACE फ़ाइल में बताई गई) के नियमों पर निर्भर करता है, तो क्वेरी के नतीजों में ये डिपेंडेंसी शामिल होंगी. उदाहरण के लिए, अगर //foo:bar, //external:some-lib पर निर्भर है और //external:some-lib को @other-repo//baz:lib से जोड़ा गया है, तो bazel query 'deps(//foo:bar)', @other-repo//baz:lib और //external:some-lib, दोनों को डिपेंडेंसी के तौर पर दिखाएगा.

डेटा स्टोर करने की जगह, किसी डिपेंडेंसी पर निर्भर नहीं करती है. इसका मतलब है कि ऊपर दिए गए उदाहरण में, //external:other-repo एक डिपेंडेंसी नहीं है. //external के सदस्य के तौर पर, इस क्वेरी के बारे में क्वेरी की जा सकती है. उदाहरण के लिए,

  # 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