इस पेज का अनुवाद Cloud Translation API से किया गया है.

फ़ंक्शन

विषय सूची

पैकेज
package_group
exports_files
ग्लोब
चुनें
सबपैकेज

पैकेज

package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)

यह फ़ंक्शन, पैकेज में मौजूद हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताता है. इसका इस्तेमाल किसी पैकेज (BUILD फ़ाइल) में ज़्यादा से ज़्यादा एक बार किया जाता है.

पूरे डेटा स्टोर करने की जगह में हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताने वाले वाले रेपो के रूट में मौजूद, REPO.bazel फ़ाइल में repo() फ़ंक्शन का इस्तेमाल करें. repo() फ़ंक्शन बिलकुल वही तर्क लेता है जो package() लेता है.

किसी भी नियम से पहले, फ़ाइल के सबसे ऊपर मौजूद सभी load() स्टेटमेंट के ठीक बाद Package() फ़ंक्शन को कॉल किया जाना चाहिए.

तर्क

एट्रिब्यूट	ब्यौरा
`default_applicable_licenses`	`default_package_metadata` के लिए उपनाम.
`default_visibility`	लेबल की सूची; `[]` डिफ़ॉल्ट है इस पैकेज के नियमों को डिफ़ॉल्ट रूप से 'किसको दिखे' सेटिंग. इस पैकेज में हर नियम के लिए, इस एट्रिब्यूट में 'किसको दिखे' सेटिंग तय की गई है. हालांकि, नियम के `visibility` एट्रिब्यूट में कुछ और न बताया गया हो. इस एट्रिब्यूट के सिंटैक्स के बारे में ज़्यादा जानकारी के लिए, किसको दिखे से जुड़ा दस्तावेज़ देखें. पैकेज की डिफ़ॉल्ट 'किसको दिखे' सेटिंग, exports_files पर लागू नहीं होती, जो डिफ़ॉल्ट रूप से सार्वजनिक होती है.
`default_deprecation`	स्ट्रिंग; `""` डिफ़ॉल्ट तौर पर सेट है इस पैकेज के सभी नियमों के लिए, डिफ़ॉल्ट `deprecation` मैसेज सेट करता है.
`default_package_metadata`	लेबल की सूची; `[]` डिफ़ॉल्ट है मेटाडेटा टारगेट की एक डिफ़ॉल्ट सूची सेट करता है, जो पैकेज में मौजूद दूसरे सभी टारगेट पर लागू होती है. आम तौर पर, ये टारगेट ओएसएस पैकेज और लाइसेंस के एलानों से जुड़े होते हैं. उदाहरण के लिए, rules_license देखें.
`default_testonly`	बूलियन; डिफ़ॉल्ट रूप से `False` पर सेट है. हालांकि, इसके बारे में बताया गया है इस पैकेज में मौजूद सभी नियमों के लिए, डिफ़ॉल्ट `testonly` प्रॉपर्टी सेट करता है. `javatests` से कम कीमत वाले पैकेज में, डिफ़ॉल्ट वैल्यू `True` है.
`features`	सूची स्ट्रिंग; `[]` डिफ़ॉल्ट है इस BUILD फ़ाइल के सिमैंटिक पर असर डालने वाले अलग-अलग फ़्लैग सेट करता है. इस सुविधा का इस्तेमाल, मुख्य रूप से बिल्ड सिस्टम पर काम करने वाले लोग करते हैं. इससे वे ऐसे पैकेज टैग कर पाते हैं जिन्हें खास तरह से हैंडल करने की ज़रूरत होती है. इसका इस्तेमाल तब तक न करें, जब तक कि बिल्ड सिस्टम पर काम करने वाले किसी व्यक्ति ने इसके लिए साफ़ तौर पर अनुरोध न किया हो.

उदाहरण

नीचे दिए गए एलान में बताया गया है कि इस पैकेज के नियम सिर्फ़ //foo:target पैकेज ग्रुप के सदस्यों को दिखते हैं. किसी नियम के लिए व्यक्तिगत तौर पर दिखने की जानकारी अगर मौजूद हो, तो इस स्पेसिफ़िकेशन को ओवरराइड करें.

package(default_visibility = ["//foo:target"])

package_group

package_group(name, packages, includes)

यह फ़ंक्शन पैकेज के सेट के बारे में बताता है और उस सेट के साथ एक लेबल जोड़ता है. इस लेबल का रेफ़रंस visibility एट्रिब्यूट में दिया जा सकता है.

