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

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

व्यावहारिक इस्तेमाल के उदाहरणों के लिए, Bazel Query कैसे करें देखें.

अतिरिक्त क्वेरी रेफ़रंस

पोस्ट-लोडिंग फ़ेज़ टारगेट ग्राफ़ पर चलने वाले query के अलावा, Bazel में ऐक्शन ग्राफ़ क्वेरी और कॉन्फ़िगर की जा सकने वाली क्वेरी शामिल होती हैं.

कार्रवाई ग्राफ़ क्वेरी

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

ज़्यादा जानकारी के लिए, क्वेरी रेफ़रंस देखें.

कॉन्फ़िगर की जा सकने वाली क्वेरी

ट्रेडिशनल Bazel क्वेरी, लोड होने के बाद के फ़ेज़ के टारगेट ग्राफ़ पर चलती है. इसलिए, इसमें कॉन्फ़िगरेशन और उनसे जुड़े कॉन्सेप्ट का कोई कॉन्सेप्ट नहीं होता. खास तौर पर, यह select स्टेटमेंट का सही तरीके से समाधान नहीं करता है. इसके बजाय, यह चुने गए विकल्पों के सभी संभावित रिज़ॉल्यूशन दिखाता है. हालांकि, कॉन्फ़िगर किया जा सकने वाला क्वेरी एनवायरमेंट, cquery, कॉन्फ़िगरेशन को ठीक से मैनेज करता है. हालांकि, इसमें इस ओरिजनल क्वेरी की सभी सुविधाएं उपलब्ध नहीं होती हैं.

ज़्यादा जानकारी के लिए, cquery रेफ़रंस देखें.

उदाहरण

लोग bazel query का इस्तेमाल कैसे करते हैं? यहां कुछ सामान्य उदाहरण दिए गए हैं:

//foo ट्री, //bar/baz पर क्यों निर्भर करता है? कोई पाथ दिखाएं:

somepath(foo/..., //bar/baz:all)

ऐसी कौनसी C++ लाइब्रेरी हैं जिनका इस्तेमाल foo के लिए किया जाने वाला टेस्ट, इस बात पर निर्भर करता है कि foo_bin टारगेट काम नहीं करता?

kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))

टोकन: लेक्सिकल सिंटैक्स

क्वेरी भाषा में एक्सप्रेशन यहां दिए गए टोकन से बने होते हैं:

• कीवर्ड, जैसे कि let. कीवर्ड, भाषा के रिज़र्व शब्द होते हैं और उनमें से हर एक के बारे में नीचे बताया गया है. कीवर्ड का पूरा सेट है:

  • except

  • in

  • intersect

  • let

  • set

  • union

