तारीख सेव करें: BazelCon 2023, 24 से 25 अक्टूबर तक Google म्यूनिख में होगा! रजिस्ट्रेशन अब शुरू हो गया है! ज़्यादा जानें

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

Switch to English

फ़ंक्शन

समस्या की शिकायत करें स्रोत देखें

विषय सूची

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

पैकेज

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

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

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

तर्क

एट्रिब्यूट	जानकारी
`default_applicable_licenses`	`default_package_metadata` का उपनाम.
`default_visibility`	`List of labels; optional` इस पैकेज में नियमों की डिफ़ॉल्ट दृश्यता. इस पैकेज के हर नियम में, इस एट्रिब्यूट के दिखने की जानकारी दी गई है. हालांकि, इससे पहले `visibility` के एट्रिब्यूट में बताया जाएगा. इस एट्रिब्यूट के सिंटैक्स के बारे में ज़्यादा जानने के लिए, किसको दिखे का दस्तावेज़ देखें. पैकेज डिफ़ॉल्ट तौर पर दिखने की सेटिंग, exports_files पर लागू नहीं होती. यह डिफ़ॉल्ट रूप से सार्वजनिक होता है.
`default_deprecation`	`String; optional` इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट `deprecation` मैसेज सेट करता है.
`default_package_metadata`	`List of labels; optional` इस नीति से, मेटाडेटा टारगेट की डिफ़ॉल्ट सूची सेट होती है. यह सूची, पैकेज में मौजूद दूसरे सभी टारगेट पर लागू होती है. ये आम तौर पर, ओएसएस पैकेज और लाइसेंस से जुड़े एलानों से जुड़े टारगेट होते हैं. उदाहरण के लिए, नियम_लाइसेंस देखें.
`default_testonly`	`Boolean; optional; default is False except as noted` इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट `testonly` प्रॉपर्टी सेट करता है. `javatests` के पैकेज में डिफ़ॉल्ट वैल्यू 1 है.
`features`	`List strings; optional` इस BUILD फ़ाइल के सिमेंटिक पर असर डालने वाले अलग-अलग फ़्लैग सेट करता है. यह सुविधा मुख्य रूप से, उन लोगों को इस्तेमाल करती है जो बिल्ड सिस्टम पर काम करते हैं. वे ऐसे पैकेज को टैग करते हैं जिन्हें किसी खास तरह की देखरेख की ज़रूरत होती है. यह तब तक इस्तेमाल न करें, जब तक कि बिल्ड सिस्टम पर काम करने वाला कोई व्यक्ति साफ़ तौर पर इसका अनुरोध न करे.

उदाहरण

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

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

package_group (पैकेज_ग्रुप)

package_group(name, packages, includes)

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

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

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

पैकेज ग्रुप तकनीकी रूप से टारगेट होते हैं, लेकिन ये नियमों के हिसाब से नहीं बनाए जाते, और इनमें किसी तरह की सुरक्षा भी नहीं होती.

तर्क

एट्रिब्यूट जानकारी