पैकेज ग्रुप का इस्तेमाल मुख्य रूप से 'किसको दिखे' सेटिंग कंट्रोल करने के लिए किया जाता है. सार्वजनिक तौर पर दिखने वाले टारगेट का रेफ़रंस सोर्स ट्री में मौजूद हर पैकेज से लिया जा सकता है. निजी तौर पर दिखने वाले टारगेट का रेफ़रंस सिर्फ़ उसके पैकेज में ही दिया जा सकता है (सबपैकेज नहीं). इन सीमाओं के बीच में, कोई टारगेट अपने खुद के पैकेज के साथ ही एक या उससे ज़्यादा पैकेज ग्रुप में बताए गए किसी भी पैकेज को ऐक्सेस करने की अनुमति दे सकता है. 'किसको दिखे' सेटिंग के बारे में ज़्यादा जानकारी के लिए, किसको दिखे एट्रिब्यूट देखें.

किसी पैकेज को ग्रुप में तब शामिल माना जाता है, जब वह पैकेज packages एट्रिब्यूट से मेल खाता हो या includes एट्रिब्यूट में बताए गए किसी दूसरे पैकेज ग्रुप में पहले से मौजूद हो.

पैकेज ग्रुप, तकनीकी रूप से टारगेट किए जाते हैं, लेकिन इन्हें नियमों के हिसाब से नहीं बनाया जाता. साथ ही, उनके पास 'किसको दिखे' सेटिंग नहीं होती.

तर्क

एट्रिब्यूट ब्यौरा

