यह पेज, बेज़ल क्वेरी लैंग्वेज के लिए रेफ़रंस मैन्युअल है. इसका इस्तेमाल बिल्ड डिपेंडेंसी का विश्लेषण करने के लिए bazel query
का इस्तेमाल करने पर होता है. इससे
उन आउटपुट फ़ॉर्मैट के बारे में भी पता चलता है जो bazel query
पर काम करते हैं.
इस्तेमाल के उदाहरणों के लिए, Bazel Query कैसे करें देखें.
अतिरिक्त क्वेरी संदर्भ
पोस्ट-लोडिंग के चरण के टारगेट ग्राफ़ पर चलने वाले query
के अलावा,
Bazel में कार्रवाई के ग्राफ़ वाली क्वेरी और कॉन्फ़िगर करने लायक क्वेरी शामिल होती है.
कार्रवाई ग्राफ़ क्वेरी
कार्रवाई ग्राफ़ क्वेरी (aquery
), विश्लेषण के बाद कॉन्फ़िगर किए गए टारगेट ग्राफ़ पर काम करती है और कार्रवाइयां, आर्टफ़ैक्ट, और उनके संबंधों के बारे में जानकारी दिखाती है. aquery
तब काम आता है, जब आपको कॉन्फ़िगर किए गए टारगेट ग्राफ़ से जनरेट हुई कार्रवाइयाँ/आर्टफ़ैक्ट इस्तेमाल करने में दिलचस्पी हो.
उदाहरण के लिए, असल कमांड और उनके इनपुट, आउटपुट, और याद रखने के तरीके.
ज़्यादा जानकारी के लिए, क्वेरी से जुड़ी जानकारी देखें.
कॉन्फ़िगर करने लायक क्वेरी
पारंपरिक बेज़ल क्वेरी, पोस्ट लोड होने के फ़ेज़ टारगेट ग्राफ़ पर चलती है और इसलिए कॉन्फ़िगरेशन और उनसे जुड़े कॉन्सेप्ट की कोई जानकारी नहीं होती. खास तौर पर, इससे चुने हुए स्टेटमेंट का सही तरीके से समाधान नहीं होता है. इसके बजाय, यह सेक्शन में चुने गए सभी संभावित रिज़ॉल्यूशन को दिखाता है. हालांकि,
कॉन्फ़िगर करने लायक क्वेरी एनवायरमेंट, cquery
, कॉन्फ़िगरेशन को सही तरीके से हैंडल करता है, लेकिन इस मूल क्वेरी की सभी सुविधाएं नहीं देता है.
ज़्यादा जानकारी के लिए, क्वेरी रेफ़रंस देखें.
उदाहरण
लोग bazel query
का इस्तेमाल कैसे करते हैं? यहां कुछ सामान्य उदाहरण दिए गए हैं:
//foo
पेड़, //bar/baz
पर निर्भर क्यों है?
पाथ दिखाएं:
somepath(foo/..., //bar/baz:all)
सभी foo
जांचों में इस बात पर निर्भर कौन सी C++ लाइब्रेरी हैं कि foo_bin
टारगेट में ये चीज़ें शामिल नहीं हैं?
kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))
टोकन: टेक्सटिकल सिंटैक्स
क्वेरी की भाषा में एक्सप्रेशन नीचे दिए गए टोकन से मिलकर बनते हैं:
कीवर्ड, जैसे कि
let
. कीवर्ड, भाषा के रिज़र्व किए गए शब्द होते हैं और उनमें से हर एक के बारे में यहां बताया गया है. कीवर्ड का पूरा सेट यह है:शब्द, जैसे कि "
foo/...
" या ".*test rule
" या "//bar/baz:all
". अगर वर्ण का क्रम "उद्धरण चिह्न" हो (जिसे शुरू से शुरू और आखिर में डबल कोट किया जाता है, तो यह एक शब्द है). अगर किसी वर्ण क्रम को कोट नहीं किया गया है, तो उसे शब्द के रूप में पार्स किया जा सकता है. कोट नहीं किए गए शब्द, A-Za-z अक्षर, 0 से 9 तक के अंक, और विशेष वर्ण*/@.-_:$~[]
, तारे का चिह्न, फ़ॉरवर्ड स्लैश, पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर का निशान, टिल्ड, बायां स्क्वेयर ब्रेस, राइट स्क्वेयर ब्रेस से लिए गए वर्ण होते हैं. हालांकि, कोट नहीं किए गए शब्द हाइफ़न-
या तारे के निशान*
से शुरू नहीं हो सकते भले ही मिलते-जुलते [target name] (/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 क्वेरी के लिए भाषा के सिद्धांत
बेज़ल क्वेरी की भाषा, एक्सप्रेशन की एक भाषा है. हर एक्सप्रेशन, टारगेट के कुछ हिस्से के क्रम के सेट या फिर उसी तरह से, टारगेट के ग्राफ़ (डीएजी) की जांच करता है. सिर्फ़ इस तरह का डेटाटाइप.
सेट और ग्राफ़ एक ही डेटाटाइप को दिखाते हैं, लेकिन उसके अलग-अलग पहलुओं पर ध्यान देते हैं, उदाहरण के लिए:
- सेट करें: टारगेट का आंशिक क्रम दिलचस्प नहीं है.
- ग्राफ़: टारगेट का आंशिक क्रम ज़्यादा है.
डिपेंडेंसी ग्राफ़ में साइकल
बिल्ड डिपेंडेंसी ग्राफ़, असाइकलिक होने चाहिए.
क्वेरी वाली भाषा के लिए इस्तेमाल किए जाने वाले एल्गोरिदम, असाइकलिक ग्राफ़ में इस्तेमाल होते हैं. हालांकि, ये साइकल के हिसाब से काफ़ी मज़बूत होते हैं. साइकल के साथ क्या किया जाता है, इसकी जानकारी नहीं दी जाती है. इसलिए, इस बात पर भरोसा नहीं करना चाहिए.
इंप्लिसिट डिपेंडेंसी
BUILD
फ़ाइलों में साफ़ तौर पर बताई गई डिपेंडेंसी बनाने के अलावा,
Bazel नियमों में कुछ और इंप्लिसिट डिपेंडेंसी जोड़ता है. उदाहरण के लिए, हर Java नियम पूरी तरह से JavaBuilder पर निर्भर करता है. इंप्लिसिट डिपेंडेंसी,
उन एट्रिब्यूट का इस्तेमाल करके बनाई जाती हैं जो $
से शुरू होते हैं. इन्हें BUILD
फ़ाइलों में बदला नहीं जा सकता.
डिफ़ॉल्ट रूप से, क्वेरी के नतीजे को कैलकुलेट करते समय, bazel query
हर डिपेंडेंसी को ध्यान में रखती है. --[no]implicit_deps
विकल्प की मदद से, इसे बदला जा सकता है. ध्यान दें कि क्वेरी को कॉन्फ़िगरेशन में शामिल नहीं किया जाता है. इसलिए, हो सकता है कि टूल की संभावित संख्या को ध्यान में न रखा जाए.
आवाज़
Bazel क्वेरी भाषा एक्सप्रेशन बिल्ड डिपेंडेंसी ग्राफ़ पर काम करते हैं, जो ग्राफ़ को BUILD
सभी फ़ाइलों में नियम के सभी निर्देशों से साफ़ तौर पर परिभाषित किया जाता है. यह समझना ज़रूरी है कि यह ग्राफ़ कुछ हद तक एब्सट्रैक्ट है और इसमें किसी बिल्ड के सभी चरणों को पूरा करने के बारे में पूरी जानकारी नहीं दी गई है. बिल्ड करने के लिए, कॉन्फ़िगरेशन भी ज़रूरी है; ज़्यादा जानकारी के लिए, उपयोगकर्ता की गाइड का कॉन्फ़िगरेशन सेक्शन देखें.
अगर आप किसी बिल्ड के दौरान सभी सोर्स फ़ाइलों के सेट का हिसाब लगाने के लिए क्वेरी टूल का इस्तेमाल करते हैं, तो यह असल में ज़रूरी से ज़्यादा रिपोर्ट कर सकता है. उदाहरण के लिए, क्वेरी टूल में वे सभी फ़ाइलें शामिल होंगी जो मैसेज के अनुवाद के लिए ज़रूरी हैं, भले ही आप अपने बिल्ड में उस सुविधा का इस्तेमाल न करना चाहते हों.
ग्राफ़ ऑर्डर का संरक्षण पर
कार्रवाइयां, उनके सब-एक्सप्रेशन से इनहेरिट की गई सभी क्रम की
शर्तों को सुरक्षित रखती हैं. इसे "कुछ हद तक ऑर्डर को सुरक्षित रखने वाला कानून" माना जा सकता है. उदाहरण के तौर पर: अगर आप किसी खास टारगेट के आधार पर, डिपेंडेंसी को ट्रांज़िट समय के तौर पर तय करने के लिए क्वेरी जारी करते हैं, तो सेट का क्रम डिपेंडेंसी ग्राफ़ के हिसाब से लिया जाता है. अगर आप सिर्फ़ file
के टारगेट को शामिल करने के लिए सेट किए गए फ़िल्टर को फ़िल्टर करते हैं, तो नतीजे के सबसेट में टारगेट की हर जोड़ी के बीच, एक ही
ट्रांज़िट का क्रम होता है. भले ही, इनमें से कोई भी जोड़ी असल में मूल ग्राफ़ में सीधे तौर पर नहीं जुड़ी होती है.
(बिल्डिंग निर्भरता ग्राफ़ में कोई फ़ाइल-फ़ाइल किनारे नहीं हैं).
हालांकि, सभी ऑपरेटर ऑर्डर को सुरक्षित रखते हैं, लेकिन सेट करने से जुड़ी कार्रवाइयों जैसे कुछ ऑपरेशंस, ऑर्डर करने से जुड़ी किसी भी शर्त को पेश नहीं करते. इस एक्सप्रेशन पर विचार करें:
deps(x) union y
फ़ाइनल सेट के क्रम की गारंटी, सब-एक्सप्रेशन के क्रम में आने वाली सभी रुकावटों को बनाए रखती है. जैसे, x
की कुछ समय के लिए जो डिपेंडेंसी होती हैं, वे एक-दूसरे के हिसाब से सही होती हैं. हालांकि, क्वेरी में y
में टारगेट के क्रम के बारे में और न ही y
में टारगेट से जुड़े टारगेट के क्रम के बारे में कोई गारंटी दी जाती है (y
में मौजूद टारगेट को छोड़कर, जो deps(x)
में भी होते हैं).
ऑर्डर देने से जुड़ी शर्तों को लागू करने वाले ऑपरेटर में ये शामिल हैं:
allpaths
, deps
, rdeps
, somepath
, और टारगेट पैटर्न वाइल्डकार्ड
package:*
, dir/...
वगैरह.
Sky क्वेरी
Sky Query, क्वेरी का एक ऐसा मोड है जो किसी खास यूनिवर्सल स्कोप पर काम करता है.
विशेष फ़ंक्शन केवल SkyQuery में उपलब्ध हैं
Sky Query मोड में अन्य क्वेरी फ़ंक्शन allrdeps
और
rbuildfiles
हैं. ये फ़ंक्शन, पूरे यूनिवर्स के दायरे में काम करते हैं (इसलिए, इन्हें सामान्य क्वेरी का कोई मतलब नहीं बनता).
ब्रह्मांड का दायरा तय करना
इन दो फ़्लैग को पास करके, Sky Query मोड को चालू किया जाता है:
(--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
की सुविधा इस्तेमाल की जा सकती है. खास तौर पर, ऐसा तब होता है, जब
--universe_scope
के विकल्प के लिए, आपको खुद क्वेरी एक्सप्रेशन को पार्स करना पड़ता है.
इसलिए, allrdeps
और rbuildfiles
जैसे स्कोप के इस्तेमाल वाले क्वेरी एक्सप्रेशन के लिए, --infer_universe_scope
का इस्तेमाल सिर्फ़ तब करें, जब इसका व्यवहार आपकी पसंद के मुताबिक हो.
डिफ़ॉल्ट क्वेरी की तुलना में स्काई क्वेरी के कुछ फ़ायदे और नुकसान हैं. इसका मुख्य नुकसान यह है कि यह ग्राफ़ के क्रम के हिसाब से आउटपुट नहीं देता, इसलिए कुछ आउटपुट फ़ॉर्मैट इस्तेमाल नहीं किए जा सकते. इसका फ़ायदा यह है कि यह दो ऑपरेटर (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
एक्सप्रेशन का मूल्यांकन, expr2 के नतीजे से मिलता-जुलता है, जिसमें वैरिएबल name की सभी मुफ़्त मेट्रिक को expr1 की वैल्यू से बदला जाता है.
उदाहरण के लिए, 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 पैरामीटर को शामिल नहीं किया जाता है, तो खोज को बिना किसी प्रतिबंध के
बनाया जाता है: यह पूर्वापेक्षाओं के रिफ़्लेक्सिव ट्रांज़िटिव ट्रांज़िशन की गिनती करता है.
रिवर्स डिपेंडेंसी को कुछ समय के लिए बंद करना: आरडीपी
expr ::= rdeps(expr, expr)
| rdeps(expr, expr, depth)
rdeps(u, x)
ऑपरेटर, सेट किए गए आर्ग्युमेंट सेट की रिवर्स डिपेंडेंसी
x की जांच करता है.
यह ब्रह्मांड सेट के ट्रांज़िट समय में,u के अंदर होता है.
नतीजे के तौर पर दिखने वाला ग्राफ़, डिपेंडेंसी से जुड़े संबंध के हिसाब से क्रम में लगाया जाता है. ज़्यादा जानकारी के लिए ग्राफ़ का क्रम सेक्शन देखें.
rdeps
ऑपरेटर, विकल्प के तौर पर एक वैकल्पिक आर्ग्युमेंट स्वीकार करता है. यह आर्ग्युमेंट एक लिटरल होता है, जिसमें खोज के लिए ऊपर की तरफ़ की सीमा तय होती है. नतीजे वाले ग्राफ़ में, आर्ग्युमेंट सेट में सिर्फ़ किसी नोड से बताई गई डेप्थ की दूरी वाले नोड शामिल होते हैं. इसलिए, rdeps(//foo, //common, 1)
//foo
के ट्रांज़िट समय में सभी नोड का मूल्यांकन करता है, जो सीधे //common
पर निर्भर होता है. (ये संख्याएं, minrank
आउटपुट फ़ॉर्मैट में दिखाई गई रैंक से मेल खाती हैं.) अगर depth पैरामीटर को शामिल नहीं किया जाता है, तो खोज को जोड़ा नहीं जाता.
सभी रिवर्स डिपेंडेंसी को ट्रांज़िट समय के लिए बंद करना: Allrdeps
expr ::= allrdeps(expr)
| allrdeps(expr, depth)
allrdeps
ऑपरेटर, rdeps
ऑपरेटर की तरह ही काम करता है. हालांकि, इसमें "यूनिवर्स सेट" वह होता है जिसके बारे में --universe_scope
फ़्लैग का आकलन
किया जाता है, न कि अलग से बताए जाने पर. इसलिए, अगर
--universe_scope=//foo/...
पास हो गया है, तो allrdeps(//bar)
rdeps(//foo/..., //bar)
के बराबर होगा.
एक ही पैकेज में डायरेक्ट रिवर्स डिपेंडेंसी: same_pkg_direct_rdeps
expr ::= same_pkg_direct_rdeps(expr)
same_pkg_direct_rdeps(x)
ऑपरेटर, टारगेट के ऐसे पूरे सेट से जांच करता है जो आर्ग्युमेंट सेट में टारगेट के समान पैकेज में होता है और जो इस पर सीधे तौर पर निर्भर होता है.
टारगेट के पैकेज से निपटना: भाई-बहन
expr ::= siblings(expr)
siblings(x)
ऑपरेटर, टारगेट के पूरे सेट से मेल खाते हैं. ये सेट, आर्ग्युमेंट सेट के टारगेट के बराबर होते हैं.
वैकल्पिक विकल्प: कुछ
expr ::= some(expr)
| some(expr, count )
some(x, k)
ऑपरेटर,
अपने तर्क के आधार पर सेट किए गए x वैल्यू में से, ज़्यादा से ज़्यादा k टारगेट को अपने हिसाब से चुनता है और ऐसे सेट का आकलन करता है जिनमें सिर्फ़ वही टारगेट होते हैं. पैरामीटर k ज़रूरी नहीं है. अगर
यह मौजूद नहीं है, तो सिंगलटन सेट को सिर्फ़ एक टारगेट के साथ चुना जाएगा. अगर आर्ग्युमेंट सेट का साइज़ x
k से कम है, तो पूरा आर्ग्युमेंट सेट
x दिखाया जाएगा.
उदाहरण के लिए, एक्सप्रेशन some(//foo:main union //bar:baz)
किसी सिंगलटन सेट के लिए मूल्यांकन करता है, जिसमें //foo:main
या //bar:baz
शामिल होते हैं—हालांकि, इनमें से किसी के बारे में नहीं बताया गया है. एक्सप्रेशन some(//foo:main union //bar:baz, 2)
या
some(//foo:main union //bar:baz, 3)
, //foo:main
और
//bar:baz
, दोनों दिखाता है.
अगर आर्ग्युमेंट सिंगलटन है, तो some
पहचान फ़ंक्शन का आकलन करता है: some(//foo:main)
, //foo:main
के बराबर है.
अगर बताए गए आर्ग्युमेंट सेट खाली हैं, तो यह एक गड़बड़ी है, जैसा कि एक्सप्रेशन some(//foo:main intersect //bar:baz)
में हुआ है.
पाथ ऑपरेटर: ऐम्पपाथ, सभी पाथ
expr ::= somepath(expr, expr)
| allpaths(expr, expr)
somepath(S, E)
और
allpaths(S, E)
ऑपरेटर टारगेट के दो सेट के बीच के पाथ की गिनती करते हैं. दोनों क्वेरी में दो
आर्ग्युमेंट स्वीकार किए जाते हैं, शुरुआती पॉइंट का एक सेट S होता है और एंड पॉइंट का एक सेट
E होता है. somepath
, कुछ आर्बिट्रेरी पाथ में मौजूद नोड के ग्राफ़ को, S में मौजूद टारगेट से E के टारगेट में दिखाता है. allpaths
, सभी पाथ पर मौजूद नोड के ग्राफ़ को, S में मौजूद किसी भी टारगेट से E के किसी टारगेट को दिखाता है.
नतीजे के तौर पर दिखने वाले ग्राफ़, डिपेंडेंसी से जुड़े संबंध के हिसाब से क्रम में लगाए जाते हैं. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम वाला सेक्शन देखें.
somepath(S1 + S2, E) , एक संभावित नतीजा. |
somepath(S1 + S2, E) , एक और नतीजा. |
allpaths(S1 + S2, E) |
टारगेट टाइप फ़िल्टर करने की सुविधा: टाइप
expr ::= kind(word, expr)
kind(pattern, input)
ऑपरेटर टारगेट के सेट पर फ़िल्टर लागू करता है और उन टारगेट को खारिज कर देता है जो अनुमानित तरह के नहीं होते. pattern
पैरामीटर बताता है कि किस तरह का टारगेट मैच करना है.
उदाहरण के लिए, BUILD
फ़ाइल (पैकेज p
के लिए) में बताए गए चार टारगेट के टाइप, टेबल में दिखाए गए हैं:
कोड | टारगेट | दयालु |
---|---|---|
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", ) |
//p:a |
नियम का नियम |
//p:a.in |
सोर्स फ़ाइल | |
//p:a.out |
जनरेट की गई फ़ाइल | |
//p:BUILD |
सोर्स फ़ाइल |
इस तरह, kind("cc_.* rule", foo/...)
, सभी 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 (निरंतर रूप में, जैसे कि x) के लेबल में रेगुलर एक्सप्रेशन 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))
data
डिपेंडेंसी में, कम से कम एक वैल्यू तय करने वाली //foo
डिपेंडेंसी के सभी नियम चुने जाएंगे. //
और :
की वजह से, हर लेबल कम से कम तीन वर्ण लंबा होगा.
सूची-प्रकार विशेषता में विशेष value
के साथ //foo
निर्भरता के सभी नियम चुनने के लिए, इनका उपयोग करें
attr("tags", "[\[ ]value[,\]]", deps(//foo))
यह इसलिए काम करता है, क्योंकि value
से पहले के वर्ण [
होंगे या स्पेस और value
के बाद का वर्ण कॉमा या ]
होगा.
नियम किसको दिखे फ़िल्टर करना: दिख रहा है
expr ::= visible(expr, expr)
visible(predicate, input)
ऑपरेटर, टारगेट के किसी सेट पर कोई फ़िल्टर लागू करता है. साथ ही, सेट किए गए टारगेट को हटा देता है.
पहला तर्क, predicate टारगेट का एक सेट है, जिसे आउटपुट में सभी टारगेट को दिखना चाहिए. visible एक्सप्रेशन उस सेट का आकलन करता है जिसमें सभी टारगेट x शामिल होते हैं, ताकि x सेट input का सदस्य हो. साथ ही, y को x में मौजूद सभी टारगेट के लिए y दिखता है. उदाहरण के लिए :
visible(//foo, //bar:*)
//bar
के उन टारगेट को चुनेगा जिन पर //foo
निर्भर करता है. हालांकि, ये विज़िबिलिटी से जुड़ी पाबंदियों के बिना होते हैं.
टाइप लेबल के नियम एट्रिब्यूट का आकलन: लेबल
expr ::= labels(word, expr)
labels(attr_name, inputs)
ऑपरेटर inputs के कुछ नियम में
"label" या "लेबल की सूची" प्रकार की विशेषता 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
नियमों के ज़रिए सीधे तौर पर या किसी दूसरे तरीके से इस्तेमाल किया जाता है.
पैकेज की परिभाषा फ़ाइलें: buildfile
expr ::= buildfiles(expr)
buildfiles(x)
ऑपरेटर, फ़ाइलों की उस सेट की वैल्यू दिखाता है जो सेट x में मौजूद हर टारगेट के पैकेज के बारे में जानकारी देता है. इसका मतलब है कि हर पैकेज के लिए, उसकी BUILD
फ़ाइल और load
के ज़रिए .bzl की सभी फ़ाइलों के पैकेज की जानकारी देता है. ध्यान दें कि यह
load
ed फ़ाइलों वाले पैकेज की BUILD
फ़ाइलें भी दिखाता है.
आम तौर पर, इस ऑपरेटर का इस्तेमाल यह तय करने के लिए किया जाता है कि तय किया गया टारगेट बनाने के लिए किन फ़ाइलों या पैकेज की ज़रूरत है. आम तौर पर, इनका इस्तेमाल --output package
विकल्प के साथ किया जाता है. उदाहरण के लिए,
bazel query 'buildfiles(deps(//foo))' --output package
ऐसे सभी पैकेज का सेट दिखाता है जिन पर //foo
कुछ समय के लिए निर्भर करता है.
पैकेज की परिभाषा फ़ाइलें: rbuildfiles
expr ::= rbuildfiles(word, ...)
rbuildfiles
ऑपरेटर, पाथ फ़्रैगमेंट की कॉमा-सेपरेटेड लिस्ट लेता है और उन BUILD
फ़ाइलों का सेट दिखाता है जो कुछ समय के लिए इन फ़्रैगमेंट पर निर्भर करते हैं. उदाहरण के लिए, अगर
//foo
एक पैकेज है, तो rbuildfiles(foo/BUILD)
से
//foo:BUILD
टारगेट वैल्यू मिलेगी. अगर foo/BUILD
फ़ाइल में
load('//bar:file.bzl'...
मौजूद है, तो rbuildfiles(bar/file.bzl)
से
//foo:BUILD
टारगेट के साथ-साथ ऐसी किसी भी दूसरी BUILD
फ़ाइल के लिए टारगेट रिटर्न होगा जो //bar:file.bzl
को लोड करता है
--universe_scope
फ़्लैग में बताया गया है. जो फ़ाइलें सीधे BUILD
फ़ाइलों और .bzl
फ़ाइलों से मेल नहीं खातीं, उनके नतीजों पर कोई असर नहीं पड़ता. उदाहरण के लिए, सोर्स फ़ाइलों (जैसे, foo.cc
) को अनदेखा किया जाता है,
भले ही उनका नाम BUILD
फ़ाइल में साफ़ तौर पर बताया गया हो. हालांकि, सिमलिंक का इस्तेमाल किया जाता है. इसलिए, अगर
foo/BUILD
को bar/BUILD
के लिए सिमलिंक बनाया गया है, तो
rbuildfiles(bar/BUILD)
, नतीजों में //foo:BUILD
को शामिल करेगा.
rbuildfiles
ऑपरेटर, नैतिक तौर पर, buildfiles
ऑपरेटर के उलट है. हालांकि, यह नैतिक व्युत्क्रम
एक दिशा में ज़्यादा मज़बूती से होल्ड करता है: rbuildfiles
के आउटपुट ठीक buildfiles
के इनपुट की तरह हैं; पहले वाले में पैकेज में सिर्फ़ BUILD
फ़ाइल टारगेट होंगे, और बाद वाले में ऐसे टारगेट हो सकते हैं. दूसरी तरफ़, यह बातचीत कमज़ोर है. buildfiles
ऑपरेटर के आउटपुट, सभी पैकेज और .bzl
दिए गए इनपुट के हिसाब से फ़ाइलें. हालांकि, rbuildfiles
ऑपरेटर के इनपुट, वे टारगेट नहीं होते हैं, बल्कि ये उस टारगेट फ़्रैगमेंट होते हैं जो टारगेट के मुताबिक होते हैं.
पैकेज परिभाषा फ़ाइलें: लोड फ़ाइलें
expr ::= loadfiles(expr)
loadfiles(x)
ऑपरेटर, Starlark फ़ाइलों का सेट दिखाता है, जो xसेट में हर टारगेट के पैकेज को लोड करने के लिए ज़रूरी हैं. दूसरे शब्दों में, यह हर पैकेज के लिए उसकी .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
फ़्लैग की काम करने की
सुविधा का एक सबसेट होता है और उसे बंद कर दिया जाता है.)
इस फ़्लैग की डिफ़ॉल्ट वैल्यू auto
है. इससे, जानकारी के हिसाब से क्रम
मिलता है. हालांकि, जब somepath(a,b)
का इस्तेमाल किया जाएगा, तब नतीजे
deps
के हिसाब से प्रिंट किए जाएंगे.
जब no
का फ़्लैग, --output
,
build
, label
, label_kind
, location
, package
, proto
या
xml
में से कोई एक हो, तो आउटपुट को आर्बिट्रेरी ऑर्डर में प्रिंट किया जाएगा. आम तौर पर, यह
सबसे तेज़ विकल्प है. हालांकि, यह --output
के graph
, minrank
या maxrank
में से किसी एक होने पर काम नहीं करता है. इन फ़ॉर्मैट में, बेज़ल हमेशा डिपेंडेंसी ऑर्डर या रैंक के हिसाब से नतीजों को प्रिंट करता है.
जब deps
का फ़्लैग होता है, तो बैज़ेल नतीजों को समय के हिसाब से प्रिंट करता है. इसका मतलब है कि डिपेंडेंसी पहले है. हालांकि, ऐसे नोड जो डिपेंडेंसी ऑर्डर में ऑर्डर नहीं किए गए होते हैं
(क्योंकि एक से दूसरे में कोई पाथ नहीं होता) किसी भी क्रम में प्रिंट किए जा सकते हैं.
full
का फ़्लैग होने पर, बैज़ेल नोड को पूरी तरह से डेटरमिनिस्टिक (कुल) क्रम में प्रिंट करता है.
सबसे पहले, सभी नोड को अंग्रेज़ी वर्णमाला के क्रम में लगाया जाता है. फिर, सूची में मौजूद हर नोड का इस्तेमाल, ऑर्डर के बाद सबसे पहले की जाने वाली खोज की शुरुआत के तौर पर किया जाता है. इस खोज में, जाने वाले नोड के आउटगोइंग किनारों को बाद वाले नोड के वर्णानुक्रम में पार किया जाता है. आखिर में, नोड उसी क्रम में प्रिंट किए जाते हैं जिस क्रम में उन्हें देखा गया था.
इस क्रम में नोड प्रिंट करने की प्रक्रिया धीमी हो सकती है. इसलिए इसका इस्तेमाल सिर्फ़ तब किया जाना चाहिए जब तय करने वाला नियम अहम हो.
टारगेट का सोर्स फ़ॉर्म प्रिंट करें, जैसा कि वे BUILD में दिखता है
--output build
इस विकल्प को चुनने पर, हर टारगेट इस तरह से दिखाया जाता है जैसे कि उसे BUILD भाषा में हाथ से लिखा गया हो. सभी वैरिएबल और फ़ंक्शन कॉल (जैसे कि ग्लोब, मैक्रो) को बड़ा कर दिया जाता है. इससे, स्टारलार्क मैक्रो का असर देखा जा सकता है. इसके अलावा, हर असरदार नियम एक
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 फ़ाइलों के लिए डिपेंडेंसी-ग्राफ़-अवेयर" ग्रेप के तौर पर किया जा सकता है.
टारगेट करने का तरीका, टारगेट करने के तरीके के हिसाब से अलग-अलग होता है (kind ऑपरेटर देखें). नियमों के लिए, BUILD
फ़ाइल में नियम के एलान की जगह को प्रिंट किया जाता है.
सोर्स फ़ाइलों के लिए, असल फ़ाइल की लाइन 1 की जगह
प्रिंट की जाती है. जनरेट की गई फ़ाइल के लिए, उसे जनरेट करने वाले नियम की जगह की जानकारी प्रिंट की जाती है. (क्वेरी टूल में जनरेट की गई फ़ाइल का
असल स्थान ढूंढने के लिए काफ़ी जानकारी नहीं है, और किसी भी स्थिति में यह मौजूद नहीं हो सकता है अगर बिल्ड का काम अभी तक नहीं हुआ है.)
पैकेज का सेट प्रिंट करें
--output package
यह विकल्प, ऐसे सभी पैकेज के नाम को प्रिंट करता है जो नतीजों के सेट में मौजूद कुछ टारगेट से जुड़े हैं. नामों को लेगसी क्रम में प्रिंट किया जाता है; डुप्लीकेट शामिल नहीं किए जाते हैं. औपचारिक रूप से, यह पैकेज पर (लेबल, टारगेट) सेट से पैकेज पर अनुमान है.
बाहरी डेटा स्टोर करने की जगह में पैकेज को @repo//foo/bar
के तौर पर फ़ॉर्मैट किया जाता है, जबकि मुख्य डेटा स्टोर करने की जगह में पैकेज को foo/bar
के तौर पर फ़ॉर्मैट किया जाता है.
deps(...)
क्वेरी के साथ, इस आउटपुट विकल्प का इस्तेमाल करके पैकेज का एक सेट ढूंढा जा सकता है. टारगेट का कोई सेट बनाने के लिए, इस सेट के लिए चेकआउट करना ज़रूरी है.
नतीजे का ग्राफ़ दिखाएं
--output graph
इस विकल्प की वजह से, क्वेरी का नतीजा लोकप्रिय AT&T ग्राफ़वीज़ फ़ॉर्मैट में
ग्राफ़ के रूप में प्रिंट होता है. आम तौर पर,
नतीजे को फ़ाइल में सेव किया जाता है, जैसे कि .png
या .svg
.
(अगर आपके वर्कस्टेशन पर dot
प्रोग्राम इंस्टॉल नहीं किया गया है, तो sudo apt-get install graphviz
निर्देश का इस्तेमाल करके उसे इंस्टॉल किया जा सकता है.) सैंपल शुरू करने के लिए, नीचे दिया गया उदाहरण देखें.
यह आउटपुट फ़ॉर्मैट खास तौर पर allpaths
,
deps
या rdeps
क्वेरी के लिए कारगर है, जिसके नतीजे में
पाथ का सेट शामिल होता है. इसे लीनियर फ़ॉर्म में रेंडर करते समय, आसानी से विज़ुअलाइज़ नहीं किया जा सकता. जैसे, --output label
के साथ रेंडर करना.
डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर किए गए रूप में रेंडर होता है. इसका मतलब है कि
क्यूपोलॉजिकल तौर पर बराबर नोड को एक नोड में एक साथ लेबल कर दिया जाता है. यह ग्राफ़ को ज़्यादा छोटा और पढ़ने लायक बनाता है, क्योंकि आम तौर पर दिखने वाले नतीजों के ग्राफ़ में बहुत बार-बार एक ही पैटर्न होता है. उदाहरण के लिए, java_library
नियम उन सभी Java सोर्स फ़ाइलों पर निर्भर हो सकता है जो एक ही genrule
से जनरेट होती हैं. हालांकि, फ़ैक्टर के ग्राफ़ में ये सभी फ़ाइलें एक नोड से दिखती हैं. --nograph:factored
विकल्प की मदद से, इस व्यवहार को बंद किया जा सकता है.
--graph:node_limit n
यह विकल्प, आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई बताता है. लंबे लेबल छोटे कर दिए जाएंगे; -1
काट-छांट बंद कर देता है. नोड के लेबल की लंबाई बहुत ज़्यादा होने की वजह से, आम तौर पर ग्राफ़ प्रिंट होते हैं. ग्राफ़वीज़ 1024 वर्णों से बड़े लेबल प्रबंधित नहीं कर सकता, जो इस विकल्प का डिफ़ॉल्ट मान है. इस विकल्प का तब तक असर नहीं होता, जब तक --output=graph
का इस्तेमाल नहीं किया जाता.
--[no]graph:factored
डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर के रूप में दिखाए जाते हैं, जैसा कि ऊपर बताया गया है.
--nograph:factored
तय होने पर, ग्राफ़ को
फ़ैक्टर किए बिना प्रिंट किया जाता है. इससे ग्राफ़वीज़ का इस्तेमाल करने वाला विज़ुअलाइज़ेशन मुश्किल होता है, लेकिन आसान फ़ॉर्मैट को दूसरे टूल (जैसे कि ग्रेप) से प्रोसेस करना आसान हो सकता है. इस विकल्प का कोई असर नहीं होता
जब तक --output=graph
का इस्तेमाल नहीं किया जाता.
एक्सएमएल
--output xml
इस विकल्प की वजह से नतीजे, टारगेट को एक्सएमएल फ़ॉर्म में प्रिंट होते हैं. आउटपुट किसी 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