यह पेज इस्तेमाल की गई बेज़ल क्वेरी लैंग्वेज के लिए रेफ़रंस मैन्युअल है
जबकि बिल्ड डिपेंडेंसी का विश्लेषण करने के लिए bazel query
का इस्तेमाल किया जाता है. यह भी
bazel query
पर काम करने वाले आउटपुट फ़ॉर्मैट के बारे में बताता है.
काम के उदाहरणों के लिए, Baez क्वेरी का इस्तेमाल करने का तरीका देखें.
अन्य क्वेरी का रेफ़रंस
पोस्ट-लोडिंग फ़ेज़ के टारगेट ग्राफ़ पर चलने वाले query
के अलावा,
Baज़ल में, ऐक्शन ग्राफ़ क्वेरी और कॉन्फ़िगर की जा सकने वाली क्वेरी शामिल होती है.
ऐक्शन ग्राफ़ क्वेरी
कार्रवाई ग्राफ़ क्वेरी (aquery
), विश्लेषण के बाद कॉन्फ़िगर की गई क्वेरी पर काम करती है
टारगेट ग्राफ़ और कार्रवाइयों, आर्टफ़ैक्ट, और
करते हैं. aquery
तब फ़ायदेमंद है, जब आपकी दिलचस्पी इसमें हो
कॉन्फ़िगर किए गए टारगेट ग्राफ़ से जनरेट की गई कार्रवाइयों/आर्टफ़ैक्ट की प्रॉपर्टी.
उदाहरण के लिए, असल में चलाए जाने वाले निर्देश और उनके इनपुट, आउटपुट, और याद रखने के तरीके.
ज़्यादा जानकारी के लिए, क्वेरी का रेफ़रंस देखें.
कॉन्फ़िगर की जा सकने वाली क्वेरी
ट्रेडिशनल Basel क्वेरी, पोस्ट-लोडिंग फ़ेज़ के टारगेट ग्राफ़ पर चलती है और
इसलिए, इसमें कॉन्फ़िगरेशन और उनसे जुड़े कॉन्सेप्ट का कोई कॉन्सेप्ट नहीं है. खास तौर पर,
यह चुनिंदा स्टेटमेंट का सही तरीके से समाधान नहीं करता
और इसके बजाय, यह जवाब को चुनने के सभी संभावित रिज़ॉल्यूशन दिखाता है. हालांकि,
कॉन्फ़िगर किया जा सकने वाला क्वेरी एनवायरमेंट, cquery
, कॉन्फ़िगरेशन को सही तरीके से हैंडल करता है, लेकिन
इस ओरिजनल क्वेरी की सभी सुविधाएं उपलब्ध नहीं कराता है.
ज़्यादा जानकारी के लिए, cquery का रेफ़रंस देखें.
उदाहरण
लोग bazel query
का इस्तेमाल कैसे करते हैं? यहां कुछ सामान्य उदाहरण दिए गए हैं:
//foo
ट्री, //bar/baz
पर क्यों निर्भर करता है?
कोई पाथ दिखाएं:
somepath(foo/..., //bar/baz:all)
C++ लाइब्रेरी किस तरह के foo
टेस्ट करती हैं, यह इस बात पर निर्भर करता है
foo_bin
के टारगेट में ऐसा नहीं है?
kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))
टोकन: लेक्सिकल सिंटैक्स
क्वेरी लैंग्वेज में एक्सप्रेशन इन चीज़ों से बने होते हैं टोकन:
कीवर्ड, जैसे
let
. कीवर्ड इनमें से हर भाषा के बारे में नीचे बताया गया है. पूरा सेट कीवर्ड का है:शब्द, जैसे कि "
foo/...
" या ".*test rule
" या "//bar/baz:all
" का इस्तेमाल करें. अगर कोई वर्ण का क्रम "कोट" है (एकल कोट से शुरू और खत्म होता है ' या डबल-कोट ") से शुरू और खत्म होता है. यह एक शब्द है. अगर कोई वर्ण क्रम को कोट नहीं किया गया है, इसे अब भी शब्द के रूप में पार्स किया जा सकता है. बिना कोट वाले शब्द, क्रम होते हैं अक्षर A-Za-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"
का कोट देना ज़रूरी नहीं है. हालांकि, इससे कोई नुकसान नहीं होता.विराम चिह्न, जैसे कि ब्रैकेट
()
, पीरियड.
, और कॉमा,
. शब्द विराम चिह्नों वाले (ऊपर दिए गए अपवादों को छोड़कर) को कोट करना चाहिए.
कोट किए गए शब्द के बाहर मौजूद व्हाइटस्पेस वर्णों को अनदेखा कर दिया जाता है.
बेज़ेल क्वेरी लैंग्वेज के कॉन्सेप्ट
बेज़ेल क्वेरी लैंग्वेज, एक्सप्रेशन की भाषा है. कई एक्सप्रेशन, टारगेट के आंशिक रूप से क्रम में लगाए गए सेट का आकलन करता है, या साथ ही, टारगेट का ग्राफ़ (डीएजी) है. सिर्फ़ यही एक डेटा टाइप में एक्सपोर्ट किया जा सकता है.
सेट और ग्राफ़ एक ही डेटा टाइप को दिखाते हैं, लेकिन अलग-अलग डेटा टाइप को इसके अलग-अलग पहलू देखें, उदाहरण के लिए:
- सेट करें: टारगेट के आंशिक क्रम में दिलचस्पी नहीं है.
- ग्राफ़: टारगेट का आंशिक क्रम अहम है.
डिपेंडेंसी ग्राफ़ में साइकल
बिल्ड डिपेंडेंसी ग्राफ़ एकाइकिक होने चाहिए.
क्वेरी भाषा के लिए इस्तेमाल किए जाने वाले एल्गोरिदम इसमें इस्तेमाल किए जाने के लिए हैं एकिकिक ग्राफ़, लेकिन साइकल के हिसाब से ज़्यादा सटीक होते हैं. इसके तरीके के बारे में जानकारी साइकल के बारे में नहीं बताया गया है और इस पर भरोसा नहीं किया जाना चाहिए.
इंप्लिसिट डिपेंडेंसी
BUILD
फ़ाइलों में साफ़ तौर पर बताई गई डिपेंडेंसी बनाने के अलावा,
Baज़ल, नियमों में अतिरिक्त इंप्लिसिट डिपेंडेंसी जोड़ता है. उदाहरण के लिए
प्रत्येक Java नियम स्पष्ट रूप से JavaBuilder पर निर्भर करता है. इंप्लिसिट डिपेंडेंसी
$
से शुरू होने वाले एट्रिब्यूट का इस्तेमाल करके बनाए जाते हैं और
BUILD
फ़ाइलों में ओवरराइड नहीं किया जा सकता.
डिफ़ॉल्ट तौर पर bazel query
, इंप्लिसिट डिपेंडेंसी को ध्यान में रखता है
क्वेरी के नतीजे का हिसाब लगाते समय. इस व्यवहार को इससे बदला जा सकता है:
--[no]implicit_deps
विकल्प. ध्यान दें कि क्वेरी माना नहीं जाता
कॉन्फ़िगरेशन, संभावित टूलचेन पर कभी विचार नहीं किया जाता.
आवाज़
बेज़ेल क्वेरी लैंग्वेज एक्सप्रेशन बिल्ड में ऑपरेट होते हैं
डिपेंडेंसी ग्राफ़, जो सभी
सभी BUILD
फ़ाइलों में नियम की घोषणा. यह समझना ज़रूरी है कि
यह ग्राफ़ कुछ हद तक ऐब्स्ट्रैक्ट है, और
बिल्ड के सभी चरणों को पूरा करने के तरीके का पूरा ब्यौरा. तय सीमा में
बिल्ड करने के लिए, कॉन्फ़िगरेशन की भी ज़रूरत होती है;
कॉन्फ़िगरेशन देखें
सेक्शन पढ़ें.
बेज़ेल क्वेरी लैंग्वेज में किसी एक्सप्रेशन की जांच करने का नतीजा सभी कॉन्फ़िगरेशन के लिए सही है, इसका मतलब है कि यह काफ़ी हद तक सटीक नहीं, बल्कि कंज़र्वेटिव अनुमान. अगर आपको सभी ज़रूरी सोर्स फ़ाइलों के सेट का पता लगाने के लिए क्वेरी टूल का इस्तेमाल करें बनाने के दौरान, इससे ज़रूरत से ज़्यादा रिपोर्ट भेजी जा सकती है क्योंकि, उदाहरण के लिए, क्वेरी टूल में वे सभी फ़ाइलें शामिल होंगी अनुवाद का समर्थन करना होगा, भले ही आप उस सुविधा का इस्तेमाल अपने बिल्ड में किया होगा.
ग्राफ़ ऑर्डर के संरक्षण पर
ऑपरेशन किसी भी क्रम को बनाए रखते हैं
इन्हें अपने सब-एक्सप्रेशन कंस्ट्रेंट से इनहेरिट किया जाता है. आप सोच सकते हैं कि
इसे "आंशिक क्रम के संरक्षण का नियम" कहते हैं. इन बातों पर ध्यान दें
उदाहरण: अगर आप
किसी टारगेट के लिए डिपेंडेंसी, जिससे मिलने वाले सेट को क्रम में लगाया जाता है
. अगर फ़िल्टर का इस्तेमाल करके
केवल file
प्रकार के लक्ष्य शामिल करें, वही
सकर्मक आंशिक क्रम का संबंध धारण के बीच होता है
नतीजे के सबसेट में टारगेट की जोड़ी - भले ही इनमें से कोई भी न हो
ये पेयर असल ग्राफ़ में सीधे तौर पर जुड़े होते हैं.
(बिल्ड डिपेंडेंसी ग्राफ़ में फ़ाइल-फ़ाइल के किनारे नहीं होते).
हालांकि, सभी ऑपरेटर ऑर्डर को सेव करते हैं, लेकिन कुछ ऑपरेटर जैसी कार्रवाइयां, जैसे कि सेट ऑपरेशन खुद की ऑर्डर करने की किसी सीमा के बारे में पेश न हों. इस एक्सप्रेशन पर गौर करें:
deps(x) union y
फ़ाइनल नतीजे के सेट का क्रम गारंटी के साथ है, जो
इसके सब-एक्सप्रेशन को क्रम में लगाने वाले कंस्ट्रेंट, जैसे कि सभी
x
की ट्रांज़िटिव डिपेंडेंसी
एक-दूसरे का सम्मान करते हैं. हालांकि, क्वेरी इस बात की गारंटी नहीं देती कि
y
में टारगेट का क्रम या
deps(x)
में मौजूद टारगेट का क्रम, जो
y
(उन लक्ष्यों को छोड़कर जो इसमें
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
एक सुविधा है, खासकर उस मामले में जहां
ऐसा न होने पर, --universe_scope
के लिए आपको क्वेरी एक्सप्रेशन को खुद पार्स करना होगा.
इसलिए, ऐसे क्वेरी एक्सप्रेशन के लिए जो यूनिवर्स के स्कोप वाले ऑपरेटर का इस्तेमाल करते हैं, जैसे कि
allrdeps
और
rbuildfiles
का इस्तेमाल ज़रूर करें
--infer_universe_scope
तभी मिलेगा, जब इसका व्यवहार आपकी इच्छा के अनुसार हो.
डिफ़ॉल्ट क्वेरी के मुकाबले, Sky क्वेरी के कुछ फ़ायदे और नुकसान हैं. मुख्य
नुकसान यह है कि यह अपने आउटपुट को ग्राफ़ के क्रम में नहीं लगा पाता. इसलिए, यह तय होता है कि
आउटपुट फ़ॉर्मैट वर्जित हैं. इसकी खासियत है कि यह
दो ऑपरेटर (allrdeps
और
rbuildfiles
) जैसे कि डिफ़ॉल्ट क्वेरी में उपलब्ध नहीं हैं.
साथ ही, Sky Query अपना काम
SkyFrame ग्राफ़ बनाने के बजाय,
ग्राफ़, जो डिफ़ॉल्ट रूप से लागू होता है. इसलिए, कुछ ऐसी स्थितियां हैं जिनमें
यह तेज़ है और कम मेमोरी का इस्तेमाल करता है.
एक्सप्रेशन: व्याकरण के सिंटैक्स और सिमेंटिक्स
यह बेज़ल क्वेरी लैंग्वेज का व्याकरण है, जिसकी जानकारी ईबीएनएफ़ नोटेशन में दी गई है:
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
बेज़ेल क्वेरी लैंग्वेज की मदद से,
वैरिएबल. let
एक्सप्रेशन के आकलन का नतीजा इसके जैसा ही होता है
expr2 में से, सभी मुफ़्त गड़बड़ियों के साथ
वैरिएबल name के मान को इसके मान से बदला गया
expr1.
उदाहरण के लिए, let v = foo/... in allpaths($v, //common) intersect $v
allpaths(foo/...,//common) intersect foo/...
के बराबर है.
के अलावा किसी अन्य वैरिएबल संदर्भ name
की मौजूदगी
पास में let name = ...
एक्सप्रेशन है
गड़बड़ी. दूसरे शब्दों में, टॉप-लेवल के क्वेरी एक्सप्रेशन में फ़्री वैल्यू नहीं हो सकती
वैरिएबल.
ऊपर दिए गए ग्रामर प्रोडक्शन में, name
एक शब्द की तरह होता है, लेकिन
एक अतिरिक्त कंस्ट्रेंट होता है कि यह C प्रोग्रामिंग में एक लीगल आइडेंटिफ़ायर होता है
भाषा. वैरिएबल के रेफ़रंस पहले "$" के साथ जोड़े जाने चाहिए वर्ण.
हर let
एक्सप्रेशन सिर्फ़ एक वैरिएबल के बारे में बताता है, लेकिन उन्हें नेस्ट किया जा सकता है.
टारगेट पैटर्न और वैरिएबल रेफ़रंस, दोनों में ये चीज़ें शामिल होती हैं सिर्फ़ एक टोकन, शब्द हो, जो वाक्य को आसान बना सके. हालांकि, अर्थ संबंधी कोई अस्पष्टता नहीं है, क्योंकि ऐसे शब्दों का सबसेट जो कानूनी परिवर्तनशील होते हैं नाम उन शब्दों के सबसेट से अलग होते हैं जो कानूनी लक्ष्य पैटर्न होते हैं.
तकनीकी तौर पर, let
एक्सप्रेशन नहीं बढ़ते
क्वेरी की भाषा की अभिव्यक्ति: ऐसी कोई भी क्वेरी
उनके बिना भी भाषा को व्यक्त किया जा सकता है. हालांकि,
कई क्वेरी की कम शब्दों में जानकारी दी जाती है. साथ ही, इसकी वजह से ज़्यादा
क्वेरी का बेहतर आकलन किया जा सकता है.
ब्रैकेट वाले एक्सप्रेशन
expr ::= (expr)
ब्रैकेट में, सब-एक्सप्रेशन को जोड़कर आकलन का क्रम तय किया जाता है. ब्रैकेट में रखे गए व्यंजक का आकलन करने से, आर्ग्युमेंट की वैल्यू का पता चलता है.
बीजीय सेट संक्रियाएं: प्रतिच्छेदन, संघ, सेट अंतर
expr ::= expr intersect expr
| expr ^ expr
| expr union expr
| expr + expr
| expr except expr
| expr - expr
ये तीन ऑपरेटर अपने आर्ग्युमेंट पर, आम तौर पर की जाने वाली कार्रवाइयों का हिसाब लगाते हैं.
हर ऑपरेटर के दो फ़ॉर्म होते हैं. एक नॉमिनल फ़ॉर्म होता है, जैसे कि intersect
और a
जैसे कि ^
. दोनों फ़ॉर्म एक जैसे हैं; सांकेतिक रूप ये हैं
तेज़ी से टाइप करता है. (साफ़ तौर पर कहा जाए, तो इस पेज के बाकी हिस्से में नॉमिनल फ़ॉर्म का इस्तेमाल किया गया है.)
उदाहरण के लिए,
foo/... except foo/bar/...
foo/...
से मेल खाने वाले टारगेट के सेट का मूल्यांकन करता है, लेकिन foo/bar/...
से नहीं.
इस तरह की क्वेरी भी लिखी जा सकती है:
foo/... - foo/bar/...
intersect
(^
) और union
(+
) ऑपरेशन क्रम के मुताबिक (सिमेट्रिक) होते हैं;
except
(-
) ऐसिमेट्रिक है. पार्सर सभी तीनों ऑपरेटर के साथ ऐसा व्यवहार करता है
लेफ़्ट-असोसिएट और बराबर प्राथमिकता दी जाती है, इसलिए हो सकता है कि आप ब्रैकेट का इस्तेमाल करना चाहें. इसके लिए
उदाहरण के लिए, इनमें से पहले दो एक्सप्रेशन एक जैसे हैं, लेकिन तीसरा नहीं:
x intersect y union z
(x intersect y) union z
x intersect (y union z)
किसी बाहरी स्रोत से लक्ष्य पढ़ें: सेट करें
expr ::= set(word *)
set(a b c ...)
ऑपरेटर, शून्य या उससे ज़्यादा के सेट के योग की गणना करता है
टारगेट पैटर्न, जिन्हें खाली सफ़ेद जगह से अलग किया गया हो (कॉमा नहीं).
बॉर्न शेल की $(...)
सुविधा के साथ, set()
एक
इसका मतलब है कि एक क्वेरी के नतीजों को सामान्य टेक्स्ट फ़ाइल में सेव किया जा सकता है,
वह टेक्स्ट फ़ाइल दूसरे प्रोग्राम (जैसे मानक UNIX शेल टूल) का इस्तेमाल करके, और फिर
क्वेरी टूल में नतीजे को फिर से, आगे के लिए एक वैल्यू के तौर पर पेश करना
प्रोसेस चल रही है. उदाहरण के लिए:
bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"
अगले उदाहरण में,kind(cc_library, deps(//some_dir/foo:main, 5))
इसकी गणना awk
प्रोग्राम का इस्तेमाल करके, maxrank
वैल्यू को फ़िल्टर करके की जाती है.
bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"
इन उदाहरणों में, $(<foo)
, $(cat foo)
का शॉर्टहैंड है, लेकिन शेल है
cat
के अलावा अन्य निर्देशों का भी इस्तेमाल किया जा सकता है—जैसे कि पिछला awk
निर्देश.
फ़ंक्शन
expr ::= word '(' int | word | expr ... ')'
क्वेरी लैंग्वेज में कई फ़ंक्शन के बारे में जानकारी दी गई है. फ़ंक्शन का नाम यह तय करता है कि इसके लिए कितने और टाइप के आर्ग्युमेंट की ज़रूरत है. नीचे दिए गए फ़ंक्शन उपलब्ध हैं:
allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible
डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: deps
expr ::= deps(expr)
| deps(expr, depth)
deps(x)
ऑपरेटर, बनाए गए ग्राफ़ का आकलन करता है
इसके तर्क सेट की डिपेंडेंसी के ट्रांज़िटिव क्लोज़र से
x. उदाहरण के लिए, deps(//foo)
का मान यह है
डिपेंडेंसी ग्राफ़ सिंगल नोड foo
पर रूट किया गया है. इसमें, इसके सभी
निर्भरता. deps(foo/...)
की वैल्यू, डिपेंडेंसी ग्राफ़ है जिसके रूट में
foo
डायरेक्ट्री के नीचे मौजूद हर पैकेज में मौजूद सभी नियम हैं. इस संदर्भ में,
'डिपेंडेंसी' का मतलब सिर्फ़ नियम और फ़ाइल टारगेट से है, इसलिए BUILD
और
इन टारगेट को बनाने के लिए ज़रूरी Starlark फ़ाइलों को यहां शामिल नहीं किया गया है. इसके लिए
तो आपको buildfiles
ऑपरेटर का इस्तेमाल करना चाहिए.
इससे बनने वाला ग्राफ़, डिपेंडेंसी के हिसाब से क्रम में होता है. ज़्यादा के लिए विवरण के लिए, ग्राफ़ क्रम पर सेक्शन देखें.
deps
ऑपरेटर एक वैकल्पिक दूसरा तर्क स्वीकार करता है, जो एक पूर्णांक होता है
लिटरल वैल्यू, जो खोज की गहराई के लिए ऊपरी सीमा को दिखाता है. तो
deps(foo:*, 0)
, foo
पैकेज के सभी टारगेट दिखाता है, जबकि
deps(foo:*, 1)
ने इसमें किसी भी टारगेट से जुड़ी सीधे तौर पर ज़रूरी शर्तें
foo
पैकेज और deps(foo:*, 2)
में सीधे नोड शामिल होते हैं
deps(foo:*, 1)
में नोड से ऐक्सेस किया जा सकता है और इसी तरह इसी तरह के अन्य एलिमेंट. (ये नंबर
minrank
आउटपुट फ़ॉर्मैट में दिखाई गई रैंक के मुताबिक होता है.)
अगर depth पैरामीटर को छोड़ दिया जाता है, तो खोज
अनबाउंड: यह, ज़रूरी शर्तों के रीफ़्लेक्सिव ट्रांज़िटिव क्लोज़र का पता लगाता है.
रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़र: rdeps
expr ::= rdeps(expr, expr)
| rdeps(expr, expr, depth)
rdeps(u, x)
ऑपरेटर तर्क सेट की रिवर्स डिपेंडेंसी का आकलन करता है
ब्रह्मांड सेट के ट्रांज़िटिव क्लोज़र में x
u.
इससे बनने वाला ग्राफ़, डिपेंडेंसी के हिसाब से क्रम में होता है. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम सेक्शन पर जाएं.
rdeps
ऑपरेटर एक वैकल्पिक तीसरा तर्क स्वीकार करता है, जो एक पूर्णांक होता है
लिटरल वैल्यू, जो खोज की गहराई के लिए ऊपरी सीमा को दिखाता है. नतीजे के तौर पर मिला नतीजा
ग्राफ़ में किसी
नोड पर सेट करें. इसलिए rdeps(//foo, //common, 1)
सभी नोड पर आकलन करता है
जो सीधे //common
पर निर्भर करते हैं, //foo
के अस्थायी बंद में. (ये
संख्याएं minrank
आउटपुट में दिखाई गई रैंक के मुताबिक हैं
format.) अगर depth पैरामीटर को शामिल नहीं किया जाता, तो
खोज की सीमा नहीं है.
सभी रिवर्स डिपेंडेंसी का ट्रांज़िटिव क्लोज़िंग: allrdeps
expr ::= allrdeps(expr)
| allrdeps(expr, depth)
allrdeps
ऑपरेटर, rdeps
की तरह काम करता है
ऑपरेटर, लेकिन "यूनिवर्स सेट" --universe_scope
फ़्लैग क्या है
अलग से तय करने के बजाय, उसका आकलन किया जाएगा. इस तरह, अगर
--universe_scope=//foo/...
को पास किया गया था, फिर allrdeps(//bar)
है
rdeps(//foo/..., //bar)
के बराबर है.
एक ही पैकेज में डायरेक्ट रिवर्स डिपेंडेंसी: समान_pkg_direct_rdeps
expr ::= same_pkg_direct_rdeps(expr)
same_pkg_direct_rdeps(x)
ऑपरेटर, टारगेट के पूरे सेट का आकलन करता है
जो आर्ग्युमेंट सेट में मौजूद टारगेट वाले पैकेज में हों और सीधे इस पर निर्भर हों.
टारगेट के पैकेज से निपटना: सिबलिंग
expr ::= siblings(expr)
siblings(x)
ऑपरेटर, टारगेट के पूरे सेट का आकलन करता है
तर्क सेट में मौजूद टारगेट के जैसा पैकेज हो.
विकल्प: कुछ
expr ::= some(expr)
| some(expr, count )
some(x, k)
ऑपरेटर
अपने विकल्प से स्वेच्छा से ज़्यादा से ज़्यादा k टारगेट चुनता है
तर्क सेट x, और मान, जिसमें शामिल है,
सिर्फ़ उन टारगेट को. पैरामीटर k ज़रूरी नहीं है; अगर
मौजूद नहीं होने पर, नतीजा एक सिंगलटन सेट होगा, जिसमें सिर्फ़ एक टारगेट होगा
अपने-आप चुना गया. अगर आर्ग्युमेंट सेट x का साइज़ यह होता है
k से छोटा है, तो पूरा तर्क सेट
x लौटाए जाएंगे.
उदाहरण के लिए, some(//foo:main union //bar:baz)
एक्सप्रेशन का आकलन करने पर
सिंगलटन सेट में //foo:main
या //bar:baz
शामिल है—हालांकि,
एक परिभाषित नहीं है. एक्सप्रेशन some(//foo:main union //bar:baz, 2)
या
some(//foo:main union //bar:baz, 3)
, //foo:main
और, दोनों नतीजे दिखाता है
//bar:baz
.
अगर आर्ग्युमेंट एक सिंगलटन है, तो some
पहचान फ़ंक्शन की गणना करता है: some(//foo:main)
है
//foo:main
के बराबर है.
अगर बताया गया आर्ग्युमेंट सेट खाली हो, तो यह एक गड़बड़ी होती है, जैसा कि
एक्सप्रेशन some(//foo:main intersect //bar:baz)
.
पाथ ऑपरेटर: somepath, allpaths
expr ::= somepath(expr, expr)
| allpaths(expr, expr)
somepath(S, E)
और
allpaths(S, E)
ऑपरेटर कंप्यूट
पाथ का इस्तेमाल करके तय किया जा सकता है. दोनों क्वेरी में दो तरह की क्वेरी स्वीकार की जाती हैं
आर्ग्युमेंट, शुरुआती पॉइंट का S सेट और एक सेट
आखिरी पॉइंट में से E. somepath
नतीजे के तौर पर
इसमें टारगेट से कुछ आर्बिट्रेरी पाथ पर नोड का ग्राफ़
E के टारगेट के लिए S; allpaths
इसमें किसी भी टारगेट के सभी पाथ के नोड का ग्राफ़ दिखाता है
E में किसी भी टारगेट के लिए S.
इससे बनने वाले ग्राफ़, डिपेंडेंसी के हिसाब से क्रम में लगाए जाते हैं. ज़्यादा जानकारी के लिए, ग्राफ़ का क्रम वाला सेक्शन देखें.
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 सेट का सदस्य है और
लेबल (सटीक रूप में, जैसे कि //foo:bar
)
x में से एक (एंकर नहीं किया गया) मिलान शामिल है
रेगुलर एक्सप्रेशन pattern के लिए. सभी से
लक्ष्य नाम //
से आरंभ होते हैं, इसका एक विकल्प के रूप में उपयोग किया जा सकता है
^
रेगुलर एक्सप्रेशन ऐंकर में.
यह ऑपरेटर अक्सर एक अधिक तेज़ और अधिक मज़बूत विकल्प
intersect
ऑपरेटर. उदाहरण के लिए, सभी को
//foo:foo
टारगेट की bar
डिपेंडेंसी, एक हो सकती है
मूल्यांकन करें
deps(//foo) intersect //bar/...
हालांकि, इस विवरण के लिए इसमें मौजूद सभी BUILD
फ़ाइलों को पार्स करना होगा
bar
पेड़, जो धीमा हो जाएगा और इस प्रक्रिया में गड़बड़ी हो सकती है
ऐसी 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 का सदस्य है और इसमें सभी लक्ष्यों के लिए y है predicate x, y के लिए दृश्यमान है. उदाहरण के लिए:
visible(//foo, //bar:*)
पैकेज //bar
में मौजूद उन सभी टारगेट को चुन लेगा जो //foo
कॉन्टेंट दिखने से जुड़ी पाबंदियों का उल्लंघन किए बिना क्वेरी की जा सकती है.
लेबल टाइप: लेबल के नियम से जुड़ी विशेषताओं का मूल्यांकन
expr ::= labels(word, expr)
labels(attr_name, inputs)
ऑपरेटर
"लेबल" प्रकार की विशेषता attr_name या "लेबल की सूची" इंच
सेट inputs में कुछ नियम हैं.
उदाहरण के लिए, labels(srcs, //foo)
इसकी srcs
विशेषता में दिखने वाले टारगेट
//foo
नियम. अगर एक से ज़्यादा नियम हैं
inputs सेट में srcs
एट्रिब्यूट के साथ
उसके srcs
को वापस लौटा दिया जाता है.
Test_suites को बड़ा और फ़िल्टर करें: टेस्ट
expr ::= tests(expr)
tests(x)
ऑपरेटर, सभी जांच का सेट दिखाता है
सेट x में नियम हैं, तो test_suite
नियम को
अलग-अलग परीक्षणों का सेट जिसे वे रेफ़र करते हैं और
tag
और size
.
डिफ़ॉल्ट रूप से, क्वेरी का आकलन
सभी test_suite
नियमों में गैर-जांच लक्ष्यों को अनदेखा कर देता है. यह काम किया जा सकता है
--strict_test_suite
विकल्प वाली गड़बड़ियों में बदल गई है.
उदाहरण के लिए, kind(test, foo:*)
क्वेरी में सभी
*_test
और test_suite
नियम
foo
पैकेज में. सभी परिणाम (इसके हिसाब से)
परिभाषा) 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
टारगेट के साथ-साथ, उन सभी अन्य 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
से एक ग्राफ़ जनरेट होता है.
कॉन्टेंट, फ़ॉर्मैट, और क्रम तय किया जा सकता है
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
: इन फ़ॉर्मैट का इस्तेमाल करने पर, Baze हमेशा नतीजे प्रिंट करता है
इन्हें डिपेंडेंसी ऑर्डर या रैंक के हिसाब से क्रम में लगाया गया है.
जब यह फ़्लैग deps
होता है, तो बेज़ल नतीजों को कुछ खास क्रम में प्रिंट करता है—यानी,
सबसे पहले इस डिपेंडेंसी का इस्तेमाल करें. हालांकि, वे नोड जो डिपेंडेंसी ऑर्डर के मुताबिक बिना क्रम के होते हैं
(क्योंकि एक से दूसरे तक कोई पाथ नहीं होता) किसी भी क्रम में प्रिंट किया जा सकता है.
जब यह फ़्लैग full
होता है, तो Baज़र, नोड को पूरी तरह से सारणिक (कुल) क्रम में प्रिंट करता है.
सबसे पहले, सभी नोड वर्णमाला के क्रम में लगाए जाते हैं. इसके बाद, सूची के हर नोड का इस्तेमाल
पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट सर्च, जिसमें आउटगोइंग किनारे से लेकर विज़िट नहीं किए गए नोड को ट्रैवर्स किया जाता है
उत्तराधिकारी नोड का वर्णमाला का क्रम. आखिर में, नोड क्रम के उलट प्रिंट होते हैं
जिनमें वे विज़िट किए गए थे.
इस क्रम में नोड प्रिंट करने में ज़्यादा समय लग सकता है. इसलिए, इसका इस्तेमाल सिर्फ़ तब करें, जब डिटरमिनिज़्म अहम है.
टारगेट के सोर्स फ़ॉर्म को उसी तरह प्रिंट करें जैसा वे बिल्ड में दिखेंगे
--output 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 proto
क्वेरी आउटपुट को इस तरह प्रिंट करता है:
QueryResult
प्रोटोकॉल बफ़र.
लंबाई सीमांकित प्रोटोकॉल बफ़र प्रारूप में प्रिंट लक्ष्य
--output streamed_proto
प्रिंट करता है
अवधि सीमांकित
की स्ट्रीम
Target
प्रोटोकॉल बफ़र. यह जानकारी काम की है (i) यात्रा करने के लिए
साइज़ की सीमाएं
तब प्रोटोकॉल बफ़र का इस्तेमाल किया जाता है, जब एक ही जगह में फ़िट करने के लिए बहुत ज़्यादा टारगेट हों
QueryResult
या (ii) तब प्रोसेस करना शुरू करें, जब Baze अब भी आउटपुट दे रहा हो.
टेक्स्ट प्रोटो फ़ॉर्मैट में टारगेट प्रिंट करें
--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
क्वेरी हो, तो रैंक की संख्या
सबसे कम की लंबाई (minrank
के साथ) या सबसे लंबी
x
से इसके नोड तक का (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) क्वेरी आउटपुट का इस्तेमाल करके,
मिलान करता है, जिससे Basel क्वेरी टूल को
डिपेंडेंसी-ग्राफ़-अवेयर "बिल्ड फ़ाइलों के लिए ग्रेप".
जगह की जानकारी, टारगेट के टाइप के हिसाब से अलग-अलग होती है (कइंड ऑपरेटर के बारे में जानें). नियमों के लिए,
BUILD
फ़ाइल में, नियम के एलान की जगह प्रिंट की गई हो.
स्रोत फ़ाइलों के लिए, वास्तविक फ़ाइल की पंक्ति 1 का स्थान है
प्रिंट किया गया. जनरेट की गई फ़ाइल के लिए, नियम की जगह
जनरेट करके, उसे प्रिंट किया जा सकता है. (क्वेरी टूल में ज़रूरी
जनरेट की गई फ़ाइल का वास्तविक स्थान ढूंढने के लिए जानकारी, और
किसी भी मामले में, अगर बिल्ड अभी तक नहीं किया गया है, तो हो सकता है कि यह मौजूद न हो.)
पैकेज के सेट को प्रिंट करें
--output package
इस विकल्प से उन सभी पैकेज के नाम प्रिंट हो जाते हैं जिनमें नतीजे के सेट में कुछ टारगेट से जुड़ा है. नाम लेक्सिकोग्राफ़िक क्रम; डुप्लीकेट शामिल नहीं हैं. औपचारिक तौर पर, लेबल (पैकेज, टारगेट) के सेट से पैकेज.
डेटा स्टोर करने की बाहरी जगहों के पैकेज इस तरह फ़ॉर्मैट किए जाते हैं
@repo//foo/bar
, जबकि डेटा स्टोर करने की मुख्य जगह में मौजूद पैकेज ये हैं
foo/bar
के तौर पर फ़ॉर्मैट किया गया.
deps(...)
क्वेरी के साथ, यह आउटपुट
विकल्प का इस्तेमाल पैकेज के उस सेट को ढूंढने के लिए किया जा सकता है जिसे जांचना ज़रूरी है
ताकि दिए गए टारगेट को बनाया जा सके.
नतीजे का ग्राफ़ दिखाएं
--output graph
इस विकल्प से क्वेरी का नतीजा, निर्देश के तौर पर प्रिंट हो जाता है
ग्राफ़ के रूप में मिलेगा. आम तौर पर
नतीजे को .png
या .svg
जैसी किसी फ़ाइल में सेव किया जाता है.
(अगर dot
प्रोग्राम आपके वर्कस्टेशन पर इंस्टॉल नहीं है, तो
निर्देश sudo apt-get install graphviz
का इस्तेमाल करके इसे इंस्टॉल किया जा सकता है.)
शुरू करने का सैंपल देखने के लिए, नीचे दिया गया उदाहरण सेक्शन देखें.
यह आउटपुट फ़ॉर्मैट खास तौर पर allpaths
,
deps
या rdeps
क्वेरी, जहां नतीजा
इसमें पाथ का सेट शामिल होता है जिसे तब आसानी से विज़ुअलाइज़ नहीं किया जा सकता, जब
लीनियर फ़ॉर्मैट में दिखाया जाना चाहिए, जैसे कि --output label
के साथ.
डिफ़ॉल्ट रूप से, ग्राफ़ फ़ैक्टर के तौर पर दिखाया जाता है. इसका मतलब है कि
टोपोलॉजीली-इक्विलेंट नोड्स को एक साथ मर्ज करके एक सिंगल बनाया जाता है
कई लेबल वाला नोड. इससे ग्राफ़ कॉम्पैक्ट हो जाता है
और आसानी से पढ़ा जा सकता है, क्योंकि आम तौर पर मिलने वाले नतीजों के ग्राफ़ में
दोहराए जाने वाले पैटर्न. उदाहरण के लिए, java_library
नियम
सैकड़ों Java स्रोत फ़ाइलों पर निर्भर कर सकता है, जो सभी
वही genrule
; फ़ैक्टर किए गए ग्राफ़ में, ये सभी फ़ाइलें
एक नोड से दिखाए जाते हैं. यह व्यवहार बंद हो सकता है
--nograph:factored
विकल्प के साथ.
--graph:node_limit n
यह विकल्प,
आउटपुट में ग्राफ़ नोड लंबे लेबल छोटे कर दिए जाएंगे; -1
इससे काट-छांट को बंद किया जाता है. ग्राफ़ के गुणनखंडों के रूप में होने के कारण
आम तौर पर प्रिंट किया जाता है, तो नोड लेबल बहुत लंबे हो सकते हैं. ग्राफ़विज़ यह नहीं कर सकता
हैंडल में 1,024 से ज़्यादा वर्ण के लेबल शामिल किए गए हैं, जो कि डिफ़ॉल्ट वैल्यू है
इस विकल्प को चुनें. इस विकल्प का तब तक कोई असर नहीं पड़ता, जब तक कि
--output=graph
का इस्तेमाल किया जा रहा है.
--[no]graph:factored
डिफ़ॉल्ट रूप से, ग्राफ़ के रूप में गुणक दिखाए जाते हैं, जैसा कि बताया गया है
ऊपर दिए गए हैं.
जब --nograph:factored
तय किया जाता है, तो ग्राफ़
फ़ैक्टरिंग के बिना प्रिंट किया जा सकता है. इससे ग्राफ़विज़ का इस्तेमाल करके विज़ुअलाइज़ेशन होता है
अव्यावहारिक है, लेकिन सरल प्रारूप वाला अन्य विज्ञापन
टूल (जैसे कि gRep). इस विकल्प से कोई असर नहीं पड़ता
जब तक --output=graph
का इस्तेमाल न किया जा रहा हो.
XML
--output xml
इस विकल्प से बनने वाले टारगेट, एक्सएमएल में प्रिंट हो जाते हैं फ़ॉर्म में. आउटपुट इस तरह के एक्सएमएल हेडर से शुरू होता है
<?xml version="1.0" encoding="UTF-8"?>
<query version="2">
और इसके बाद हर टारगेट के लिए एक्सएमएल एलिमेंट के साथ जारी रहता है नतीजे के ग्राफ़ में, स्थानिक क्रम में (जब तक कि बिना क्रम वाले नतीजों के लिए अनुरोध किया जाता है), और फिर अंत
</query>
file
तरह के टारगेट के लिए आसान एंट्री दी गई हैं:
<source-file name='//foo:foo_main.cc' .../>
<generated-file name='//foo:libfoo.so' .../>
हालांकि, नियमों के लिए एक्सएमएल स्ट्रक्चर्ड है और इसमें सभी
नियम की विशेषताएं, जिनमें वे एट्रिब्यूट शामिल हैं जिनका मान
BUILD
फ़ाइल में साफ़ तौर पर बताया गया है.
इसके अलावा, नतीजे में rule-input
और
rule-output
एलिमेंट जोड़कर, ताकि
डिपेंडेंसी ग्राफ़ को फिर से बनाया जा सकता है. इसके लिए हमें यह पता न होना चाहिए कि
उदाहरण के लिए, srcs
एट्रिब्यूट के एलिमेंट
फ़ॉरवर्ड की जाने वाली चीज़ें (ज़रूरी शर्तें) और
outs
एट्रिब्यूट पुराने डिपेंडेंसी (उपभोक्ता) हैं.
इंप्लिसिट डिपेंडेंसी के लिए rule-input
एलिमेंट को दबाया जाता है, अगर
--noimplicit_deps
दर्ज है.
<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
.
डेटा स्टोर करने की बाहरी जगहों से क्वेरी करना
अगर बिल्ड बाहरी डेटा स्टोर करने की जगहों के नियमों पर निर्भर करता है (जो
SPACE फ़ाइल) में एक्सपोर्ट करती है, तो क्वेरी के नतीजों में ये डिपेंडेंसी शामिल होंगी. इसके लिए
उदाहरण के लिए, अगर //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