Bazel क्वेरी का संदर्भ

कोट किए गए शब्द के बाहर मौजूद खाली जगह को अनदेखा कर दिया जाता है.

Bazel क्वेरी लैंग्वेज के कॉन्सेप्ट

Bazel क्वेरी लैंग्वेज, एक्सप्रेशन की भाषा है. हर एक्सप्रेशन, टारगेट के कुछ हद तक क्रम में लगाए गए सेट या टारगेट के ग्राफ़ (डीएजी) के तौर पर दिखता है. यह एकमात्र डेटाटाइप है.

सेट और ग्राफ़, एक ही डेटा टाइप का रेफ़रंस देते हैं. हालांकि, ये इसके अलग-अलग पहलुओं पर ज़ोर देते हैं. उदाहरण के लिए:

• सेट: टारगेट का कुछ हिस्सा क्रम में नहीं है.
• ग्राफ़: टारगेट का क्रम अहम होता है.

डिपेंडेंसी ग्राफ़ में साइकल

बिल्ड डिपेंडेंसी ग्राफ़, ऐसाइकल होने चाहिए.

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

इंप्लिसिट डिपेंडेंसी

BUILD फ़ाइलों में साफ़ तौर पर बताई गई बिल्ड डिपेंडेंसी के अलावा, Bazel नियमों में अनजान डिपेंडेंसी भी जोड़ता है. उदाहरण के लिए, हर Java नियम, JavaBuilder पर निर्भर करता है. $ से शुरू होने वाले एट्रिब्यूट का इस्तेमाल करके, डिफ़ॉल्ट डिपेंडेंसी तय की जाती हैं. साथ ही, BUILD फ़ाइलों में इन्हें बदला नहीं जा सकता.

डिफ़ॉल्ट रूप से, bazel query क्वेरी के नतीजे का हिसाब लगाते समय, डिपेंडेंसी को ध्यान में रखता है. --[no]implicit_deps विकल्प की मदद से, इस व्यवहार को बदला जा सकता है. ध्यान दें कि क्वेरी में कॉन्फ़िगरेशन को शामिल नहीं किया जाता है. इसलिए, संभावित टूलचेन को कभी भी शामिल नहीं किया जाता.

सही होना

Bazel क्वेरी लैंग्वेज एक्सप्रेशन, बिल्ड डिपेंडेंसी ग्राफ़ पर काम करते हैं. यह ग्राफ़, सभी BUILD फ़ाइलों में मौजूद सभी नियमों के एलान से अपने-आप तय होता है. यह समझना ज़रूरी है कि यह ग्राफ़ कुछ हद तक अस्पष्ट है. इसमें, किसी बिल्ड के सभी चरणों को पूरा करने का तरीका पूरी तरह से नहीं बताया गया है. बाइल्ड करने के लिए, कॉन्फ़िगरेशन भी ज़रूरी है. ज़्यादा जानकारी के लिए, उपयोगकर्ता गाइड का configurations सेक्शन देखें.

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

ग्राफ़ के क्रम को बनाए रखने के बारे में जानकारी

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

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

deps(x) union y

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

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

आसमान से जुड़ी क्वेरी

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

सिर्फ़ SkyQuery में उपलब्ध खास फ़ंक्शन

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

यूनिवर्स का स्कोप तय करना

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

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

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

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 एक सुविधा है. खास तौर पर, ऐसे मामले में जहां --infer_universe_scope के विकल्प के लिए, आपको क्वेरी एक्सप्रेशन को खुद पार्स करना होगा.--universe_scope

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

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

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

यह Bazel क्वेरी लैंग्वेज का व्याकरण है, जिसे ईबीएनएफ़ नोटेशन में दिखाया गया है:

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/... के बराबर है.

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

ऊपर दिए गए व्याकरण के प्रॉडक्शन में, name word की तरह है. हालांकि, इसमें एक और शर्त है कि यह 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 ...) ऑपरेटर, शून्य या एक से ज़्यादा टारगेट पैटर्न के सेट का यूनियन कैलकुलेट करता है. इन पैटर्न को स्पेस (कोमा नहीं) से अलग किया जाता है.

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

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 पैरामीटर को छोड़ दिया जाता है, तो खोज के लिए कोई सीमा नहीं होती: यह ज़रूरी शर्तों के रिफ़्लेक्सिव ट्रांसीटिव क्लोज़र का हिसाब लगाता है.

रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: rdeps

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

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

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

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) एक्सप्रेशन में.

पाथ ऑपरेटर: somepath, allpaths

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

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

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

टारगेट टाइप के हिसाब से फ़िल्टर करना: kind

expr ::= kind(word, expr)

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

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

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

इसलिए, kind("cc_.* rule", foo/...) का आकलन, foo के नीचे मौजूद सभी cc_library, cc_binary वगैरह नियम टारगेट के सेट के हिसाब से किया जाता है. साथ ही, 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 के लेबल (जैसे, //foo:bar के सटीक फ़ॉर्म में) में रेगुलर एक्सप्रेशन 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))

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

सूची वाले एट्रिब्यूट में, किसी खास value के साथ //foo डिपेंडेंसी में से सभी नियम चुनने के लिए,

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

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

नियम के दिखने की सेटिंग: दिख रहा है

expr ::= visible(expr, expr)

visible(predicate, input) ऑपरेटर, टारगेट के सेट पर फ़िल्टर लागू करता है और ज़रूरी विज़िबिलिटी के बिना टारगेट को खारिज कर देता है.

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

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

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

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

expr ::= labels(word, expr)

labels(attr_name, inputs) ऑपरेटर, सेट inputs के किसी नियम में "लेबल" या "लेबल की सूची" टाइप के एट्रिब्यूट attr_name में बताए गए टारगेट का सेट दिखाता है.

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

test_suites: tests को बड़ा करना और फ़िल्टर करना

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 नियमों के ज़रिए सीधे या अप्रत्यक्ष तौर पर दिया गया हो.

पैकेज की परिभाषा वाली फ़ाइलें: बिल्डफ़ाइलें

expr ::= buildfiles(expr)

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

आम तौर पर, इस ऑपरेटर का इस्तेमाल तब किया जाता है, जब यह तय करना हो कि किसी खास टारगेट को बनाने के लिए कौनसी फ़ाइलें या पैकेज ज़रूरी हैं. आम तौर पर, इसका इस्तेमाल --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 टारगेट के साथ-साथ, //bar:file.bzl को लोड करने वाली किसी भी अन्य BUILD फ़ाइल के टारगेट भी दिखाएगा

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

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

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

expr ::= loadfiles(expr)

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

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

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

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 में से कोई एक हो, तब यह काम नहीं करता: इन फ़ॉर्मैट में, Bazel हमेशा नतीजों को डिपेंडेंसी के क्रम या रैंक के हिसाब से प्रिंट करता है.

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

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

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

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

--output build

इस विकल्प की मदद से, हर टारगेट को वैसे दिखाया जाता है जैसे कि उसे BUILD भाषा में हाथ से लिखा गया हो. सभी वैरिएबल और फ़ंक्शन कॉल (जैसे, glob, मैक्रो) को बड़ा किया जाता है. इससे Starlark मैक्रो के असर को देखने में मदद मिलती है. इसके अलावा, हर लागू नियम में एक 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 क्वेरी के नतीजे के लिए किया जाता है, तो रैंक नंबर, x से उस रैंक में मौजूद किसी नोड तक के सबसे छोटे (minrank के साथ) या सबसे लंबे (maxrank के साथ) पाथ की लंबाई के बराबर होता है. 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 फ़ाइलों के लिए grep" के तौर पर किया जा सकता है.

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

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

--output package

यह विकल्प उन सभी पैकेज का नाम प्रिंट करता है जिनमें नतीजे के सेट का कोई टारगेट शामिल है. नामों को वर्णमाला के क्रम में प्रिंट किया जाता है. डुप्लीकेट नाम शामिल नहीं किए जाते. औपचारिक तौर पर, यह लेबल (पैकेज, टारगेट) के सेट से पैकेज पर प्रोजेक्ट है.

बाहरी रिपॉज़िटरी में मौजूद पैकेज, @repo//foo/bar के तौर पर फ़ॉर्मैट किए जाते हैं. वहीं, मुख्य रिपॉज़िटरी में मौजूद पैकेज, foo/bar के तौर पर फ़ॉर्मैट किए जाते हैं.

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

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

--output graph

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

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

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

--graph:node_limit n

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

--[no]graph:factored

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

XML

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