एट्रिब्यूट	ब्यौरा
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`packages`	स्ट्रिंग की सूची; `[]` डिफ़ॉल्ट तौर पर सेट है इस सूची में, पैकेज की सुविधाओं की शून्य या इससे ज़्यादा जानकारी शामिल है. हर पैकेज स्पेसिफ़िकेशन स्ट्रिंग में इनमें से कोई एक फ़ॉर्म हो सकता है: पैकेज का पूरा नाम, जिसमें डेटा स्टोर करने की जगह के बिना, डबल स्लैश से शुरू होता है. उदाहरण के लिए, `//foo/bar` उस पैकेज के बारे में बताता है जिसमें इस नाम का इस्तेमाल होता है. साथ ही, यह पैकेज उसी रिपॉज़िटरी में मौजूद होता है जिसमें पैकेज ग्रुप होता है. जैसा कि ऊपर बताया गया है, लेकिन `/...` के पीछे. उदाहरण के लिए, `//foo/...`, `//foo` और इसके सभी सबपैकेज के सेट के बारे में बताता है. `//...`, डेटा स्टोर करने की मौजूदा जगह में सभी पैकेज के बारे में बताता है. `public` या `private` स्ट्रिंग, जिनमें हर पैकेज या कोई पैकेज नहीं के बारे में जानकारी दी जाती है. (इस फ़ॉर्म के लिए, `--incompatible_package_group_has_public_syntax` फ़्लैग को सेट करना ज़रूरी है.) इसके अलावा, पैकेज की पहली दो तरह की खास बातों के आगे `-` भी जोड़ा जा सकता है, ताकि यह बताया जा सके कि वे नेगेटिव हैं. पैकेज ग्रुप में कोई भी ऐसा पैकेज होता है जो कम से कम एक पॉज़िटिव स्पेसिफ़िकेशन से मेल खाता है. साथ ही, इसमें किसी भी तरह की नेगेटिव खासियत शामिल नहीं होती है. उदाहरण के लिए, `[//foo/..., -//foo/tests/...]` वैल्यू में `//foo` के वे सभी सबपैकेज शामिल हैं जो `//foo/tests` के सबपैकेज नहीं हैं. (`//foo` खुद शामिल है, जबकि //foo/tests खुद नहीं है.) सार्वजनिक तौर पर दिखने वाले डेटा के अलावा, कोई ऐसा तरीका नहीं है जिससे पैकेज को मौजूदा डेटा स्टोर करने की जगह के बाहर सीधे तौर पर तय किया जा सके. अगर यह एट्रिब्यूट मौजूद नहीं है, तो इसे खाली सूची पर सेट करने का ही तरीका है. यह एट्रिब्यूट को सिर्फ़ `private` वाली सूची में सेट करने जैसा ही है. ध्यान दें: Bazel 6.0 से पहले, `//...` की सुविधा का लेगसी व्यवहार `public` जैसा था. यह तरीका `--incompatible_fix_package_group_reporoot_syntax` के चालू होने पर ठीक किया जाता है, जो Bazel 6.0 के बाद डिफ़ॉल्ट रूप से सेट होता है. ध्यान दें: Bazel 6.0 से पहले, जब इस एट्रिब्यूट को `bazel query --output=proto` (या `--output=xml`) के हिस्से के रूप में सीरियल के तौर पर सेट किया जाता है, तो शुरुआत में मौजूद स्लैश हटा दिए जाते हैं. उदाहरण के लिए, `//pkg/foo/...` का आउटपुट `\"pkg/foo/...\"` के तौर पर दिखेगा. यह तरीका `--incompatible_package_group_includes_double_slash` के चालू होने पर ठीक होता है, जो Bazel 6.0 के बाद डिफ़ॉल्ट रूप से सेट होता है.
`includes`	लेबल की सूची; `[]` डिफ़ॉल्ट है इसमें शामिल अन्य पैकेज ग्रुप. इस एट्रिब्यूट में मौजूद लेबल, पैकेज के दूसरे ग्रुप से जुड़े होने चाहिए. रेफ़रंस वाले पैकेज ग्रुप में मौजूद पैकेज को इस पैकेज ग्रुप में शामिल किया जाता है. यह ट्रांज़िटिव है — अगर पैकेज ग्रुप `a` में पैकेज ग्रुप `b` और `b` में पैकेज ग्रुप `c` शामिल है, तो `c` में मौजूद हर पैकेज भी `a` में शामिल होगा. जब पैकेज के स्पेसिफ़िकेशन के साथ इसका इस्तेमाल किया जाता है, तो ध्यान रखें कि हर ग्रुप के लिए पैकेज के सेट की गिनती पहले अलग-अलग की जाती है और फिर नतीजों को एक साथ मिला दिया जाता है. इसका मतलब है कि एक ग्रुप में शामिल नहीं की गई खास जानकारी का दूसरे ग्रुप में मौजूद खास जानकारी पर कोई असर नहीं पड़ता.

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

packages

स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है

इस सूची में, पैकेज की सुविधाओं की शून्य या इससे ज़्यादा जानकारी शामिल है.

हर पैकेज स्पेसिफ़िकेशन स्ट्रिंग में इनमें से कोई एक फ़ॉर्म हो सकता है:

पैकेज का पूरा नाम, जिसमें डेटा स्टोर करने की जगह के बिना, डबल स्लैश से शुरू होता है. उदाहरण के लिए, //foo/bar उस पैकेज के बारे में बताता है जिसमें इस नाम का इस्तेमाल होता है. साथ ही, यह पैकेज उसी रिपॉज़िटरी में मौजूद होता है जिसमें पैकेज ग्रुप होता है.
जैसा कि ऊपर बताया गया है, लेकिन /... के पीछे. उदाहरण के लिए, //foo/..., //foo और इसके सभी सबपैकेज के सेट के बारे में बताता है. //..., डेटा स्टोर करने की मौजूदा जगह में सभी पैकेज के बारे में बताता है.
public या private स्ट्रिंग, जिनमें हर पैकेज या कोई पैकेज नहीं के बारे में जानकारी दी जाती है. (इस फ़ॉर्म के लिए, --incompatible_package_group_has_public_syntax फ़्लैग को सेट करना ज़रूरी है.)

इसके अलावा, पैकेज की पहली दो तरह की खास बातों के आगे - भी जोड़ा जा सकता है, ताकि यह बताया जा सके कि वे नेगेटिव हैं.

पैकेज ग्रुप में कोई भी ऐसा पैकेज होता है जो कम से कम एक पॉज़िटिव स्पेसिफ़िकेशन से मेल खाता है. साथ ही, इसमें किसी भी तरह की नेगेटिव खासियत शामिल नहीं होती है. उदाहरण के लिए, [//foo/..., -//foo/tests/...] वैल्यू में //foo के वे सभी सबपैकेज शामिल हैं जो //foo/tests के सबपैकेज नहीं हैं. (//foo खुद शामिल है, जबकि //foo/tests खुद नहीं है.)

सार्वजनिक तौर पर दिखने वाले डेटा के अलावा, कोई ऐसा तरीका नहीं है जिससे पैकेज को मौजूदा डेटा स्टोर करने की जगह के बाहर सीधे तौर पर तय किया जा सके.

अगर यह एट्रिब्यूट मौजूद नहीं है, तो इसे खाली सूची पर सेट करने का ही तरीका है. यह एट्रिब्यूट को सिर्फ़ private वाली सूची में सेट करने जैसा ही है.

ध्यान दें: Bazel 6.0 से पहले, //... की सुविधा का लेगसी व्यवहार public जैसा था. यह तरीका --incompatible_fix_package_group_reporoot_syntax के चालू होने पर ठीक किया जाता है, जो Bazel 6.0 के बाद डिफ़ॉल्ट रूप से सेट होता है.

ध्यान दें: Bazel 6.0 से पहले, जब इस एट्रिब्यूट को bazel query --output=proto (या --output=xml) के हिस्से के रूप में सीरियल के तौर पर सेट किया जाता है, तो शुरुआत में मौजूद स्लैश हटा दिए जाते हैं. उदाहरण के लिए, //pkg/foo/... का आउटपुट \"pkg/foo/...\" के तौर पर दिखेगा. यह तरीका --incompatible_package_group_includes_double_slash के चालू होने पर ठीक होता है, जो Bazel 6.0 के बाद डिफ़ॉल्ट रूप से सेट होता है.

includes

लेबल की सूची; [] डिफ़ॉल्ट है

इसमें शामिल अन्य पैकेज ग्रुप.

इस एट्रिब्यूट में मौजूद लेबल, पैकेज के दूसरे ग्रुप से जुड़े होने चाहिए. रेफ़रंस वाले पैकेज ग्रुप में मौजूद पैकेज को इस पैकेज ग्रुप में शामिल किया जाता है. यह ट्रांज़िटिव है — अगर पैकेज ग्रुप a में पैकेज ग्रुप b और b में पैकेज ग्रुप c शामिल है, तो c में मौजूद हर पैकेज भी a में शामिल होगा.

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

उदाहरण

package_group के इस एलान में, "ट्रॉपिकल" नाम के एक पैकेज ग्रुप के बारे में बताया गया है, जिसमें ट्रॉपिकल फल शामिल हैं.

package_group(
    name = "tropical",
    packages = [
        "//fruits/mango",
        "//fruits/orange",
        "//fruits/papaya/...",
    ],
)

इन एलानों में, काल्पनिक ऐप्लिकेशन के पैकेज ग्रुप के बारे में बताया गया है:

package_group(
    name = "fooapp",
    includes = [
        ":controller",
        ":model",
        ":view",
    ],
)

package_group(
    name = "model",
    packages = ["//fooapp/database"],
)

package_group(
    name = "view",
    packages = [
        "//fooapp/swingui",
        "//fooapp/webui",
    ],
)

package_group(
    name = "controller",
    packages = ["//fooapp/algorithm"],
)

exports_files

exports_files([label, ...], visibility, licenses)

exports_files() इस पैकेज से जुड़ी उन फ़ाइलों की सूची के बारे में बताता है जिन्हें दूसरे पैकेज में एक्सपोर्ट किया जाता है.

किसी पैकेज के लिए BUILD फ़ाइल सीधे तौर पर दूसरे पैकेज से जुड़ी सोर्स फ़ाइलों का हवाला दे सकती है, बशर्ते उन्हें exports_files() स्टेटमेंट के साथ साफ़ तौर पर एक्सपोर्ट किया गया हो. फ़ाइलों की जानकारी दिखने के बारे में और पढ़ें.

लेगसी व्यवहार के तौर पर, नियम के इनपुट के तौर पर बताई गई फ़ाइलों को भी डिफ़ॉल्ट 'किसको दिखे' सेटिंग के साथ एक्सपोर्ट किया जाता है. ऐसा तब तक होता है, जब तक फ़्लैग --incompatible_no_implicit_file_export फ़्लिप नहीं किया जाता. हालांकि, इस व्यवहार पर भरोसा नहीं किया जाना चाहिए और इसे ऐक्टिव तौर पर माइग्रेट नहीं किया जाना चाहिए.

तर्क

तर्क, मौजूदा पैकेज में मौजूद फ़ाइलों के नाम की सूची होती है. यह भी बताया जा सकता है कि 'डिवाइस किसे दिखे' सेटिंग. इस मामले में, तय किए गए टारगेट के लिए फ़ाइलें दिखेंगी. अगर कोई 'किसको दिखे' सेटिंग तय नहीं की गई है, तो फ़ाइलें हर पैकेज पर दिखेंगी. भले ही, package फ़ंक्शन में पैकेज के दिखने की डिफ़ॉल्ट सेटिंग तय की गई हो. लाइसेंस भी तय किए जा सकते हैं.

उदाहरण

इस उदाहरण में, test_data पैकेज की एक टेक्स्ट फ़ाइल golden.txt को एक्सपोर्ट किया जाता है, ताकि दूसरे पैकेज इसका इस्तेमाल कर सकें. उदाहरण के लिए, जांच के data एट्रिब्यूट में.

# from //test_data/BUILD

exports_files(["golden.txt"])

ग्लोब

glob(include, exclude=[], exclude_directories=1, allow_empty=True)

ग्लोब एक हेल्पर फ़ंक्शन है, जो कुछ खास पाथ पैटर्न से मैच करने वाली सभी फ़ाइलों को खोजता है. साथ ही, उनके पाथ की नई, बदली जा सकने वाली, क्रम से लगाई गई सूची दिखाता है. Glob सिर्फ़ अपने पैकेज में मौजूद फ़ाइलें खोजता है और सिर्फ़ सोर्स फ़ाइलों (जनरेट की गई फ़ाइलों या अन्य टारगेट को नहीं) खोजता.

अगर फ़ाइल का पैकेज-रिलेटिव पाथ किसी भी include पैटर्न से मैच करता है और exclude पैटर्न से मेल नहीं खाता, तो सोर्स फ़ाइल का लेबल, नतीजे में शामिल किया जाता है.

include और exclude सूचियों में ऐसे पाथ पैटर्न शामिल होते हैं जो मौजूदा पैकेज से जुड़े होते हैं. हर पैटर्न में एक या ज़्यादा पाथ सेगमेंट हो सकते हैं. हमेशा की तरह, यूनिक्स पाथ के साथ, इन सेगमेंट को / से अलग किया जाता है. सेगमेंट में * वाइल्डकार्ड हो सकता है: यह पाथ सेगमेंट की किसी भी सबस्ट्रिंग से मेल खाता है (यहां तक कि खाली सबस्ट्रिंग भी), जिसमें डायरेक्ट्री सेपरेटर / शामिल नहीं है. इस वाइल्डकार्ड का इस्तेमाल, एक पाथ सेगमेंट में कई बार किया जा सकता है. इसके अलावा, ** वाइल्डकार्ड, शून्य या उससे ज़्यादा पाथ सेगमेंट से मैच कर सकता है. हालांकि, इसे एक स्टैंडअलोन पाथ सेगमेंट के तौर पर तय करना ज़रूरी है.

उदाहरण:

foo/bar.txt इस पैकेज में मौजूद foo/bar.txt फ़ाइल से पूरी तरह मेल खाता है
अगर फ़ाइल .txt पर खत्म होती है, तो foo/*.txt, foo/ डायरेक्ट्री में मौजूद हर फ़ाइल से मेल खाता है (जब तक कि foo/ एक सबपैकेज न हो)
foo/a*.htm*, foo/ डायरेक्ट्री में मौजूद हर उस फ़ाइल से मेल खाता है जो a से शुरू होती है. इसके बाद, इसमें आर्बिट्ररी स्ट्रिंग (यह खाली हो सकती है), फिर .htm होती है और किसी अन्य आर्बिट्रेरी स्ट्रिंग पर खत्म होती है; जैसे, foo/axx.htm और foo/a.html या foo/axxx.html
**/a.txt इस पैकेज की हर सबडायरेक्ट्री की हर a.txt फ़ाइल से मेल खाता है
अगर नतीजे देने वाले पाथ पर मौजूद कम से कम एक डायरेक्ट्री को bar कहा जाता है, तो **/bar/**/*.txt इस पैकेज की हर सबडायरेक्ट्री में मौजूद .txt फ़ाइल से मेल खाता है. उदाहरण के लिए, xxx/bar/yyy/zzz/a.txt या bar/a.txt (ध्यान रखें कि ** भी किसी सेगमेंट से मेल नहीं खाता) या bar/zzz/a.txt
** इस पैकेज की हर सबडायरेक्ट्री की हर फ़ाइल से मेल खाता है
foo**/a.txt एक अमान्य पैटर्न है, क्योंकि ** को एक सेगमेंट के रूप में, अपने-आप में दिखना चाहिए

अगर exclude_directories आर्ग्युमेंट चालू है (1 पर सेट है), तो इस टाइप की डायरेक्ट्री की फ़ाइलें, खोज के नतीजों (डिफ़ॉल्ट तौर पर 1) में शामिल नहीं होंगी.

अगर allow_empty आर्ग्युमेंट False पर सेट है, तो glob फ़ंक्शन से गड़बड़ी हो जाएगी. ऐसा तब होगा, जब नतीजा खाली सूची होगा.

इसकी कई अहम सीमाएं और सावधानियां हैं:

glob(), BUILD फ़ाइल के आकलन के दौरान चलता है. इसलिए, glob() सिर्फ़ आपके सोर्स ट्री की फ़ाइलों से मैच करता है, कभी जनरेट नहीं की गई फ़ाइलों से. अगर आपको एक ऐसा टारगेट बनाना है जिसके लिए सोर्स और जनरेट की गई, दोनों फ़ाइलें ज़रूरी हों, तो आपको जनरेट की गई फ़ाइलों की एक खास सूची को ग्लोब में जोड़ना होगा. :mylib और :gen_java_srcs के साथ यह उदाहरण देखें.
अगर किसी नियम का नाम मेल खाने वाली सोर्स फ़ाइल जैसा ही है, तो वह नियम फ़ाइल को "शैडो" कर देगा.

इसे समझने के लिए, याद रखें कि glob(), पाथ की सूची दिखाता है. इसलिए, दूसरे नियमों के एट्रिब्यूट (जैसे, srcs = glob(["*.cc"])) में glob() का इस्तेमाल करने का असर, मेल खाने वाले पाथ को साफ़ तौर पर सूची में डालने जैसा ही होता है. उदाहरण के लिए, अगर glob() ["Foo.java", "bar/Baz.java"] देता है, लेकिन "Foo.java" नाम के पैकेज में एक नियम भी है (जिसकी अनुमति है, हालांकि Bazel इसके बारे में चेतावनी देता है), तो glob() का उपभोक्ता "Foo.java" फ़ाइल के बजाय "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub की समस्या #10395 देखें.
ग्लोब, सबडायरेक्ट्री में मौजूद फ़ाइलों से मेल खा सकते हैं. साथ ही, सबडायरेक्ट्री के नाम वाइल्डकार्ड हो सकते हैं. हालांकि...
लेबल को पैकेज की सीमा पार करने की अनुमति नहीं है और ग्लोब का मिलान सबपैकेज में मौजूद फ़ाइलों से नहीं होता है.

उदाहरण के लिए, अगर x/y पैकेज के तौर पर मौजूद है (या तो x/y/BUILD के तौर पर या पैकेज पाथ पर किसी और जगह पर), तो पैकेज x में ग्लोब एक्सप्रेशन **/*.cc में x/y/z.cc शामिल नहीं है. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा, BUILD फ़ाइलों की मौजूदगी पर निर्भर करता है. इसका मतलब है कि अगर x/y नाम का कोई पैकेज नहीं होता, तो उसी ग्लोब एक्सप्रेशन में x/y/z.cc शामिल होता. इसके अलावा, --deleted_packages फ़्लैग का इस्तेमाल करके, उस ग्लोब एक्सप्रेशन को 'मिटाया गया' के तौर पर मार्क किया जाता है.
ऊपर बताई गई पाबंदी सभी ग्लोब एक्सप्रेशन पर लागू होती है. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस वाइल्डकार्ड का इस्तेमाल करते हैं.
. से शुरू होने वाली फ़ाइल के नाम वाली छिपी हुई फ़ाइल को ** और * वाइल्डकार्ड, दोनों से पूरी तरह मैच किया जाता है. अगर आपको किसी छिपी हुई फ़ाइल को कंपाउंड पैटर्न से मैच करना है, तो पैटर्न . से शुरू होना चाहिए. उदाहरण के लिए, * और .*.txt, .foo.txt से मेल खाएंगे, लेकिन *.txt नहीं. छिपी हुई डायरेक्ट्री का मिलान भी इसी तरह किया जाता है. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें शामिल हो सकती हैं जो इनपुट के तौर पर ज़रूरी नहीं होती हैं. इनकी वजह से, ग़ैर-ज़रूरी ग्लोब वाली फ़ाइलों और मेमोरी के इस्तेमाल की संख्या बढ़ सकती है. छिपी हुई डायरेक्ट्री को बाहर रखने के लिए, उन्हें "बाहर रखें" वाली सूची में शामिल तर्क में जोड़ें.
"**" वाइल्डकार्ड में एक कोने वाला केस है: "**" पैटर्न, पैकेज के डायरेक्ट्री पाथ से मेल नहीं खाता. इसका मतलब है कि glob(["**"], exclude_directories = 0), मौजूदा पैकेज की डायरेक्ट्री में मौजूद सभी फ़ाइलों और डायरेक्ट्री से पूरी तरह से मैच करता है. हालांकि, वे सब-पैकेज की डायरेक्ट्री में नहीं डाले जा सकते. इसके बारे में पिछला नोट देखें.

आम तौर पर, आपको ग्लोब पैटर्न के लिए सिर्फ़ '*' इस्तेमाल करने के बजाय, एक सही एक्सटेंशन (जैसे कि *.html) देने की कोशिश करनी चाहिए. नाम को बेहतर तरीके से समझाने के लिए, उसमें मौजूद जानकारी को खुद दस्तावेज़ में सेव करना होता है. इससे यह भी पक्का होता है कि कोई गलती से बैकअप फ़ाइलों या emacs/vi/... फ़ाइलों को अपने-आप सेव न करे.

बिल्ड के नियम बनाते समय, ग्लोब के एलिमेंट की गिनती की जा सकती है. उदाहरण के लिए, इससे हर इनपुट के लिए अलग-अलग नियम जनरेट करने में मदद मिलती है. नीचे बड़े किए गए ग्लोब का उदाहरण सेक्शन देखें.

ग्लोब के उदाहरण

इस डायरेक्ट्री की सभी java फ़ाइलों और :gen_java_srcs नियम से जनरेट की गई सभी फ़ाइलों से बनी Java लाइब्रेरी बनाएं.

java_library(
    name = "mylib",
    srcs = glob(["*.java"]) + [":gen_java_srcs"],
    deps = "...",
)

genrule(
    name = "gen_java_srcs",
    outs = [
        "Foo.java",
        "Bar.java",
    ],
    ...
)

प्रयोग वाली.txt फ़ाइल के अलावा, डायरेक्ट्री टेस्ट डेटा में सभी टेक्स्ट फ़ाइलें शामिल करें. ध्यान दें कि टेस्टडेटा की सबडायरेक्ट्री में मौजूद फ़ाइलों को शामिल नहीं किया जाएगा. अगर आपको उन फ़ाइलों को शामिल करना है, तो रिकर्सिव ग्लोब (**) का इस्तेमाल करें.

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(
        ["testdata/*.txt"],
        exclude = ["testdata/experimental.txt"],
    ),
)

बार-बार होने वाले ग्लोब के उदाहरण

यह टेस्ट, testdata डायरेक्ट्री की सभी फ़ाइल फ़ाइलों और उसकी सबडायरेक्ट्री (और उनकी सबडायरेक्ट्री वगैरह) पर निर्भर करता है. BUILD फ़ाइल वाली सबडायरेक्ट्री को अनदेखा कर दिया जाता है. (ऊपर दी गई सीमाएं और चेतावनियां देखें.)

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(["testdata/**/*.txt"]),
)

इस डायरेक्ट्री की सभी JavaScript फ़ाइलों और सबडायरेक्ट्री से बनी लाइब्रेरी बनाएं. उन सबडायरेक्ट्री को छोड़कर जिनके पाथ में टेस्टिंग नाम की डायरेक्ट्री शामिल होती है. अगर हो सके, तो इस पैटर्न से बचना चाहिए. ऐसा करने से, हो सकता है कि प्रोजेक्ट की संख्या कम हो जाए और बिल्ड होने में लगने वाला समय बढ़ जाए.

java_library(
    name = "mylib",
    srcs = glob(
        ["**/*.java"],
        exclude = ["**/testing/**"],
    ),
)

बड़े किए गए ग्लोब के उदाहरण

मौजूदा डायरेक्ट्री में *_test.cc के लिए एक ऐसा जेनरूल बनाएं जो फ़ाइल में मौजूद लाइनों की गिनती करता हो.

# Conveniently, the build language supports list comprehensions.
[genrule(
    name = "count_lines_" + f[:-3],  # strip ".cc"
    srcs = [f],
    outs = ["%s-linecount.txt" % f[:-3]],
    cmd = "wc -l $< >$@",
 ) for f in glob(["*_test.cc"])]

अगर ऊपर दी गई BUILD फ़ाइल पैकेज //foo में है और पैकेज में मेल खाने वाली तीन फ़ाइलें हैं, तो a_test.cc, b_test.cc, और c_test.cc चलने पर bazel query '//foo:all' जनरेट हुए सभी नियमों की सूची दिखाएगा:

$ bazel query '//foo:all' | sort
//foo:count_lines_a_test
//foo:count_lines_b_test
//foo:count_lines_c_test

चुनें

select(
    {conditionA: valuesA, conditionB: valuesB, ...},
    no_match_error = "custom message"
)

select() एक हेल्पर फ़ंक्शन है, जो नियम एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. यह करीब किसी भी एट्रिब्यूट असाइनमेंट की दाईं ओर मौजूद विकल्प को बदल सकता है. इसलिए, इसकी वैल्यू कमांड लाइन Bazel फ़्लैग के हिसाब से तय होती है. उदाहरण के लिए, इसका इस्तेमाल प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या अलग-अलग रिसॉर्स को एम्बेड करने के लिए किया जा सकता है. यह इस बात पर निर्भर करता है कि कोई नियम "डेवलपर" बनाम "रिलीज़" मोड में बनाया गया है या नहीं.

इसका बुनियादी इस्तेमाल इस तरह किया जाता है:

sh_binary(
    name = "mytarget",
    srcs = select({
        ":conditionA": ["mytarget_a.sh"],
        ":conditionB": ["mytarget_b.sh"],
        "//conditions:default": ["mytarget_default.sh"]
    })
)

ऐसा करने पर, sh_binary के srcs एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. इसके लिए, लेबल की सामान्य सूची असाइन किए गए असाइनमेंट को select कॉल से बदला जाता है. यह एट्रिब्यूट, कॉन्फ़िगरेशन की शर्तों को, वैल्यू से मेल खाने वाली वैल्यू से मैप करता है. हर शर्त config_setting या constraint_value का एक लेबल रेफ़रंस है, जो तब "मैच करता है", जब टारगेट का कॉन्फ़िगरेशन, वैल्यू के अनुमानित सेट से मेल खाता है. इसके बाद, mytarget#srcs की वैल्यू वह लेबल हो जाएगी जो लेबल की सूची, मौजूदा शुरू करने के कोड से मेल खाती है.

ध्यान दें:

किसी भी बातचीत के लिए, सिर्फ़ एक शर्त चुनी जाती है.
अगर कई शर्तें मेल खाती हैं और एक शर्त अन्य की विशेषज्ञता है, तो उस विशेषज्ञता को प्राथमिकता दी जाती है. शर्त B को शर्त A की विशेषज्ञता तब माना जाता है, जब B में A के तौर पर एक जैसे सभी फ़्लैग और कंस्ट्रेंट वैल्यू हों. साथ ही, कुछ दूसरे फ़्लैग या कंस्ट्रेंट वैल्यू भी मौजूद हों. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को, ऑर्डर तैयार करने के लिए नहीं डिज़ाइन किया गया है, जैसा कि नीचे उदाहरण 2 में दिखाया गया है.
अगर कई शर्तें मेल खाती हैं और एक, बाकी सभी की विशेषज्ञता नहीं है, तो Bazel गड़बड़ी के साथ तब तक काम नहीं करेगा, जब तक सभी शर्तों की वैल्यू एक ही न हो.
अगर कोई दूसरी शर्त पूरी नहीं होती है, तो खास स्यूडो-लेबल //conditions:default को मैच करने वाला माना जाता है. अगर यह शर्त शामिल नहीं की जाती है, तो गड़बड़ी से बचने के लिए कोई दूसरा नियम मेल खाना चाहिए.
select को एक बड़े एट्रिब्यूट असाइनमेंट के अंदर एम्बेड किया जा सकता है. इसलिए, srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...}) और srcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]}) मान्य एक्सप्रेशन हैं.
select ज़्यादातर एट्रिब्यूट के साथ काम करता है, लेकिन सभी एट्रिब्यूट के साथ नहीं. काम न करने वाले एट्रिब्यूट को उनके दस्तावेज़ों में nonconfigurable के तौर पर मार्क किया गया है.
सबपैकेज
```
subpackages(include, exclude=[], allow_empty=True)
```
subpackages() एक हेल्पर फ़ंक्शन है, जो glob() की तरह है. इसमें फ़ाइलों और डायरेक्ट्री के बजाय, सबपैकेज होते हैं. इसमें, glob() के पाथ पैटर्न का ही इस्तेमाल किया जाता है. साथ ही, यह ऐसे किसी भी सबपैकेज से मैच कर सकता है जो फ़िलहाल लोड हो रही BUILD फ़ाइल का सीधा डिसेंडेंट है. शामिल करने और बाहर रखने के पैटर्न की पूरी जानकारी और उदाहरणों के लिए, ग्लोब देखें.

इससे बनने वाले सबपैकेज की सूची को क्रम में लगाया जाता है. इसमें, लोड होने वाले मौजूदा पैकेज के हिसाब से पाथ शामिल किए जाते हैं. ये पाथ, include में दिए गए पैटर्न से मेल खाते हैं, न कि exclude में मौजूद पैटर्न से.
उदाहरण

इस उदाहरण में, foo/BUILD पैकेज के लिए सभी डायरेक्ट सबपैकेज की सूची दी गई है
```
# The following BUILD files exist:
# foo/BUILD
# foo/bar/baz/BUILD
# foo/sub/BUILD
# foo/sub/deeper/BUILD
#
# In foo/BUILD a call to
subs = subpackages(include = ["**"])

# results in subs == ["sub", "bar/baz"]
#
# 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
# 'foo'
```
आम तौर पर, इस फ़ंक्शन को सीधे कॉल करने के बजाय, इस बात का सुझाव दिया जाता है कि उपयोगकर्ता skylib के 'सबपैकेज' मॉड्यूल का इस्तेमाल करें.