Build Foundation ने फ़ाउंडिंग सदस्यों के तौर पर लोगों को शामिल करना शुरू कर दिया है! ईमेल पाने वाली सूची में शामिल हों, रिसर्च में हिस्सा लेने से जुड़ा कानूनी समझौता पढ़ें, और रजिस्टर करें!

Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

फ़ंक्शन

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

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

पैकेज

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

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

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

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

तर्क

एट्रिब्यूट	ब्यौरा
`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`	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

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 एलान में, "tropical" नाम के पैकेज ग्रुप के बारे में बताया गया है. इसमें ट्रॉपिकल फल शामिल हैं.

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

उदाहरण

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

# from //test_data/BUILD

exports_files(["golden.txt"])

glob

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

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

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

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

उदाहरण:

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

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

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

इसकी कुछ अहम सीमाएं और चेतावनियां हैं:

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

आम तौर पर, आपको ग्लोब पैटर्न के लिए सिर्फ़ '*' का इस्तेमाल करने के बजाय, सही एक्सटेंशन (जैसे, *.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",
    ],
    ...
)

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

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

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

टेस्ट को testdata डायरेक्ट्री और उसकी किसी भी सबडायरेक्ट्री (और उनकी सबडायरेक्ट्री वगैरह) में मौजूद सभी 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 के लिए एक अलग genrule बनाएं, जो फ़ाइल में मौजूद लाइनों की संख्या गिनता हो.

# 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 फ़ाइल के किसी भी सबपैकेज से मैच कर सकता है. शामिल करने और बाहर रखने के पैटर्न के बारे में ज़्यादा जानकारी और उदाहरणों के लिए, glob देखें.

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

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

# results in subs1 == ["sub", "bar/baz", "bar/but/bad"]
#
# 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
# 'foo'

subs2 = subpackages(include = ["bar/*"])
# results in subs2 = ["bar/baz"]
#
# Since 'bar' is not a subpackage itself, this looks for any subpackages under
# all first level subdirectories of 'bar'.

subs3 = subpackages(include = ["bar/**"])
# results in subs3 = ["bar/baz", "bar/but/bad"]
#
# Since bar is not a subpackage itself, this looks for any subpackages which are
# (1) under all subdirectories of 'bar' which can be at any level, (2) not a
# subpackage of another subpackages.

subs4 = subpackages(include = ["sub"])
subs5 = subpackages(include = ["sub/*"])
subs6 = subpackages(include = ["sub/**"])
# results in subs4 and subs6 being ["sub"]
# results in subs5 = [].
#
# In subs4, expression "sub" checks whether 'foo/sub' is a package (i.e. is a
# subpackage of 'foo').
# In subs5, "sub/*" looks for subpackages under directory 'foo/sub'. Since
# 'foo/sub' is already a subpackage itself, the subdirectories will not be
# traversed anymore.
# In subs6, 'foo/sub' is a subpackage itself and matches pattern "sub/**", so it
# is returned. But the subdirectories of 'foo/sub' will not be traversed
# anymore.
```
आम तौर पर, इस फ़ंक्शन को सीधे कॉल करने के बजाय, उपयोगकर्ता skylib के 'subpackages' मॉड्यूल का इस्तेमाल करते हैं.

फ़ंक्शन संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

सामग्री

पैकेज

तर्क

उदाहरण

package_group

तर्क

उदाहरण

exports_files

तर्क

उदाहरण

glob

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

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

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

चुनें

सबपैकेज

उदाहरण

फ़ंक्शन