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

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

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

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

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

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

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

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

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

ट्रेडिशनल Bazel क्वेरी, पोस्ट-लोडिंग फ़ेज़ टारगेट ग्राफ़ पर चलती है. इसलिए, इसमें कॉन्फ़िगरेशन और उनसे जुड़े कॉन्सेप्ट का कोई कॉन्सेप्ट नहीं है. खास तौर पर, यह चुने गए स्टेटमेंट का ठीक से समाधान नहीं करता है. इसके बजाय, यह चुनिंदा विकल्पों के सभी संभावित रिज़ॉल्यूशन दिखाता है. हालांकि, कॉन्फ़िगर किया जा सकने वाला क्वेरी एनवायरमेंट, 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, और विशेष वर्ण */@.-_:$~[] (तारक, फ़ॉरवर्ड स्लैश, , पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर चिह्न, टिल्ड, लेफ़्ट स्क्वेयर ब्रेस, राइट स्क्वेयर ब्रैस) से लिया गया है. हालांकि, बिना कोट वाले शब्दों की शुरुआत हाइफ़न - या स्टार * से नहीं हो सकती. भले ही, मिलते-जुलते [टारगेट नेम][(/Concepts/labels#target-names) की शुरुआत इन वर्णों से ही हो.

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

  ऐसी स्क्रिप्ट लिखते समय कोट करना ज़रूरी है जो उपयोगकर्ता की ओर से दी गई वैल्यू से 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 नियमों में अतिरिक्त इंप्लिसिट डिपेंडेंसी जोड़ता है. उदाहरण के लिए, Java का हर नियम, साफ़ तौर पर JavaBuilder पर निर्भर करता है. इंप्लिसिट डिपेंडेंसी $ से शुरू होने वाले एट्रिब्यूट का इस्तेमाल करके बनाई जाती हैं. इन्हें BUILD फ़ाइलों में नहीं बदला जा सकता.

हर डिफ़ॉल्ट क्वेरी के नतीजे की गणना करते समय 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 Query क्वेरी का एक मोड है जो एक खास यूनिवर्सल स्कोप पर काम करता है.

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

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

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

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

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

expr ::= (expr)

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

बीजीय सेट ऑपरेशन: चौराहा, यूनियन, सेट डिफ़रेंस

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

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

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

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

इसका आकलन उन टारगेट के सेट के आधार पर किया जाता है जो foo/... से मैच करते हैं, लेकिन foo/bar/... से नहीं.

आप इस तरह एक ही क्वेरी लिख सकते हैं:

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

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

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

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

expr ::= set(word *)

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

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

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

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

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

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

फ़ंक्शन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

expr ::= same_pkg_direct_rdeps(expr)

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

टारगेट के पैकेज को हैंडल करना: भाई-बहन

expr ::= siblings(expr)

siblings(x) ऑपरेटर, टारगेट के उन पूरे सेट का आकलन करता है जो तर्क सेट में मौजूद टारगेट के पैकेज में मौजूद होते हैं.

आर्बिट्रेरी पसंद: कुछ

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

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

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

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

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

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

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

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

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

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

expr ::= kind(word, expr)

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

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

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

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

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

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

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

expr ::= filter(word, expr)

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

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

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

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

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

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

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

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

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

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

नियम एट्रिब्यूट को फ़िल्टर करना: attr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

expr ::= visible(expr, expr)

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

पहला आर्ग्युमेंट, predicate, टारगेट का एक सेट है. आउटपुट में मौजूद सभी टारगेट, लोगों को दिखने चाहिए. visible एक्सप्रेशन उस सेट का आकलन करता है जिसमें सभी टारगेट x हैं. इससे पता चलता है कि x, सेट input का सदस्य है और predicate 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 सेट में मौजूद हर टारगेट के पैकेज को लोड करने के लिए ज़रूरी है. दूसरे शब्दों में, हर पैकेज के लिए, यह .bzl फ़ाइलें दिखाता है, जो उसकी BUILD फ़ाइलों से रेफ़र होती हैं.

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

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

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

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

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

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

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

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

minrank 0 //c:c 1 //b:b 1 //a:a 2 //b:b.cc 2 //a:a.cc

maxrank 0 //c:c 1 //b:b 2 //a:a 2 //b:b.cc 3 //a:a.cc

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

--output location

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

जगह की जानकारी, टारगेट टाइप के हिसाब से अलग-अलग होती है (तरह ऑपरेटर देखें). नियमों के लिए, 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, काट-छांट को बंद कर देता है. आम तौर पर ग्राफ़ प्रिंट किए जाने वाले फ़ैक्टरेड फ़ॉर्म की वजह से, नोड लेबल बहुत लंबे हो सकते हैं. ग्राफ़Viz, 1024 से ज़्यादा वर्णों वाले लेबल को हैंडल नहीं कर सकता, जो कि इस विकल्प की डिफ़ॉल्ट वैल्यू है. यह विकल्प तब तक काम नहीं करेगा, जब तक --output=graph का इस्तेमाल नहीं किया जाता.

--[no]graph:factored

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

XML

--output xml

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

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

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

</query>

सामान्य एंट्री, file तरह के टारगेट के लिए भेजी जाती हैं:

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

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

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

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

  <rule class='cc_binary rule' name='//foo:foo' ...>
    <list name='srcs'>
      <label value='//foo:foo_main.cc'/>
      <label value='//foo:bar.cc'/>
      ...
    </list>
    <list name='deps'>
      <label value='//common:common'/>
      <label value='//collections:collections'/>
      ...
    </list>
    <list name='data'>
      ...
    </list>
    <int name='linkstatic' value='0'/>
    <int name='linkshared' value='0'/>
    <list name='licenses'/>
    <list name='distribs'>
      <distribution value="INTERNAL" />
    </list>
    <rule-input name="//common:common" />
    <rule-input name="//collections:collections" />
    <rule-input name="//foo:foo_main.cc" />
    <rule-input name="//foo:bar.cc" />
    ...
  </rule>

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

--[no]xml:line_numbers

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

--[no]xml:default_values

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

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

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

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

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