एट्रिब्यूट	जानकारी
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`packages`	`List of strings; optional` शून्य या ज़्यादा पैकेज विशेषताओं की एक सूची. पैकेज की खास बातों की हर स्ट्रिंग में, इनमें से कोई एक फ़ॉर्म हो सकता है: किसी पैकेज का पूरा नाम, जो इसके डेटा स्टोर करने की जगह के बिना होता है, डबल स्लैश से शुरू होता है. उदाहरण के लिए, `//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` के चालू होने पर, यह कार्रवाई ठीक की जाती है. यह बेज़ल 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`	`List of labels; optional` इस पैकेज में शामिल अन्य पैकेज ग्रुप. इस एट्रिब्यूट में दिए गए लेबल से दूसरे पैकेज ग्रुप का पता चलना चाहिए. बताए गए पैकेज ग्रुप में पैकेज, इस पैकेज ग्रुप का हिस्सा हैं. यह ट्रांज़िटिव है — अगर पैकेज ग्रुप `a` में पैकेज ग्रुप `b` शामिल है और `b` में पैकेज ग्रुप `c` शामिल है, तो `c` में मौजूद हर पैकेज भी `a` का सदस्य होगा. पैकेज नहीं किए गए पैकेज की खास बातों के साथ इस्तेमाल किए जाने पर, ध्यान दें कि हर ग्रुप के पैकेज का सेट सबसे पहले अलग से कैलकुलेट किया जाता है. इसके बाद, नतीजों को एक साथ रखा जाता है. इसका मतलब है कि किसी एक ग्रुप में शामिल नहीं किए गए स्पेसिफ़िकेशन, दूसरे ग्रुप की स्पेसिफ़िकेशन पर असर नहीं डालते हैं.

name

Name; required

इस टारगेट के लिए खास नाम.

packages

List of strings; optional

शून्य या ज़्यादा पैकेज विशेषताओं की एक सूची.

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

किसी पैकेज का पूरा नाम, जो इसके डेटा स्टोर करने की जगह के बिना होता है, डबल स्लैश से शुरू होता है. उदाहरण के लिए, //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 के चालू होने पर, यह कार्रवाई ठीक की जाती है. यह बेज़ल 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

List of labels; optional

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

इस एट्रिब्यूट में दिए गए लेबल से दूसरे पैकेज ग्रुप का पता चलना चाहिए. बताए गए पैकेज ग्रुप में पैकेज, इस पैकेज ग्रुप का हिस्सा हैं. यह ट्रांज़िटिव है — अगर पैकेज ग्रुप 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"],
)

Export_files

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

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

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

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

तर्क

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

उदाहरण

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

# from //test_data/BUILD

exports_files(["golden.txt"])

ग्लोब

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

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

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

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

उदाहरण:

foo/bar.txt इस पैकेज में मौजूद foo/bar.txt फ़ाइल से मेल खाता है
अगर फ़ाइल .txt से खत्म होती है, तो यह foo/ डायरेक्ट्री की हर फ़ाइल से मेल खाती है (जब तक कि foo/ एक सब-पैकेज न हो)
foo/a*.htm*, foo/ से जुड़ी हर उस फ़ाइल से मेल खाता है जो a से शुरू होती है. इसके बाद, आर्बिट्ररी स्ट्रिंग (जो खाली हो सकती है) मौजूद होती है. इसके बाद, .htm होती है और यह किसी दूसरी आर्बिट्ररी स्ट्रिंग पर खत्म होती है, जैसे कि foo/axx.htm और foo/a.html
**/a.txt इस पैकेज की हर सब-डायरेक्ट्री में मौजूद हर a.txt फ़ाइल से मेल खाता है
**/bar/**/*.txt इस पैकेज की हर सबडायरेक्ट्री में हर .txt फ़ाइल से मेल खाता है. इसके बाद, जब नतीजे वाले पाथ पर कम से कम एक डायरेक्ट्री को bar कहा जाता है, जैसे कि 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" (जिसे बैजल इसके बारे में चेतावनी देता है) पैकेज में भी एक नियम है, तो glob() का उपभोक्ता "Foo.java" फ़ाइल के बजाय "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub से जुड़ी समस्या #10395 देखें.
ग्लोब, सबडायरेक्ट्री की फ़ाइलों से मेल खा सकते हैं. सबडायरेक्ट्री के नामों में वाइल्डकार्ड का इस्तेमाल किया जा सकता है. हालांकि...
लेबल को पैकेज की सीमा पार करने और ग्लोब की मदद से, सबपैकेज में मौजूद फ़ाइलों से मेल खाने की अनुमति नहीं है.

उदाहरण के लिए, पैकेज x में ग्लोब एक्सप्रेशन **/*.cc में x/y/z.cc को शामिल नहीं किया जाता है, अगर x/y पैकेज के रूप में (या x/y/BUILD या पैकेज पाथ पर कहीं और मौजूद है) में शामिल होता है. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा असल में BUILD फ़ाइलों की मौजूदगी पर निर्भर करता है — अगर x/y नाम का कोई पैकेज नहीं था, तो उसी ग्लोब एक्सप्रेशन में x/y/z.cc को शामिल किया जाएगा या --delete_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",
    ],
    ...
)

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

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

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

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

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

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

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

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

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

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

ध्यान दें:

शुरू करने के किसी भी न्योते पर सिर्फ़ एक शर्त चुनी जाती है.
अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त अन्य की विशेषज्ञता है, तो विशेषज्ञता को प्राथमिकता दी जाती है. शर्त B को स्थिति A की विशेषज्ञता माना जाता है. ऐसा तब होता है, जब B में सभी फ़्लैग और कंस्ट्रेंट वैल्यू, A के तौर पर एक जैसी हों. साथ ही, इसमें कुछ दूसरे फ़्लैग या कंस्ट्रेंट वैल्यू भी शामिल हों. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को ऑर्डर करने के लिए नहीं बनाया गया है, जैसा कि नीचे उदाहरण 2 में दिखाया गया है.
अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त अन्य सभी के लिए विशेषज्ञता नहीं है, तो बेज़ल किसी गड़बड़ी के साथ काम नहीं करेगा. ऐसा तब तक होगा, जब तक सभी शर्तें एक ही वैल्यू के लिए ठीक नहीं हो जातीं.
अगर कोई दूसरी शर्त मेल नहीं खाती है, तो खास स्यूडो-लेबल //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 के 'सबपैकेज' मॉड्यूल का इस्तेमाल करें.

फ़ंक्शन

विषय सूची

पैकेज

तर्क

उदाहरण

package_group (पैकेज_ग्रुप)

तर्क

उदाहरण

Export_files

तर्क

उदाहरण

ग्लोब

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

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

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

चुनें

सब-पैकेज

उदाहरण