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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

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

इस्तेमाल के तरीकों के बारे में जानने के लिए, Bazel Query कैसे करें देखें.

क्वेरी का अन्य रेफ़रंस

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

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

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

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

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

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

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

उदाहरण

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

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

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

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

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

टोकन: lexical सिंटैक्स

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

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

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

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

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

     //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" का नाम देना ज़रूरी नहीं है, लेकिन इससे कोई नुकसान नहीं होगा.

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

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

बेज़ल क्वेरी लैंग्वेज के सिद्धांत

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

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

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

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

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

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

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

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

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

आवाज़

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

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

ग्राफ़ ऑर्डर को सुरक्षित रखना

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

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

deps(x) union y

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

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

Sky क्वेरी

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

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

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

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

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

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) उपलब्ध कराता है, जो डिफ़ॉल्ट क्वेरी के तौर पर उपलब्ध नहीं होते हैं. इसी तरह, स्काई क्वेरी एक नया ग्राफ़ बनाने के बजाय स्काईफ़्रेम ग्राफ़ की जांच करके अपना काम करती है, जो डिफ़ॉल्ट तरीके से लागू किया जाता है. इसलिए, कुछ ऐसी स्थितियां होती हैं जिनमें यह ज़्यादा तेज़ होता है और कम मेमोरी का इस्तेमाल करता है.

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

यह बेज़ल क्वेरी भाषा का व्याकरण है, जिसे 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 एक्सप्रेशन का इवैलुएशन, expr2 के नतीजे जैसा ही होता है. इसमें वैरिएबल के सभी मुफ़्त इंस्टेंस को expr1 की वैल्यू से बदल दिया जाता है.

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

वैरिएबल name के बगल में let 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 ... ')'

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

डिपेंडेंसी का ट्रांज़िटिव कनेक्शन: गिरावट

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

deps(x) ऑपरेटर, ग्राफ़ के मूल्यांकन के लिए बने ग्राफ़ को उसके आर्ग्युमेंट सेट x की डिपेंडेंसी को ट्रांज़िट समय में बंद करता है. उदाहरण के लिए, deps(//foo) की वैल्यू एक डिपेंडेंसी ग्राफ़ पर आधारित होती है. यह नोड foo पर निर्भर करता है. deps(foo/...) का मान डिपेंडेंसी ग्राफ़ है. इसके रूट, foo डायरेक्ट्री के नीचे मौजूद हर पैकेज के सभी नियम हैं. इस संदर्भ में, 'डिपेंडेंसी' का मतलब है कि सिर्फ़ नियम और फ़ाइल टारगेट हैं. इसलिए, ये टारगेट बनाने के लिए BUILD और स्टारलार्क फ़ाइलें यहां शामिल नहीं हैं. इसके लिए, आपको 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 में, किसी भी टारगेट से Sसभी पाथ के नोड के ग्राफ़ को E में मौजूद किसी भी टारगेट में दिखाता है.

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

सोमपाथ
somepath(S1 + S2, E), एक नतीजा.
सोमपाथ
somepath(S1 + S2, E), एक और संभावित नतीजा.
पाथ
allpaths(S1 + S2, E)

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

expr ::= kind(word, expr)

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

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

कोड टारगेट तरह
        genrule(
            name = "a",
            srcs = ["a.in"],
            outs = ["a.out"],
            cmd = "...",
        )
      
//p:a नियम लागू करें
//p:a.in सोर्स फ़ाइल
//p:a.out जनरेट की गई फ़ाइल
//p:BUILD सोर्स फ़ाइल

इस तरह, kind("cc_.* rule", foo/...), foo के नीचे दिए गए सभी cc_library, cc_binary वगैरह नियम टारगेट के सेट का आकलन करता है. साथ ही, //foo टारगेट की निर्भरता के ट्रांज़िशन के दौरान सभी सोर्स फ़ाइलों के सेट का मूल्यांकन करता है.

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

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

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

expr ::= filter(word, expr)

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

पहला आर्ग्युमेंट pattern ऐसा शब्द है जिसमें टारगेट नामों पर सामान्य एक्सप्रेशन शामिल है. filter एक्सप्रेशन, x वाले सभी टारगेट वाले सेट की जांच करता है, ताकि 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)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 के नियमों के ज़रिए सीधे तौर पर या किसी दूसरे तरीके से इस्तेमाल किया गया है.

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

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 टारगेट के साथ-साथ ऐसी दूसरी 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 में हर टारगेट के पैकेज को लोड करने की ज़रूरत होती है. दूसरे शब्दों में, यह हर पैकेज के लिए, अपनी BUILD फ़ाइलों से जुड़ी .bzl फ़ाइलें दिखाता है.

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

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

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

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

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

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

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

--graph:node_limit n

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

--[no]graph:factored

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

एक्सएमएल

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