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

यह पेज इस्तेमाल की गई बेज़ल क्वेरी लैंग्वेज के लिए रेफ़रंस मैन्युअल है जबकि बिल्ड डिपेंडेंसी का विश्लेषण करने के लिए 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. कीवर्ड इनमें से हर भाषा के बारे में नीचे बताया गया है. पूरा सेट कीवर्ड का है:

  • except

  • in

  • intersect

  • let

  • set

  • union

• शब्द, जैसे कि "foo/..." या ".*test rule" या "//bar/baz:all" का इस्तेमाल करें. अगर कोई वर्ण का क्रम "कोट" है (एकल कोट से शुरू और खत्म होता है ' या डबल-कोट ") से शुरू और खत्म होता है. यह एक शब्द है. अगर कोई वर्ण क्रम को कोट नहीं किया गया है, इसे अब भी शब्द के रूप में पार्स किया जा सकता है. बिना कोट वाले शब्द, क्रम होते हैं अक्षर A-Za-z से लिए गए वर्ण यानी 0 से 9 तक के अंक और खास वर्ण */@.-_:$~[] (तारे का निशान, फ़ॉरवर्ड स्लैश, ऐट, पीरियड, हाइफ़न, अंडरस्कोर, कोलन, डॉलर का निशान, टिल्ड, लेफ़्ट स्क्वेयर ब्रेस, राइट स्क्वेयर ब्रेस) जोड़ें. हालांकि, जिन शब्दों को कोट नहीं किया गया है वे हाइफ़न - या तारे के निशान * से शुरू नहीं हो सकते भले ही रिलेटिव [टारगेट के नाम][(/Concepts/labels#target-names) शुरू हो जाए कुछ करने के लिए प्रेरित किया जा सकता है.

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

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

   //foo:bar+wiz    # WRONG: scanned as //foo:bar + wiz.
   //foo:bar=wiz    # WRONG: scanned as //foo:bar = wiz.
   "//foo:bar+wiz"  # OK.
   "//foo:bar=wiz"  # OK.
  

  ध्यान दें कि यह कोट, ऐसे कोट के अलावा है जिसकी ज़रूरत पड़ सकती है खोल सकते हैं, जैसे:

  bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
  

  अगर कीवर्ड कोट किए जाते हैं, तो उन्हें सामान्य शब्द माना जाता है. उदाहरण के लिए, some कीवर्ड लेकिन "कुछ" एक शब्द है. 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 एक्सप्रेशन के आकलन का नतीजा इसके जैसा ही होता है expr₂ में से, सभी मुफ़्त गड़बड़ियों के साथ वैरिएबल name के मान को इसके मान से बदला गया expr₁.

उदाहरण के लिए, 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.

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

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

expr ::= kind(word, expr)

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

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

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

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

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

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

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

expr ::= filter(word, expr)

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

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

rbuildfiles ऑपरेटर का स्कोप वह यूनिवर्स है जिसे --universe_scope फ़्लैग. ऐसी फ़ाइलें जो सीधे तौर पर BUILD फ़ाइलों और .bzl से जुड़ी नहीं हैं इन फ़ाइलों से नतीजों पर कोई असर नहीं पड़ता. उदाहरण के लिए, सोर्स फ़ाइलों (जैसे कि foo.cc) को अनदेखा किया जाता है, भले ही, उनकी जानकारी BUILD फ़ाइल में साफ़ तौर पर दी गई हो. हालांकि, सिमलिंक का सम्मान किया जाता है, ताकि अगर foo/BUILD, bar/BUILD का सिमलिंक है, तो rbuildfiles(bar/BUILD) के नतीजों में //foo:BUILD शामिल होगा.

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

पैकेज के बारे में बताने वाली फ़ाइलें: लोड फ़ाइलें

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 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