यह पेज, Bazel क्वेरी लैंग्वेज का रेफ़रंस मैन्युअल है. इसका इस्तेमाल तब किया जाता है, जब बिल्ड डिपेंडेंसी का विश्लेषण करने के लिए bazel query
का इस्तेमाल किया जाता है. इसमें उन आउटपुट फ़ॉर्मैट के बारे में भी बताया गया है जो bazel query
पर काम करते हैं.
इस्तेमाल के उदाहरणों के लिए, Bazel क्वेरी का इस्तेमाल करने का तरीका लेख पढ़ें.
क्वेरी का अन्य रेफ़रंस
query
के अलावा, Bazel में ऐक्शन ग्राफ़ क्वेरी और कॉन्फ़िगर की जा सकने वाली क्वेरी भी शामिल होती है. query
, पोस्ट-लोडिंग फ़ेज़ के टारगेट ग्राफ़ पर चलता है.
ऐक्शन ग्राफ़ की क्वेरी
कार्रवाई ग्राफ़ क्वेरी (aquery
), विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करती है. इसमें कार्रवाइयां, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी मिलती है. aquery
तब काम आता है, जब आपको कॉन्फ़िगर किए गए टारगेट ग्राफ़ से जनरेट किए गए ऐक्शन/आर्टफ़ैक्ट की प्रॉपर्टी में दिलचस्पी हो.
उदाहरण के लिए, चलाए गए असल निर्देश और उनके इनपुट, आउटपुट, और मेनेमोनिक्स.
ज़्यादा जानकारी के लिए, aquery रेफ़रंस देखें.
कॉन्फ़िगर की जा सकने वाली क्वेरी
पारंपरिक Bazel क्वेरी, पोस्ट-लोडिंग फ़ेज़ के टारगेट ग्राफ़ पर चलती है. इसलिए, इसमें कॉन्फ़िगरेशन और उनसे जुड़े कॉन्सेप्ट का कोई कॉन्सेप्ट नहीं होता. ध्यान दें कि यह select स्टेटमेंट को सही तरीके से हल नहीं करता. इसके बजाय, यह select के सभी संभावित रिज़ॉल्यूशन दिखाता है. हालांकि, कॉन्फ़िगर किया जा सकने वाला
क्वेरी एनवायरमेंट cquery
, कॉन्फ़िगरेशन को सही तरीके से मैनेज करता है, लेकिन इस ओरिजनल क्वेरी की सभी सुविधाएं नहीं देता है.
ज़्यादा जानकारी के लिए, 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
. कीवर्ड, इस भाषा के रिज़र्व किए गए शब्द हैं. इन शब्दों के बारे में नीचे बताया गया है. कीवर्ड का पूरा सेट यह है:शब्द, जैसे कि "
foo/...
" या ".*test rule
" या "//bar/baz:all
". अगर वर्ण क्रम को "कोट" किया गया है (शुरुआत और आखिर में सिंगल कोट ' या डबल कोट " है), तो यह एक शब्द है. अगर किसी वर्ण क्रम को कोट नहीं किया गया है, तो भी उसे शब्द के तौर पर पार्स किया जा सकता है. बिना कोटेशन वाले शब्द, अंग्रेज़ी के अक्षरों A से Z, अंकों 0 से 9, और*/@.-_:$~[]
(तारांकन, फ़ॉरवर्ड स्लैश, ऐट, पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर साइन, टाइल्ड, बायां स्क्वेयर ब्रैकेट, और दायां स्क्वेयर ब्रैकेट) जैसे खास वर्णों से बने होते हैं. हालांकि, बिना कोट किए गए शब्द, हाइफ़न-
या तारे के निशान*
से शुरू नहीं हो सकते. भले ही, रिलेटिव टारगेट नेम उन वर्णों से शुरू हो सकते हैं.बिना कोट किए गए शब्दों में, प्लस साइन
+
या बराबर के साइन=
भी शामिल नहीं किए जा सकते. भले ही, टारगेट के नामों में इन वर्णों का इस्तेमाल किया जा सकता है. क्वेरी एक्सप्रेशन जनरेट करने वाला कोड लिखते समय, टारगेट के नाम को कोट में लिखना चाहिए.उपयोगकर्ताओं से मिली वैल्यू से बेज़ल क्वेरी एक्सप्रेशन बनाने वाली स्क्रिप्ट लिखते समय, कोट करना ज़रूरी है.
//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/...
वगैरह.
आसमान से जुड़ी क्वेरी
स्काई क्वेरी, क्वेरी का एक मोड है, जो तय किए गए यूनिवर्स स्कोप पर काम करता है.
सिर्फ़ 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 query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"
हालांकि, --universe_scope
के साथ उस क्वेरी का नतीजा सिर्फ़ //my:target
होता है. //my:target
की रिवर्स डिपेंडेंसी में से कोई भी यूनिवर्स में मौजूद नहीं है! वहीं दूसरी ओर, इन बातों का ध्यान रखें:
bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"
यह एक काम की क्वेरी है, जो कुछ डायरेक्ट्री में मौजूद
tests
टारगेट के एक्सपैंशन में, टेस्ट टारगेट को कैलकुलेट करने की कोशिश करती है. ये डायरेक्ट्री, अस्थायी तौर पर उन टारगेट पर निर्भर होती हैं जिनकी डेफ़िनिशन में किसी .bzl
फ़ाइल का इस्तेमाल किया गया है. यहां,
--infer_universe_scope
एक सुविधा है. खास तौर पर, ऐसे मामले में जहां
--infer_universe_scope
के विकल्प के लिए, आपको क्वेरी एक्सप्रेशन को खुद पार्स करना होगा.--universe_scope
इसलिए, यूनिवर्स के स्कोप वाले allrdeps
और rbuildfiles
जैसे ऑपरेटर ऑपरेटर का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए, --infer_universe_scope
का इस्तेमाल सिर्फ़ तब करें, जब यह आपके काम के मुताबिक हो.
डिफ़ॉल्ट क्वेरी के मुकाबले, Sky क्वेरी के कुछ फ़ायदे और नुकसान हैं. इसका मुख्य नुकसान यह है कि यह अपने आउटपुट को ग्राफ़ के क्रम के हिसाब से क्रम में नहीं लगा सकता. इसलिए, कुछ आउटपुट फ़ॉर्मैट इस्तेमाल करने की अनुमति नहीं है. इसके फ़ायदे यह हैं कि इसमें दो ऑपरेटर (allrdeps
और
rbuildfiles
) उपलब्ध होते हैं, जो डिफ़ॉल्ट क्वेरी में उपलब्ध नहीं होते.
साथ ही, Sky Query, नया ग्राफ़ बनाने के बजाय, Skyframe ग्राफ़ का विश्लेषण करके अपना काम करती है. डिफ़ॉल्ट तौर पर, ऐसा नहीं किया जाता. इस तरह, कुछ परिस्थितियों में यह तेज़ होता है और
कम मेमोरी का इस्तेमाल करता है.
एक्सप्रेशन: व्याकरण का सिंटैक्स और सेमेटिक्स
यह Bazel क्वेरी लैंग्वेज का व्याकरण है, जिसे ईबीएनएफ़ नोटेशन में दिखाया गया है:
expr ::= word
| let name = expr in expr
| (expr)
| expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
| set(word *)
| word '(' int | word | expr ... ')'
नीचे दिए गए सेक्शन में, इस व्याकरण के हर प्रोडक्शन के बारे में क्रम से बताया गया है.
टारगेट पैटर्न
expr ::= word
सिंटैक्स के हिसाब से, टारगेट पैटर्न सिर्फ़ एक शब्द होता है. इसे टारगेट के (बिना क्रम वाला) सेट माना जाता है. सबसे आसान टारगेट पैटर्न एक लेबल होता है, जो किसी एक टारगेट (फ़ाइल या नियम) की पहचान करता है. उदाहरण के लिए, टारगेट पैटर्न //foo:bar
का आकलन ऐसे सेट के लिए किया जाता है जिसमें एक एलिमेंट, टारगेट, bar
नियम शामिल हो.
टारगेट पैटर्न, पैकेज और टारगेट के लिए वाइल्डकार्ड शामिल करने के लिए, लेबल को सामान्य बनाते हैं. उदाहरण के लिए, foo/...:all
(या सिर्फ़ foo/...
) एक टारगेट पैटर्न है, जो foo
डायरेक्ट्री के नीचे मौजूद हर पैकेज में, बार-बार सभी नियमों वाले सेट का आकलन करता है. bar/baz:all
एक टारगेट पैटर्न है, जो bar/baz
पैकेज में मौजूद सभी नियमों वाले सेट का आकलन करता है, लेकिन उसके सब-पैकेज का नहीं.
इसी तरह, foo/...:*
एक टारगेट पैटर्न है, जो foo
डायरेक्ट्री के नीचे मौजूद हर पैकेज में, सभी टारगेट (नियम और फ़ाइलें) वाले सेट का आकलन करता है. bar/baz:*
, bar/baz
पैकेज के सभी टारगेट वाले सेट का आकलन करता है, लेकिन इसके सब-पैकेज का नहीं.
:*
वाइल्डकार्ड, फ़ाइलों के साथ-साथ नियमों से भी मैच करता है. इसलिए, अक्सर क्वेरी के लिए यह :all
से ज़्यादा मददगार होता है. इसके उलट, :all
वाइल्डकार्ड (foo/...
जैसे टारगेट पैटर्न में शामिल है) आम तौर पर बिल्ड के लिए ज़्यादा मददगार होता है.
bazel query
टारगेट पैटर्न, bazel build
बिल्ड टारगेट की तरह ही काम करते हैं.
ज़्यादा जानकारी के लिए, टारगेट पैटर्न देखें या
bazel help target-syntax
टाइप करें.
टारगेट पैटर्न का आकलन, एक सिंगलटन सेट (लेबल के मामले में) के लिए, कई एलिमेंट वाले सेट (जैसे कि foo/...
में हज़ारों एलिमेंट होता है) तक या अगर टारगेट पैटर्न किसी भी टारगेट से मेल नहीं खाता है, तो खाली सेट का आकलन किया जा सकता है.
टारगेट पैटर्न एक्सप्रेशन के नतीजे में मौजूद सभी नोड, एक-दूसरे के हिसाब से सही क्रम में होते हैं. यह क्रम, डिपेंडेंसी रिलेशन के हिसाब से तय होता है. इसलिए, foo:*
का नतीजा सिर्फ़ पैकेज foo
में मौजूद टारगेट का सेट नहीं है, बल्कि उन टारगेट का ग्राफ़ भी है. (नतीजों के नोड के अन्य नोड के मुकाबले, क्रम से होने की कोई गारंटी नहीं दी जाती.) ज़्यादा जानकारी के लिए,
ग्राफ़ का क्रम सेक्शन देखें.
वैरिएबल
expr ::= let name = expr1 in expr2
| $name
Bazel क्वेरी भाषा में, वेरिएबल की परिभाषाएं और उनके रेफ़रंस दिए जा सकते हैं. let
एक्सप्रेशन का आकलन करने पर, वैल्यू वही मिलती है जो expr2 से मिलती है. इसमें वैरिएबल name की सभी फ़्री ऑक्यूरेंस को expr1 की वैल्यू से बदल दिया जाता है.
उदाहरण के लिए, let v = foo/... in allpaths($v, //common) intersect $v
, allpaths(foo/...,//common) intersect foo/...
के बराबर है.
बंद किए गए let name = ...
एक्सप्रेशन के अलावा, किसी दूसरे वैरिएबल रेफ़रंस name
के होने पर गड़बड़ी होती है. दूसरे शब्दों में, टॉप-लेवल क्वेरी एक्सप्रेशन में फ़्री वैरिएबल नहीं हो सकते.
ऊपर दिए गए व्याकरण के प्रॉडक्शन में, name
word की तरह है. हालांकि, इसमें एक और शर्त है कि यह C प्रोग्रामिंग भाषा में कानूनी आइडेंटिफ़ायर हो. वैरिएबल के रेफ़रंस के आगे "$" वर्ण होना चाहिए.
हर let
एक्सप्रेशन में सिर्फ़ एक वैरिएबल तय किया जाता है. हालांकि, इन्हें नेस्ट किया जा सकता है.
टारगेट पैटर्न और वैरिएबल के रेफ़रंस, दोनों में सिर्फ़ एक टोकन होता है. यह एक शब्द होता है, जो वाक्य को साफ़ तौर पर समझाने वाला होता है. हालांकि, इसमें कोई मतलब समझने में कोई दिक्कत नहीं होती, क्योंकि वैरिएबल के लिए इस्तेमाल किए जा सकने वाले शब्दों का सबसेट, टारगेट पैटर्न के लिए इस्तेमाल किए जा सकने वाले शब्दों के सबसेट से अलग होता है.
तकनीकी तौर पर, let
एक्सप्रेशन से क्वेरी भाषा की जानकारी देने की क्षमता नहीं बढ़ती: भाषा में बताई जा सकने वाली किसी भी क्वेरी को उनके बिना भी बताया जा सकता है. हालांकि, इससे कई क्वेरी कम शब्दों में हो जाती हैं. साथ ही, क्वेरी का आकलन भी बेहतर तरीके से किया जा सकता है.
ब्रैकेट वाले एक्सप्रेशन
expr ::= (expr)
ब्रैकेट, आकलन के क्रम को लागू करने के लिए सब-एक्सप्रेशन को जोड़ते हैं. ब्रैकेट में मौजूद एक्सप्रेशन का आकलन, उसके आर्ग्युमेंट की वैल्यू के हिसाब से किया जाता है.
बीजीय सेट संक्रियाएं: प्रतिच्छेदन, संघ, सेट अंतर
expr ::= expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
ये तीन ऑपरेटर, अपने आर्ग्युमेंट पर सेट के सामान्य ऑपरेशन कैलकुलेट करते हैं.
हर ऑपरेटर के दो फ़ॉर्म होते हैं. पहला, नाम वाला फ़ॉर्म, जैसे कि intersect
और दूसरा, सिंबल वाला फ़ॉर्म, जैसे कि ^
. दोनों फ़ॉर्म एक जैसे होते हैं और सांकेतिक फ़ॉर्म ज़्यादा तेज़ी से
टाइप होते हैं. (इस पेज के बाकी हिस्से में, नाममात्र फ़ॉर्म का इस्तेमाल किया गया है.)
उदाहरण के लिए,
foo/... except foo/bar/...
foo/...
से मैच करने वाले टारगेट के सेट का आकलन करता है, लेकिन foo/bar/...
से मैच नहीं करता.
एक ही क्वेरी को इस तरह लिखा जा सकता है:
foo/... - foo/bar/...
intersect
(^
) और union
(+
) ऑपरेटर कम्यूटिव (सिमेट्रिक) होते हैं;
except
(-
) असिमेट्रिक होता है. पार्सर, इन तीनों ऑपरेटर को बाईं ओर से जुड़े और एक जैसी प्राथमिकता वाले ऑपरेटर के तौर पर इस्तेमाल करता है. इसलिए, आपको ब्रैकेट की ज़रूरत पड़ सकती है. उदाहरण के लिए, इनमें से पहले दो एक्सप्रेशन एक जैसे हैं, लेकिन तीसरा नहीं:
x intersect y union z
(x intersect y) union z
x intersect (y union z)
किसी बाहरी सोर्स से टारगेट पढ़ना: सेट
expr ::= set(word *)
set(a b c ...)
ऑपरेटर, शून्य या एक से ज़्यादा टारगेट पैटर्न के सेट का यूनियन कैलकुलेट करता है. इन पैटर्न को स्पेस (कोमा नहीं) से अलग किया जाता है.
बोर्न शेल की $(...)
सुविधा के साथ set()
एक क्वेरी के नतीजों को किसी सामान्य टेक्स्ट फ़ाइल में सेव करने का तरीका उपलब्ध कराता है.
इसका मतलब है कि एक क्वेरी के नतीजों को किसी सामान्य टेक्स्ट फ़ाइल में सेव किया जा सकता है.
इसके बाद, दूसरे प्रोग्राम (जैसे कि स्टैंडर्ड यूएनआईएक्स शेल टूल) का इस्तेमाल करके उस टेक्स्ट फ़ाइल में हेर-फेर किया जाता है.
इसके बाद, नतीजे को क्वेरी टूल में फिर से वैल्यू के तौर पर
पेश किया जाता है. उदाहरण के लिए:
bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"
अगले उदाहरण में,kind(cc_library, deps(//some_dir/foo:main, 5))
का हिसाब लगाने के लिए, awk
प्रोग्राम का इस्तेमाल करके maxrank
वैल्यू को फ़िल्टर किया गया है.
bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"
इन उदाहरणों में, $(<foo)
, $(cat foo)
का शॉर्टहैंड है. हालांकि, cat
के अलावा, शेल कमांड का इस्तेमाल भी किया जा सकता है. जैसे, पिछले awk
कमांड.
फ़ंक्शन
expr ::= word '(' int | word | expr ... ')'
क्वेरी भाषा में कई फ़ंक्शन तय किए जाते हैं. फ़ंक्शन के नाम से यह तय होता है कि उसे कितने और किस तरह के आर्ग्युमेंट की ज़रूरत है. ये फ़ंक्शन उपलब्ध हैं:
allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible
डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: deps
expr ::= deps(expr)
| deps(expr, depth)
deps(x)
ऑपरेटर, अपने आर्ग्युमेंट सेट x की डिपेंडेंसी के ट्रांज़िशन क्लोज़र से बने ग्राफ़ का आकलन करता है. उदाहरण के लिए, deps(//foo)
की वैल्यू, एक नोड foo
पर आधारित डिपेंडेंसी ग्राफ़ है. इसमें उसकी सभी डिपेंडेंसी शामिल हैं. deps(foo/...)
की वैल्यू, डिपेंडेंसी ग्राफ़ होती है. इन ग्राफ़ के रूट, foo
डायरेक्ट्री के नीचे मौजूद हर पैकेज के सभी नियम होते हैं. इस संदर्भ में,
'डिपेंडेंसी' का मतलब सिर्फ़ नियम और फ़ाइल टारगेट होता है. इसलिए, इन टारगेट को बनाने के लिए ज़रूरी BUILD
और
Starlark फ़ाइलों को यहां शामिल नहीं किया गया है. इसके लिए, आपको buildfiles
ऑपरेटर का इस्तेमाल करना चाहिए.
इससे मिलने वाले ग्राफ़ को, डिपेंडेंसी रिलेशन के हिसाब से क्रम में लगाया जाता है. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम सेक्शन देखें.
deps
ऑपरेटर, वैकल्पिक दूसरा आर्ग्युमेंट स्वीकार करता है. यह एक पूर्णांक होता है, जो खोज की गहराई की ऊपरी सीमा तय करता है. इसलिए, deps(foo:*, 0)
, foo
पैकेज में मौजूद सभी टारगेट दिखाता है. वहीं, deps(foo:*, 1)
में foo
पैकेज के किसी भी टारगेट की ज़रूरी शर्तें शामिल होती हैं. इसके अलावा, deps(foo:*, 2)
में deps(foo:*, 1)
के नोड से सीधे तौर पर ऐक्सेस किए जा सकने वाले नोड शामिल होते हैं. (ये नंबर, minrank
आउटपुट फ़ॉर्मैट में दिखाई गई रैंक से मेल खाते हैं.)
अगर depth पैरामीटर को शामिल नहीं किया जाता है, तो खोज की कोई सीमा तय नहीं होती है: यह ज़रूरी शर्तों के 'रिफ़्लेक्सिव ट्रांज़िटिव क्लोज़र' का पता लगाता है.
रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: rdeps
expr ::= rdeps(expr, expr)
| rdeps(expr, expr, depth)
rdeps(u, x)
ऑपरेटर, यूनिवर्स सेट u के ट्रांसीटिव क्लोज़र में, आर्ग्युमेंट सेट x की रिवर्स डिपेंडेंसी का आकलन करता है.
इससे मिलने वाले ग्राफ़ को, डिपेंडेंसी रिलेशन के हिसाब से क्रम में लगाया जाता है. ज़्यादा जानकारी के लिए, ग्राफ़ के क्रम सेक्शन देखें.
rdeps
ऑपरेटर एक वैकल्पिक तीसरा तर्क स्वीकार करता है जो खोज की डेप्थ पर ऊपरी सीमा तय करने वाला एक पूर्णांक होता है. इस ग्राफ़ में, सिर्फ़ ऐसे नोड शामिल होते हैं जो आर्ग्युमेंट सेट में मौजूद किसी भी नोड से तय की गई डीपथ के अंदर हों. इसलिए, rdeps(//foo, //common, 1)
, //foo
के ट्रांज़िटिव क्लोज़र में मौजूद उन सभी नोड का आकलन करता है जो सीधे तौर पर //common
पर निर्भर होते हैं. (ये नंबर, minrank
आउटपुट फ़ॉर्मैट में दिखाई गई रैंक के हिसाब से होते हैं.) अगर depth पैरामीटर को शामिल नहीं किया जाता है, तो खोज की सीमा नहीं होती.
सभी रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: allrdeps
expr ::= allrdeps(expr)
| allrdeps(expr, depth)
allrdeps
ऑपरेटर, rdeps
ऑपरेटर की तरह काम करता है. अंतर सिर्फ़ यह है कि "यूनिवर्स सेट", अलग से तय किए जाने के बजाय, --universe_scope
फ़्लैग का आकलन करता है. इसलिए, अगर --universe_scope=//foo/...
पास हो गया है, तो allrdeps(//bar)
, rdeps(//foo/..., //bar)
के बराबर है.
एक ही पैकेज में सीधे रिवर्स डिपेंडेंसी: same_pkg_direct_rdeps
expr ::= same_pkg_direct_rdeps(expr)
same_pkg_direct_rdeps(x)
ऑपरेटर, उन सभी टारगेट का आकलन करता है जो आर्ग्युमेंट सेट में मौजूद टारगेट के एक ही पैकेज में होते हैं और जो सीधे तौर पर उस पर निर्भर होते हैं.
टारगेट के पैकेज से जुड़ी समस्या हल करना: भाई-बहन
expr ::= siblings(expr)
siblings(x)
ऑपरेटर, उन सभी टारगेट का आकलन करता है जो आर्ग्युमेंट सेट में मौजूद टारगेट के तौर पर एक ही पैकेज में होते हैं.
मनमुताबिक विकल्प: कुछ
expr ::= some(expr)
| some(expr, count )
some(x, k)
ऑपरेटर, अपने आर्ग्युमेंट सेट x से ज़्यादा से ज़्यादा k टारगेट चुनता है. साथ ही, सिर्फ़ उन टारगेट वाले सेट का आकलन करता है. पैरामीटर k ज़रूरी नहीं है. अगर यह मौजूद नहीं है, तो नतीजा एक सिंगलटन सेट होगा, जिसमें मनमुताबिक चुना गया सिर्फ़ एक टारगेट होगा. अगर आर्ग्युमेंट सेट x का साइज़, k से कम है, तो आर्ग्युमेंट सेट x को पूरा दिखाया जाएगा.
उदाहरण के लिए, एक्सप्रेशन some(//foo:main union //bar:baz)
का आकलन, //foo:main
या //bar:baz
वाले सिंगलटन सेट के तौर पर किया जाता है. हालांकि, यह तय नहीं किया जाता कि कौनसा सेट है. some(//foo:main union //bar:baz, 2)
या some(//foo:main union //bar:baz, 3)
एक्सप्रेशन, //foo:main
और //bar:baz
, दोनों दिखाता है.
अगर आर्ग्युमेंट एकल है, तो some
, आइडेंटिटी फ़ंक्शन का हिसाब लगाता है: some(//foo:main)
, //foo:main
के बराबर है.
अगर तय किया गया आर्ग्युमेंट सेट खाली है, तो यह गड़बड़ी है. जैसे, some(//foo:main intersect //bar:baz)
एक्सप्रेशन में.
पाथ ऑपरेटर: somepath, allpaths
expr ::= somepath(expr, expr)
| allpaths(expr, expr)
somepath(S, E)
और
allpaths(S, E)
ऑपरेटर, टारगेट के दो सेट के बीच पाथ का हिसाब लगाते हैं. दोनों क्वेरी में दो आर्ग्युमेंट इस्तेमाल किए जाते हैं. पहला, शुरुआती पॉइंट का सेट S और दूसरा, आखिरी पॉइंट का सेट E. somepath
कुछ आर्बिट्रेरी पाथ के नोड का ग्राफ़, S में मौजूद टारगेट से E के टारगेट पर दिखाता है; allpaths
, S में किसी भी टारगेट के सभी पाथ के नोड के ग्राफ़ को E के किसी भी टारगेट में दिखाता है.
इससे मिलने वाले ग्राफ़, डिपेंडेंसी रिलेशन के हिसाब से क्रम में लगा दिए जाते हैं. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम सेक्शन देखें.
टारगेट टाइप के हिसाब से फ़िल्टर करना: kind
expr ::= kind(word, expr)
kind(pattern, input)
ऑपरेटर, टारगेट के सेट पर एक फ़िल्टर लागू करता है और उन टारगेट को खारिज कर देता है जो उम्मीद के मुताबिक नहीं हैं. pattern
पैरामीटर से यह तय होता है कि किस तरह के टारगेट से मैच करना है.
उदाहरण के लिए, नीचे दी गई टेबल में, BUILD
फ़ाइल (पैकेज p
के लिए) से तय किए गए चार टारगेट के टाइप दिखाए गए हैं:
कोड | टारगेट | प्रकार |
---|---|---|
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", ) |
//p:a |
genrule नियम |
//p:a.in |
सोर्स फ़ाइल | |
//p:a.out |
जनरेट की गई फ़ाइल | |
//p:BUILD |
सोर्स फ़ाइल |
इस तरह, kind("cc_.* rule", foo/...)
आकलन करके, foo
के नीचे दिए गए सभी cc_library
, cc_binary
वगैरह और नियम के टारगेट के सेट का आकलन करता है. साथ ही, kind("source file", deps(//foo))
//foo
टारगेट के डिपेंडेंसी क्लोज़र में मौजूद सभी सोर्स फ़ाइलों के सेट का आकलन करता है.
pattern आर्ग्युमेंट को कोटेशन में रखने की ज़रूरत अक्सर होती है, क्योंकि इसके बिना, पार्स करने वाला टूल source
file
और .*_test
जैसी कई रेगुलर एक्सप्रेशन को शब्द नहीं मानता.
package group
से मैच करने पर, :all
पर खत्म होने वाले टारगेट से कोई नतीजा नहीं मिल सकता. इसके बजाय, :all-targets
का इस्तेमाल करें.
टारगेट के नाम को फ़िल्टर करना: फ़िल्टर
expr ::= filter(word, expr)
filter(pattern, input)
ऑपरेटर, टारगेट के सेट पर एक फ़िल्टर लागू करता है. साथ ही, उन टारगेट को खारिज कर देता है जिनके लेबल (पूरी जानकारी के साथ) पैटर्न से मेल नहीं खाते. यह, इसके इनपुट के सबसेट का आकलन करता है.
पहला आर्ग्युमेंट, pattern एक ऐसा शब्द है जिसमें टारगेट नेम के लिए रेगुलर एक्सप्रेशन शामिल है. एक filter
एक्सप्रेशन, उस सेट का आकलन करता है जिसमें सभी टारगेट x मौजूद होते हैं. जैसे, x, सेट input का सदस्य है और x के लेबल (जैसे कि //foo:bar
) में रेगुलर एक्सप्रेशन pattern के लिए (ऐंकर न किया गया) मैच शामिल है. सभी टारगेट नेम //
से शुरू होते हैं. इसलिए, इसका इस्तेमाल ^
रेगुलर एक्सप्रेशन ऐंकर के विकल्प के तौर पर किया जा सकता है.
यह ऑपरेटर, अक्सर intersect
ऑपरेटर का ज़्यादा तेज़ और ज़्यादा मज़बूत विकल्प उपलब्ध कराता है. उदाहरण के लिए, //foo:foo
टारगेट की सभी bar
डिपेंडेंसी देखने के लिए,
deps(//foo) intersect //bar/...
हालांकि, इस स्टेटमेंट के लिए, bar
ट्री में मौजूद सभी BUILD
फ़ाइलों को पार्स करना होगा. यह प्रोसेस धीमी होगी और काम की BUILD
फ़ाइलों में गड़बड़ियां हो सकती हैं. इसका दूसरा विकल्प यह होगा:
filter(//bar, deps(//foo))
यह फ़ंक्शन सबसे पहले //foo
डिपेंडेंसी के सेट का हिसाब लगाएगा और फिर दिए गए पैटर्न से मैच करने वाले सिर्फ़ टारगेट को फ़िल्टर करेगा. दूसरे शब्दों में, जिन टारगेट के नाम में //bar
सबस्ट्रिंग के तौर पर शामिल है उन्हें फ़िल्टर किया जाएगा.
filter(pattern,
expr)
ऑपरेटर का इस्तेमाल, किसी फ़ाइल के नाम या एक्सटेंशन के हिसाब से फ़िल्टर करने के लिए भी किया जाता है. उदाहरण के लिए,
filter("\.cc$", deps(//foo))
//foo
बनाने के लिए इस्तेमाल की गई सभी .cc
फ़ाइलों की सूची देगा.
नियम के हिसाब से एट्रिब्यूट फ़िल्टर करना: attr
expr ::= attr(word, word, expr)
attr(name, pattern, input)
ऑपरेटर, टारगेट के किसी सेट पर फ़िल्टर लागू करता है. साथ ही, ऐसे टारगेट को खारिज कर देता है जो नियम नहीं हैं, जिनमें एट्रिब्यूट name तय नहीं किया गया है या जिनमें एट्रिब्यूट की वैल्यू, दिए गए रेगुलर एक्सप्रेशन pattern से मेल नहीं खाती. यह अपने इनपुट के सबसेट का आकलन करता है.
पहला आर्ग्युमेंट, name नियम एट्रिब्यूट का नाम है. इसे दिए गए रेगुलर एक्सप्रेशन पैटर्न से मैच करना चाहिए. दूसरा आर्ग्युमेंट,
pattern एट्रिब्यूट वैल्यू पर आधारित रेगुलर एक्सप्रेशन है. attr
एक्सप्रेशन का आकलन, सभी टारगेट x वाले सेट के हिसाब से किया जाता है. ऐसा तब होता है, जब x, सेट input का सदस्य हो, तय किए गए एट्रिब्यूट name वाला नियम हो, और एट्रिब्यूट की वैल्यू में रेगुलर एक्सप्रेशन pattern के लिए (बिना ऐंकर वाला) मैच शामिल हो. अगर name वैकल्पिक एट्रिब्यूट है और नियम में इसकी साफ़ तौर पर जानकारी नहीं दी गई है, तो तुलना के लिए एट्रिब्यूट की डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाएगा. उदाहरण के लिए,
attr(linkshared, 0, deps(//foo))
उन सभी //foo
डिपेंडेंसी को चुनेगा जिनके लिए लिंक किया गया एट्रिब्यूट (जैसे, cc_binary
नियम) सेट करने की अनुमति है. साथ ही, यह एट्रिब्यूट या तो साफ़ तौर पर 0 पर सेट होगा या इसे बिल्कुल सेट नहीं किया जाएगा, लेकिन डिफ़ॉल्ट वैल्यू 0 होगी (जैसे, cc_binary
नियमों के लिए).
सूची वाले एट्रिब्यूट (जैसे, srcs
, data
वगैरह) को [value<sub>1</sub>, ..., value<sub>n</sub>]
फ़ॉर्मैट की स्ट्रिंग में बदल दिया जाता है. यह [
ब्रैकेट से शुरू होता है और ]
ब्रैकेट पर खत्म होता है. साथ ही, एक से ज़्यादा वैल्यू को अलग करने के लिए, ",
" (कॉमा, स्पेस) का इस्तेमाल किया जाता है.
लेबल के ऐब्सलूट फ़ॉर्म का इस्तेमाल करके, लेबल को स्ट्रिंग में बदला जाता है. उदाहरण के लिए, एट्रिब्यूट deps=[":foo",
"//otherpkg:bar", "wiz"]
को [//thispkg:foo, //otherpkg:bar, //thispkg:wiz]
स्ट्रिंग में बदल दिया जाएगा.
ब्रैकेट हमेशा मौजूद होते हैं. इसलिए, मैच करने के मकसद से खाली सूची में, स्ट्रिंग की वैल्यू []
का इस्तेमाल किया जाएगा. उदाहरण के लिए,
attr("srcs", "\[\]", deps(//foo))
//foo
डिपेंडेंसी में से उन सभी नियमों को चुनेगा जिनका srcs
एट्रिब्यूट खाली है, जबकि
attr("data", ".{3,}", deps(//foo))
//foo
डिपेंडेंसी में से उन सभी नियमों को चुनेगा जो data
एट्रिब्यूट में कम से कम एक वैल्यू तय करते हैं. //
और :
की वजह से, हर लेबल कम से कम तीन वर्णों का होता है.
सूची-टाइप एट्रिब्यूट में, खास value
वाली //foo
डिपेंडेंसी में से सभी नियमों को चुनने के लिए,
attr("tags", "[\[ ]value[,\]]", deps(//foo))
यह काम करता है, क्योंकि value
से पहले का वर्ण [
या स्पेस होगा और value
के बाद का वर्ण, कॉमा या ]
होगा.
नियम के दिखने की सेटिंग: दिख रहा है
expr ::= visible(expr, expr)
visible(predicate, input)
ऑपरेटर, टारगेट के सेट पर फ़िल्टर लागू करता है और ज़रूरी विज़िबिलिटी के बिना टारगेट को खारिज कर देता है.
पहला आर्ग्युमेंट, predicate, टारगेट का एक सेट होता है. यह ज़रूरी है कि आउटपुट में मौजूद सभी टारगेट को यह सेट दिखे. visible एक्सप्रेशन, ऐसे सेट का आकलन करता है जिसमें सभी टारगेट x शामिल होते हैं. जैसे, x input सेट का सदस्य होता है और predicate में मौजूद सभी टारगेट y के लिए, x y को दिखता है. उदाहरण के लिए:
visible(//foo, //bar:*)
पैकेज //bar
में मौजूद उन सभी टारगेट को चुनेगा जिन पर //foo
विज्ञापन दिखने से जुड़ी पाबंदियों का उल्लंघन किए बिना भरोसा किया जा सकता है.
लेबल टाइप: लेबल के नियम से जुड़ी एट्रिब्यूट का आकलन
expr ::= labels(word, expr)
labels(attr_name, inputs)
ऑपरेटर, सेट inputs के किसी नियम में "लेबल" या "लेबल की सूची" टाइप के एट्रिब्यूट attr_name में बताए गए टारगेट का सेट दिखाता है.
उदाहरण के लिए, labels(srcs, //foo)
, //foo
नियम के srcs
एट्रिब्यूट में दिखने वाले टारगेट का सेट दिखाता है. अगर inputs सेट में srcs
एट्रिब्यूट वाले एक से ज़्यादा नियम हैं, तो उनके srcs
का यूनियन दिखाया जाता है.
test_suites: tests को बड़ा करना और फ़िल्टर करना
expr ::= tests(expr)
tests(x)
ऑपरेटर, सेट x में सभी जांच के नियमों का सेट दिखाता है. इस सुविधा में, test_suite
के उन नियमों को अलग-अलग टेस्ट के सेट में बड़ा किया जाता है जिनके बारे में वे जानकारी देते हैं. साथ ही, यह tag
और size
के हिसाब से फ़िल्टर लागू करता है.
डिफ़ॉल्ट रूप से, क्वेरी का आकलन करने से test_suite
के सभी नियमों में मौजूद ऐसे टारगेट को अनदेखा कर दिया जाता है जो जांच के दायरे में नहीं आते. --strict_test_suite
विकल्प की मदद से, इसे गड़बड़ियों में बदला जा सकता है.
उदाहरण के लिए, क्वेरी kind(test, foo:*)
में foo
पैकेज में मौजूद सभी *_test
और test_suite
नियमों की सूची होती है. सभी नतीजे (परिभाषा के मुताबिक) foo
पैकेज के सदस्य हैं. इसके उलट, क्वेरी tests(foo:*)
उन सभी अलग-अलग टेस्ट को दिखाएगी जिन्हें bazel test
foo:*
से चलाया जाएगा: इसमें ऐसे अन्य पैकेज के टेस्ट शामिल हो सकते हैं जिनका रेफ़रंस test_suite
नियमों के ज़रिए सीधे या अप्रत्यक्ष तौर पर दिया गया हो.
पैकेज की परिभाषा वाली फ़ाइलें: बिल्ड फ़ाइलें
expr ::= buildfiles(expr)
buildfiles(x)
ऑपरेटर, उन फ़ाइलों का सेट दिखाता है जो x सेट में मौजूद हर टारगेट के पैकेज के बारे में बताती हैं. दूसरे शब्दों में, हर पैकेज, उसकी BUILD
फ़ाइल, और load
के ज़रिए रेफ़र की गई सभी .bzl फ़ाइलों के लिए. ध्यान दें कि यह उन पैकेज की BUILD
फ़ाइलें भी दिखाता है जिनमें ये load
वाली फ़ाइलें शामिल हैं.
आम तौर पर, इस ऑपरेटर का इस्तेमाल यह तय करते समय किया जाता है कि कोई खास टारगेट बनाने के लिए किन फ़ाइलों या पैकेज की ज़रूरत है. ऐसा अक्सर नीचे दिए गए --output package
विकल्प के साथ किया जाता है. उदाहरण के लिए,
bazel query 'buildfiles(deps(//foo))' --output package
उन सभी पैकेज का सेट दिखाता है जिन पर //foo
ट्रांज़िटिव तरीके से निर्भर करता है.
पैकेज की परिभाषा वाली फ़ाइलें: rbuildfiles
expr ::= rbuildfiles(word, ...)
rbuildfiles
ऑपरेटर, पाथ फ़्रैगमेंट की कॉमा-सेपरेटेड लिस्ट लेता है और
BUILD
फ़ाइलों का वह सेट दिखाता है जो इन पाथ फ़्रैगमेंट पर ट्रांज़िट के तौर पर निर्भर करता है. उदाहरण के लिए, अगर //foo
कोई पैकेज है, तो rbuildfiles(foo/BUILD)
से //foo:BUILD
टारगेट दिखेगा. अगर foo/BUILD
फ़ाइल में load('//bar:file.bzl'...
मौजूद है, तो rbuildfiles(bar/file.bzl)
//foo:BUILD
टारगेट के साथ-साथ //bar:file.bzl
को लोड करने वाली अन्य BUILD
फ़ाइलों के टारगेट दिखाएगा
--universe_scope
फ़्लैग में बताया गया यूनिवर्स है. जिन फ़ाइलों का सीधा संबंध BUILD
फ़ाइलों और .bzl
फ़ाइलों से नहीं है उनका नतीजों पर कोई असर नहीं पड़ता. उदाहरण के लिए, सोर्स फ़ाइलों (जैसे कि foo.cc
) को अनदेखा किया जाता है,
भले ही उनकी जानकारी साफ़ तौर पर BUILD
फ़ाइल में दी गई हो. हालांकि, सिमलینک को शामिल किया जाता है, ताकि अगर foo/BUILD
, bar/BUILD
का सिमलینک है, तो rbuildfiles(bar/BUILD)
अपने नतीजों में //foo:BUILD
को शामिल करेगा.
rbuildfiles
ऑपरेटर, buildfiles
ऑपरेटर के उलट काम करता है. हालांकि, यह नैतिक उलटाव एक दिशा में ज़्यादा ज़ोर से होता है: rbuildfiles
के आउटपुट, buildfiles
के इनपुट जैसे ही होते हैं; पहले में सिर्फ़ पैकेज में BUILD
फ़ाइल टारगेट होंगे और दूसरे में ऐसे टारगेट हो सकते हैं. दूसरी दिशा में, कorespondence कमज़ोर है. buildfiles
ऑपरेटर के आउटपुट, सभी पैकेज और से जुड़े टारगेट होते हैं.bzl
किसी इनपुट के लिए ज़रूरी फ़ाइलें. हालांकि, rbuildfiles
ऑपरेटर के इनपुट, वे टारगेट नहीं होते, बल्कि वे टारगेट से जुड़े पाथ फ़्रैगमेंट होते हैं.
पैकेज के बारे में बताने वाली फ़ाइलें: लोड फ़ाइलें
expr ::= loadfiles(expr)
loadfiles(x)
ऑपरेटर, x सेट में हर टारगेट के पैकेज लोड करने के लिए ज़रूरी Starlark फ़ाइलों का सेट दिखाता है. दूसरे शब्दों में, हर पैकेज के लिए, यह ऐसी .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 भाषा में हाथ से लिखा गया हो. सभी वैरिएबल और फ़ंक्शन कॉल (जैसे, glob, मैक्रो) को बड़ा किया जाता है. इससे Starlark मैक्रो के असर को देखने में मदद मिलती है. इसके अलावा, हर लागू नियम में generator_name
और/या generator_function
वैल्यू दिखती है. साथ ही, उस मैक्रो का नाम भी दिखता है जिसका इस्तेमाल करके लागू नियम बनाया गया है.
हालांकि, आउटपुट में BUILD
फ़ाइलों के जैसे सिंटैक्स का इस्तेमाल किया जाता है, लेकिन यह गारंटी नहीं है कि इससे मान्य BUILD
फ़ाइल बनेगी.
हर टारगेट का लेबल प्रिंट करना
--output label
इस विकल्प की मदद से, नतीजों वाले ग्राफ़ में हर टारगेट के नामों (या लेबल) का सेट, हर लाइन में एक लेबल, टॉपोलॉजिकल क्रम में प्रिंट किया जाता है. ऐसा तब तक किया जाता है, जब तक --noorder_results
तय नहीं किया जाता. नतीजों के क्रम के बारे में जानकारी देखें.
(टोपोलॉजिकल क्रम वह होता है जिसमें कोई ग्राफ़ नोड, अपने सभी उत्तराधिकारियों से पहले दिखता है.) रिवर्स पोस्टऑर्डर, ग्राफ़ की कई संभावित टॉपोलॉजिकल ऑर्डरिंग में से सिर्फ़ एक है. हालांकि, यह तय नहीं किया गया है कि कौनसी ऑर्डरिंग चुनी जाए.
somepath
क्वेरी के आउटपुट को प्रिंट करते समय, नोड को जिस क्रम में प्रिंट किया जाता है वह पाथ का क्रम होता है.
चेतावनी: कुछ मामलों में, एक ही लेबल वाले दो अलग-अलग टारगेट हो सकते हैं. उदाहरण के लिए, sh_binary
नियम और उसकी एकमात्र (अहम) srcs
फ़ाइल, दोनों को foo.sh
कहा जा सकता है. अगर किसी क्वेरी के नतीजे में ये दोनों टारगेट शामिल हैं, तो label
फ़ॉर्मैट में आउटपुट में डुप्लीकेट दिखेगा. label_kind
(नीचे देखें) फ़ॉर्मैट का इस्तेमाल करने पर, फ़र्क़ साफ़ तौर पर दिखता है: दोनों टारगेट का नाम एक ही है, लेकिन एक का टाइप sh_binary rule
है और दूसरे का टाइप source file
.
हर टारगेट का लेबल और टाइप प्रिंट करना
--output label_kind
label
की तरह, यह आउटपुट फ़ॉर्मैट, नतीजे वाले ग्राफ़ में हर टारगेट के लेबल को स्थान के हिसाब से प्रिंट करता है. हालांकि, यह लेबल से पहले टारगेट के टाइप के मुताबिक होता है.
प्रोटोकॉल बफ़र फ़ॉर्मैट में टारगेट प्रिंट करना
--output proto
क्वेरी के आउटपुट को QueryResult
प्रोटोकॉल बफ़र के तौर पर प्रिंट करता है.
लंबाई सीमांकित प्रोटोकॉल बफ़र प्रारूप में प्रिंट लक्ष्य
--output streamed_proto
Target
प्रोटोकॉल बफ़र की लंबाई के हिसाब से बांटी गई स्ट्रीम को प्रिंट करता है. यह (i) प्रोटोकॉल बफ़र के साइज़ की सीमाओं को हल करने के लिए तब मददगार होता है, जब एक ही QueryResult
में फ़िट होने के लिए बहुत ज़्यादा टारगेट हों या (ii) Bazel के आउटपुट होने के दौरान प्रोसेसिंग शुरू करने के लिए.
टारगेट को टेक्स्ट प्रोटो फ़ॉर्मैट में प्रिंट करना
--output textproto
--output proto
की तरह ही, QueryResult
प्रोटोकॉल बफ़र को टेक्स्ट फ़ॉर्मैट में प्रिंट करता है.
ndjson फ़ॉर्मैट में टारगेट प्रिंट करना
--output streamed_jsonproto
--output streamed_proto
की तरह ही, यह भी Target
प्रोटोकॉल बफ़र की स्ट्रीम को ndjson फ़ॉर्मैट में प्रिंट करता है.
रैंक के क्रम में हर टारगेट का लेबल प्रिंट करना
--output minrank --output maxrank
label
की तरह ही, minrank
और maxrank
आउटपुट फ़ॉर्मैट, नतीजे के ग्राफ़ में हर टारगेट के लेबल को प्रिंट करते हैं. हालांकि, ये टॉपोलॉजिकल क्रम में दिखने के बजाय, रैंक के क्रम में दिखते हैं. साथ ही, इनके आगे उनकी रैंक का नंबर दिखता है. इन पर, नतीजों के क्रम
--[no]order_results
फ़्लैग का असर नहीं होता (नतीजों के क्रम के बारे में नोट देखें).
इस फ़ॉर्मैट के दो वैरिएंट हैं: minrank
हर नोड को, रूट नोड से उस तक के सबसे छोटे पाथ की लंबाई के हिसाब से रैंक करता है.
"रूट" नोड (जिनमें कोई इनकमिंग एज नहीं है) की रैंक 0 होती है,
उनके उत्तराधिकारी की रैंक 1 होती है वगैरह. (हमेशा की तरह, एज किसी टारगेट से उसके लिए ज़रूरी शर्तों पर ले जाते हैं: वे टारगेट जिन पर वह निर्भर करता है.)
maxrank
हर नोड को रूट नोड से लेकर उसके सबसे लंबे पाथ तक की लंबाई के हिसाब से रैंक करता है. फिर से, "रूट" की रैंक 0 होती है. बाकी सभी नोड की रैंक, अपने सभी पूर्ववर्तियों की रैंक से एक ज़्यादा होती है.
किसी साइकल में मौजूद सभी नोड को एक ही रैंक माना जाता है. (ज़्यादातर ग्राफ़, साइकल नहीं होते. हालांकि, साइकल इसलिए होते हैं, क्योंकि BUILD
फ़ाइलों में गलत साइकल होते हैं.)
इन आउटपुट फ़ॉर्मैट से यह पता चलता है कि कोई ग्राफ़ कितना डीप है. अगर इनका इस्तेमाल deps(x)
, rdeps(x)
या allpaths
क्वेरी के नतीजे के लिए किया जाता है, तो रैंक नंबर, x
से उस रैंक में मौजूद किसी नोड तक के सबसे छोटे (minrank
के साथ) या सबसे लंबे (maxrank
के साथ) पाथ की लंबाई के बराबर होता है. maxrank
का इस्तेमाल करके, बिल्ड के चरणों का वह सबसे लंबा क्रम तय किया जा सकता है जो टारगेट बनाने के लिए ज़रूरी होता है.
उदाहरण के लिए, बाईं ओर मौजूद ग्राफ़ में दाईं ओर दिए गए आउटपुट दिखते हैं, जब --output minrank
और --output maxrank
को क्रमशः तय किया जाता है.
minrank 0 //c:c 1 //b:b 1 //a:a 2 //b:b.cc 2 //a:a.cc |
maxrank 0 //c:c 1 //b:b 2 //a:a 2 //b:b.cc 3 //a:a.cc |
हर टारगेट की जगह की जानकारी प्रिंट करना
--output location
label_kind
की तरह, यह विकल्प भी नतीजे में मौजूद हर टारगेट के लिए, टारगेट का टाइप और लेबल प्रिंट करता है. हालांकि, इसके प्रीफ़िक्स के तौर पर एक स्ट्रिंग होती है, जो फ़ाइल के नाम और लाइन नंबर के तौर पर टारगेट की जगह बताती है. यह फ़ॉर्मैट, grep
के आउटपुट जैसा दिखता है. इसलिए, Emacs या vi जैसे टूल, क्वेरी के आउटपुट का इस्तेमाल करके, मैच की सीरीज़ में एक से दूसरी जगह पर जा सकते हैं. इससे, Bazel क्वेरी टूल का इस्तेमाल, डिपेंडेंसी-ग्राफ़ के बारे में जानकारी देने वाले "BUILD फ़ाइलों के लिए grep" के तौर पर किया जा सकता है.
जगह की जानकारी, टारगेट के टाइप के हिसाब से अलग-अलग होती है. kind ऑपरेटर देखें. नियमों के लिए, BUILD
फ़ाइल में नियम के एलान की जगह की जानकारी प्रिंट की जाती है.
सोर्स फ़ाइलों के लिए, असल फ़ाइल की पहली लाइन की जगह को प्रिंट किया जाता है. जनरेट की गई फ़ाइल के लिए, उसे जनरेट करने वाले नियम की जगह को प्रिंट किया जाता है. (जनरेट की गई फ़ाइल की जगह का पता लगाने के लिए, क्वेरी टूल के पास ज़रूरत के मुताबिक जानकारी नहीं होती. साथ ही, अगर अब तक कोई बिल्ड नहीं किया गया है, तो हो सकता है कि वह मौजूद न हो.)
पैकेज का सेट प्रिंट करना
--output package
यह विकल्प उन सभी पैकेज का नाम प्रिंट करता है जिनमें नतीजे के सेट का कोई टारगेट शामिल है. नामों को वर्णमाला के क्रम में प्रिंट किया जाता है. डुप्लीकेट नाम शामिल नहीं किए जाते. औपचारिक तौर पर, यह लेबल (पैकेज, टारगेट) के सेट से पैकेज पर प्रोजेक्ट है.
एक्सटर्नल रिपॉज़िटरी में मौजूद पैकेज को @repo//foo/bar
के तौर पर फ़ॉर्मैट किया जाता है, जबकि डेटा स्टोर करने की मुख्य जगह में मौजूद पैकेज को foo/bar
के फ़ॉर्मैट में रखा जाता है.
deps(...)
क्वेरी के साथ, इस आउटपुट विकल्प का इस्तेमाल करके, उन पैकेज का सेट ढूंढा जा सकता है जिन्हें टारगेट के किसी सेट को बनाने के लिए, चुनना ज़रूरी है.
नतीजे का ग्राफ़ दिखाएं
--output graph
इस विकल्प की मदद से, क्वेरी का नतीजा AT&T GraphViz फ़ॉर्मैट में, डायरेक्टेड ग्राफ़ के तौर पर प्रिंट किया जाता है. यह फ़ॉर्मैट काफ़ी लोकप्रिय है. आम तौर पर, नतीजे को .png
या .svg
जैसी फ़ाइल में सेव किया जाता है.
(अगर आपके वर्कस्टेशन पर dot
प्रोग्राम इंस्टॉल नहीं है, तो इसे sudo apt-get install graphviz
कमांड का इस्तेमाल करके इंस्टॉल किया जा सकता है.)
इस्तेमाल करने के उदाहरण के लिए, नीचे दिए गए उदाहरण वाले सेक्शन को देखें.
यह आउटपुट फ़ॉर्मैट, allpaths
,
deps
या rdeps
क्वेरी के लिए खास तौर पर मददगार होता है. इन क्वेरी के नतीजों में, पाथ का एक सेट शामिल होता है. इसे --output label
जैसे लीनियर फ़ॉर्मैट में रेंडर करने पर, आसानी से विज़ुअलाइज़ नहीं किया जा सकता.
डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर के तौर पर दिखाया जाता है. इसका मतलब है कि
जगह के हिसाब से मिलते-जुलते नोड, कई लेबल के साथ एक नोड में मर्ज किए जाते हैं. इससे ग्राफ़ ज़्यादा कॉम्पैक्ट और पढ़ने लायक बन जाता है, क्योंकि आम तौर पर नतीजों के ग्राफ़ में बहुत ज़्यादा बार दोहराए जाने वाले पैटर्न होते हैं. उदाहरण के लिए, java_library
नियम, एक ही genrule
से जनरेट की गई सैकड़ों Java सोर्स फ़ाइलों पर निर्भर हो सकता है. फ़ैक्टर वाले ग्राफ़ में, इन सभी फ़ाइलों को एक ही नोड से दिखाया जाता है. --nograph:factored
विकल्प का इस्तेमाल करके, इस व्यवहार को बंद किया जा सकता है.
--graph:node_limit n
यह विकल्प, आउटपुट में किसी ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई तय करता है. लंबे लेबल काट दिए जाएंगे; -1 का इस्तेमाल करने पर, लेबल काटने की सुविधा बंद हो जाएगी. आम तौर पर, ग्राफ़ को फ़ैक्टर वाले फ़ॉर्म में प्रिंट किया जाता है. इस वजह से, नोड के लेबल बहुत लंबे हो सकते हैं. ग्राफ़विज़ 1024 वर्णों से ज़्यादा के लेबल को हैंडल नहीं कर सकता, जो इस विकल्प की डिफ़ॉल्ट वैल्यू है. इस विकल्प का तब तक कोई असर नहीं पड़ता, जब तक --output=graph
का इस्तेमाल नहीं किया जा रहा हो.
--[no]graph:factored
डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर वाले फ़ॉर्म में दिखाए जाते हैं, जैसा कि ऊपर बताया गया है.
--nograph:factored
तय करने पर, ग्राफ़ को फ़ैक्टर किए बिना प्रिंट किया जाता है. इससे ग्राफ़वीज़ का इस्तेमाल करके विज़ुअलाइज़ेशन करना अव्यावहारिक हो जाता है, लेकिन
आसान फ़ॉर्मैट से दूसरे टूल (जैसे कि ग्रेप) की मदद से आसानी से प्रोसेस किया जा सकता है. जब तक --output=graph
का इस्तेमाल नहीं किया जा रहा है, तब तक इस विकल्प का कोई असर नहीं होगा.
XML
--output xml
इस विकल्प की मदद से, नतीजों के तौर पर मिले टारगेट, एक्सएमएल फ़ॉर्मैट में प्रिंट किए जाते हैं. आउटपुट, इस तरह के एक्सएमएल हेडर से शुरू होता है
<?xml version="1.0" encoding="UTF-8"?>
<query version="2">
इसके बाद, नतीजों के ग्राफ़ में मौजूद हर टारगेट के लिए, टॉपोलॉजिकल क्रम में एक्सएमएल एलिमेंट के साथ जारी रहता है (जब तक कि बिना क्रम के नतीजों का अनुरोध न किया गया हो). इसके बाद, यह एलिमेंट,
</query>
file
तरह के टारगेट के लिए आसान एंट्री दी गई हैं:
<source-file name='//foo:foo_main.cc' .../>
<generated-file name='//foo:libfoo.so' .../>
हालांकि, नियमों के लिए एक्सएमएल को व्यवस्थित किया जाता है और इसमें नियम के सभी एट्रिब्यूट की परिभाषाएं होती हैं. इनमें वे एट्रिब्यूट भी शामिल होते हैं जिनकी वैल्यू, नियम की BUILD
फ़ाइल में साफ़ तौर पर नहीं बताई गई थी.
इसके अलावा, नतीजे में rule-input
और
rule-output
एलिमेंट शामिल होते हैं, ताकि डिपेंडेंसी ग्राफ़ की टॉपोलॉजी को फिर से बनाया जा सके. इसके लिए, यह जानना ज़रूरी नहीं है कि उदाहरण के लिए, srcs
एट्रिब्यूट के एलिमेंट, फ़ॉरवर्ड डिपेंडेंसी (ज़रूरी शर्तें) हैं और outs
एट्रिब्यूट के कॉन्टेंट, बैकवर्ड डिपेंडेंसी (उपभोक्ता) हैं.
अगर --noimplicit_deps
के बारे में बताया गया है, तो इंप्लिसिट डिपेंडेंसी के लिए rule-input
एलिमेंट को दबा दिया जाता है.
<rule class='cc_binary rule' name='//foo:foo' ...>
<list name='srcs'>
<label value='//foo:foo_main.cc'/>
<label value='//foo:bar.cc'/>
...
</list>
<list name='deps'>
<label value='//common:common'/>
<label value='//collections:collections'/>
...
</list>
<list name='data'>
...
</list>
<int name='linkstatic' value='0'/>
<int name='linkshared' value='0'/>
<list name='licenses'/>
<list name='distribs'>
<distribution value="INTERNAL" />
</list>
<rule-input name="//common:common" />
<rule-input name="//collections:collections" />
<rule-input name="//foo:foo_main.cc" />
<rule-input name="//foo:bar.cc" />
...
</rule>
टारगेट के हर एक्सएमएल एलिमेंट में एक name
एट्रिब्यूट होता है, जिसकी वैल्यू टारगेट का लेबल होती है. साथ ही, इसमें एक location
एट्रिब्यूट भी होता है, जिसकी वैल्यू --output location
से प्रिंट की गई टारगेट की जगह होती है.
--[no]xml:line_numbers
डिफ़ॉल्ट रूप से, एक्सएमएल आउटपुट में दिखाई गई जगहों में लाइन नंबर होते हैं.
--noxml:line_numbers
तय करने पर, लाइन नंबर नहीं छपते.
--[no]xml:default_values
डिफ़ॉल्ट रूप से, एक्सएमएल आउटपुट में वह नियम एट्रिब्यूट शामिल नहीं होता जिसकी वैल्यू उस तरह के एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू होती है. उदाहरण के लिए, ऐसा तब होता है, जब BUILD
फ़ाइल में उसकी वैल्यू न बताई गई हो या डिफ़ॉल्ट वैल्यू साफ़ तौर पर दी गई हो. इस विकल्प से ऐसे एट्रिब्यूट की वैल्यू, एक्सएमएल आउटपुट में शामिल हो जाती हैं.
रेगुलर एक्सप्रेशन
क्वेरी भाषा में रेगुलर एक्सप्रेशन, Java रेगुलर एक्सप्रेशन लाइब्रेरी का इस्तेमाल करते हैं. इसलिए, java.util.regex.Pattern
के लिए पूरे सिंटैक्स का इस्तेमाल किया जा सकता है.
बाहरी डेटा स्टोर करने की जगहों से क्वेरी करना
अगर बिल्ड, बाहरी रिपॉज़िटरी (WORKSPACE फ़ाइल में बताए गए) के नियमों पर निर्भर करता है, तो क्वेरी के नतीजों में ये डिपेंडेंसी शामिल होंगी. उदाहरण के लिए, अगर //foo:bar
, //external:some-lib
पर निर्भर है और //external:some-lib
की वैल्यू @other-repo//baz:lib
है, तो bazel query 'deps(//foo:bar)'
@other-repo//baz:lib
और //external:some-lib
, दोनों को डिपेंडेंसी के तौर पर शामिल करेगा.
बाहरी रिपॉज़िटरी, किसी बिल्ड की डिपेंडेंसी नहीं होती हैं. इसका मतलब है कि ऊपर दिए गए उदाहरण में, //external:other-repo
कोई डिपेंडेंसी नहीं है. हालांकि, //external
पैकेज के सदस्य के तौर पर इसके बारे में क्वेरी की जा सकती है. उदाहरण के लिए:
# Querying over all members of //external returns the repository.
bazel query 'kind(http_archive, //external:*)'
//external:other-repo
# ...but the repository is not a dependency.
bazel query 'kind(http_archive, deps(//foo:bar))'
INFO: Empty results