• शब्द, जैसे कि "foo/...", ".*test rule" या "//bar/baz:all". अगर वर्ण का क्रम "कोट" है (जो सिंगल-कोटेशन ' से शुरू और खत्म होता है या दो कोट से शुरू और खत्म होता है "), तो यह एक शब्द है. अगर कोई वर्ण क्रम कोट नहीं किया गया है, तो इसे अब भी शब्द के तौर पर पार्स किया जा सकता है. बिना कोट वाले शब्द, कैरेक्टर A-Za-z, अंक 0-9, और खास वर्ण */@.-_:$~[] (तारे का निशान, फ़ॉरवर्ड स्लैश, at, पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर साइन, टिल्ड, लेफ़्ट स्क्वेयर ब्रेस, राइट स्क्वेयर ब्रेस) से जुड़े क्रम होते हैं. हालांकि, बिना कोट वाले शब्द हाइफ़न - या स्टार के निशान * से शुरू नहीं हो सकते. भले ही, मिलते-जुलते टारगेट नेम उन वर्णों से शुरू हों.

  बिना कोट वाले शब्दों में, वर्ण के साथ-साथ + या इसके बराबर का निशान = भी नहीं होना चाहिए. हालांकि, टारगेट के नामों में उन वर्णों की अनुमति भी होती है. क्वेरी एक्सप्रेशन जनरेट करने वाला कोड लिखते समय, टारगेट नाम कोट किए जाने चाहिए.

  ऐसी स्क्रिप्ट लिखते समय कोट करना ज़रूरी है जिसमें उपयोगकर्ता से दी गई वैल्यू से Bazel क्वेरी एक्सप्रेशन बनाए जाते हैं.

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

  ध्यान दें कि यह उद्धरण ऐसे किसी भी उद्धरण के अतिरिक्त है, जो आपके शेल के लिए ज़रूरी हो सकता है, जैसे:

  bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
  

  कोट किए जाने पर कीवर्ड और ऑपरेटर को सामान्य शब्द माना जाता है. उदाहरण के लिए, some एक कीवर्ड है, लेकिन "कुछ" शब्द है. foo और "foo", दोनों ही शब्द हैं.

  हालांकि, टारगेट के नामों में सिंगल या डबल कोट का इस्तेमाल करते समय सावधानी बरतें. एक या एक से ज़्यादा टारगेट नामों को कोट करते समय, सिर्फ़ एक तरह के कोट का इस्तेमाल करें (सभी एक या सभी डबल कोट).

  नीचे दिए गए उदाहरण के ज़रिए बताया गया है कि Java क्वेरी स्ट्रिंग क्या होगी:

    '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
  

  हमने यह सिंटैक्स इसलिए चुना है, ताकि ज़्यादातर मामलों में कोटेशन मार्क की ज़रूरत न पड़े. ".*test rule" के (असामान्य) उदाहरण में कोट की ज़रूरत है: यह पीरियड से शुरू होता है और इसमें स्पेस होता है. "cc_library" को कोट करना ज़रूरी नहीं है. हालांकि, इससे कोई नुकसान नहीं होता.

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

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

Bazel की क्वेरी भाषा के सिद्धांत

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

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

• सेट करें: टारगेट का आंशिक क्रम दिलचस्प नहीं है.
• ग्राफ़: टारगेट का आंशिक क्रम अहम है.

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

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

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

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

BUILD फ़ाइलों में साफ़ तौर पर तय की गई बिल्ड डिपेंडेंसी के अलावा, Bazel नियमों में अतिरिक्त इंप्लिसिट डिपेंडेंसी जोड़ता है. इंप्लिसिट डिपेंडेंसी इन तरीकों से तय की जा सकती हैं:

• निजी एट्रिब्यूट
• टूलचेन की ज़रूरी शर्तें

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

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

आवाज़

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

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

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

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

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

deps(x) union y

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

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

स्काई क्वेरी

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

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

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

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

Sky क्वेरी मोड को इन दो फ़्लैग को पास करके चालू किया जाता है: (--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 इस्तेमाल करने का विकल्प है. खास तौर पर, ऐसे मामलों में जहां --universe_scope चुनने का विकल्प होता है. ऐसे में, आपको क्वेरी एक्सप्रेशन को खुद ही पार्स करने की ज़रूरत होगी.

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

डिफ़ॉल्ट क्वेरी की तुलना में, Sky Query के कुछ फ़ायदे और नुकसान हैं. इसका मुख्य नुकसान यह है कि इसमें आउटपुट को ग्राफ़ के क्रम के हिसाब से क्रम में नहीं लगाया जा सकता. इसलिए, कुछ आउटपुट फ़ॉर्मैट इस्तेमाल नहीं किए जा सकते. इसका फ़ायदा यह है कि इससे दो ऑपरेटर (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, शब्द की तरह है. हालांकि, इसकी एक सीमा है कि यह सी प्रोग्रामिंग भाषा में एक कानूनी आइडेंटिफ़ायर है. वैरिएबल के रेफ़रंस को, "$" वर्ण से पहले जोड़ा जाना चाहिए.

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

रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: 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, E के किसी भी टारगेट पर ले जाने वाले, S के सभी पाथ के नोड का ग्राफ़ दिखाता है.

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

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

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

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

नियम एट्रिब्यूट को फ़िल्टर करना: 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 x में मौजूद सभी टारगेट y के लिए 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 को बड़ा और फ़िल्टर करें: टेस्ट

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 फ़ाइल टारगेट शामिल हो सकते हैं और बाद में ऐसे टारगेट शामिल हो सकते हैं. दूसरी दिशा में, बातचीत कमज़ोर है. buildfiles ऑपरेटर के आउटपुट, सभी पैकेज और .bzl फ़ाइलें, किसी दिए गए इनपुट के लिए ज़रूरी हैं. हालांकि, rbuildfiles ऑपरेटर के इनपुट वे टारगेट नहीं हैं, बल्कि ये टारगेट से जुड़े पाथ फ़्रैगमेंट हैं.

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

expr ::= loadfiles(expr)

loadfiles(x) ऑपरेटर, Starlark फ़ाइलों का वह सेट दिखाता है जो सेट x में, हर टारगेट के पैकेज को लोड करने के लिए ज़रूरी होती है. दूसरे शब्दों में, हर पैकेज के लिए, यह अपनी 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 भाषा में हाथ से लिखा गया हो. सभी वैरिएबल और फ़ंक्शन कॉल (जैसे कि ग्लोब, मैक्रो) का दायरा बढ़ाया जाता है. इससे स्टारलार्क मैक्रो का असर देखने में मदद मिलती है. इसके अलावा, हर असरदार नियम 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 proto

क्वेरी आउटपुट को QueryResult प्रोटोकॉल के बफ़र के तौर पर प्रिंट करता है.

टारगेट को लंबाई-सीमांकित प्रोटोकॉल बफ़र फ़ॉर्मैट में प्रिंट करें

--output streamed_proto

Target प्रोटोकॉल बफ़र की अवधि-सीमांकित स्ट्रीम को प्रिंट करता है. यह (i) प्रोटोकॉल बफ़र के साइज़ की सीमाओं के बारे में जानने के लिए काम का होता है, जब एक QueryResult या (ii) में फ़िट करने के लिए बहुत ज़्यादा टारगेट मौजूद हों. ऐसा तब होता है, जब Bazel अभी आउटपुट कर रहा हो.

टारगेट को टेक्स्ट प्रोटो फ़ॉर्मैट में प्रिंट करें

--output textproto

--output proto की तरह ही, प्रोटोकॉल QueryResult प्रोटोकॉल का बफ़र प्रिंट करता है, लेकिन यह टेक्स्ट फ़ॉर्मैट में होता है.

टारगेट को ndjson फ़ॉर्मैट में प्रिंट करें

--output streamed_jsonproto

--output streamed_proto की तरह ही, Target प्रोटोकॉल बफ़र की स्ट्रीम को ndjson फ़ॉर्मैट में प्रिंट किया जाता है.

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

--output minrank --output maxrank

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

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

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

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

इन आउटपुट फ़ॉर्मैट से यह पता लगाया जा सकता है कि ग्राफ़ कितना गहरा है. अगर इसका इस्तेमाल deps(x), rdeps(x) या allpaths क्वेरी के नतीजे के लिए किया जाता है, तो रैंक नंबर सबसे छोटे (minrank के साथ) या maxrank के साथ (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 फ़ाइलों के लिए ग्रेप" के तौर पर इस्तेमाल करने में मदद मिलती है.

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

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

--output package

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

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

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

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

--output graph

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

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

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

--graph:node_limit n

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

--[no]graph:factored

जैसा कि ऊपर बताया गया है, डिफ़ॉल्ट रूप से ग्राफ़, फ़ैक्टर किए गए फ़ॉर्मैट में दिखाए जाते हैं. जब --nograph:factored बताया जाता है, तो ग्राफ़ को फ़ैक्टरिंग के बिना प्रिंट किया जाता है. इससे GraViz का इस्तेमाल करके विज़ुअलाइज़ेशन करना संभव नहीं होता, लेकिन आसान फ़ॉर्मैट वाले फ़ॉर्मैट से दूसरे टूल (जैसे कि ग्रेप) की मदद से प्रोसेस करना आसान हो जाता है. इस विकल्प का तब तक कोई असर नहीं होगा, जब तक कि --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 के लिए पूरे सिंटैक्स का इस्तेमाल कर सकें.

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

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