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

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

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

इस बारे में ज़्यादा जानकारी

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

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

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

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

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

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

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

क्वेरी लैंग्वेज में दिए गए एक्सप्रेशन नीचे दिए गए हैं.

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

  • except

  • in

  • intersect

  • let

  • set

  • union

• शब्द, जैसे कि "foo/..." या ".*test rule" या "//bar/baz:all". अगर किसी वर्ण का क्रम "उद्धरण चिह्न" है (जो सिंगल कोट से शुरू होता है और उस पर खत्म होता है), तो वह एक शब्द होता है. अगर कैरेक्टर सीक्वेंस कोट नहीं किया गया है, तब भी उसे एक शब्द के रूप में पार्स किया जा सकता है. कोट नहीं किए गए शब्द, A-Za-z वाले अक्षर, 0 से 9 तक के नंबर, और खास वर्णों */@.-_:$~[] (स्टार के निशान, फ़ॉरवर्ड स्लैश, पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर चिह्न, टिल्ड, बायां स्क्वेयर ब्रैकेट) के क्रम को कहते हैं. हालांकि, हो सकता है कि कोट नहीं किए गए शब्द हाइफ़न - या तारे के निशान * से शुरू न हों. हालांकि, उन वर्णों से मिलते-जुलते [target name][(/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 एक कीवर्ड है, लेकिन "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 Query लैंग्वेज कॉन्सेप्ट

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

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

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

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

बिल्ड डिपेंडेंसी ग्राफ़, सर्कुलर फ़ॉर्मैट में होने चाहिए.

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

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

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

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

आवाज़

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

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

ग्राफ़ ऑर्डर के रखरखाव पर

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

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

deps(x) union y

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

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

स्काई क्वेरी

Sky Query, क्वेरी का एक ऐसा मोड है जो एक खास Universal स्कोप पर काम करता है.

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

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

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

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

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

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

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

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

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

डिपेंडेंसी का ट्रांज़िटिव बंद होना: डिप

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

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

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) ऑपरेटर, ज़्यादा से ज़्यादा k टारगेट को अपने आर्ग्युमेंट सेट x से सेट करता है. इसके बाद, वह सिर्फ़ उन टारगेट को चुनता है जिनमें सिर्फ़ ये टारगेट शामिल होते हैं. पैरामीटर 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, allpath

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

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

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

लक्ष्य प्रकार फ़िल्टर करें: प्रकार

expr ::= kind(word, expr)

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

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

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

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

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

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

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

expr ::= filter(word, expr)

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

पहला आर्ग्युमेंट, pattern ऐसा शब्द है जिसमें टारगेट नामों के ऊपर रेगुलर एक्सप्रेशन होता है. filter एक्सप्रेशन ऐसे सेट का आकलन करता है जिनमें सभी टारगेट x होते हैं, जैसे कि x, सेट input का सदस्य होता है या x के //foo:bar (पूरी जानकारी वाले फ़ॉर्मैट, जैसे कि //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 के ज़रिए सीधे तौर पर या किसी और तरीके से रेफ़र किया गया है.

पैकेज की डेफ़िनिशन फ़ाइलें: build files

expr ::= buildfiles(expr)

buildfiles(x) ऑपरेटर, उन फ़ाइलों का सेट दिखाता है जो x सेट में हर टारगेट के पैकेज तय करती हैं. इसका मतलब है कि हर पैकेज और उसकी BUILD फ़ाइल में मौजूद सभी .bzl फ़ाइलों को load से रेफ़र किया गया है. ध्यान दें कि यह उन पैकेज की 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 फ़ाइल में साफ़ तौर पर बताया गया हो. हालांकि, Symlinks को माना जाता है. इसलिए, अगर foo/BUILD, bar/BUILD का सिमलिंक है, तो rbuildfiles(bar/BUILD) अपने नतीजों में //foo:BUILD को शामिल करेगा.

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

पैकेज डेफ़िनिशन फ़ाइलें: loadfile

expr ::= loadfiles(expr)

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

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

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

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

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

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

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

--output 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 कमांड का इस्तेमाल करके इसे इंस्टॉल करने का विकल्प है.) उदाहरण के तौर पर दिए गए उदाहरण के लिए, नीचे दिया गया उदाहरण देखें.

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

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

--graph:node_limit n

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

--[no]graph:factored

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