फ़ंक्शन

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

विषय सूची

पैकेज

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

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

पूरे डेटा स्टोर करने की जगह में हर नियम पर मेटाडेटा लागू करने का एलान करने वाले काउंटरपार्ट के लिए, अपने रेपो के रूट में REPO.bazel फ़ाइल में repo() फ़ंक्शन का इस्तेमाल करें. repo() फ़ंक्शन ठीक वही तर्क लेता है जो 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

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

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

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

शून्य या उससे ज़्यादा पैकेज के बारे में खास जानकारी की सूची.

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

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

इसके अलावा, पैकेज के पहले दो तरह के स्पेसिफ़िकेशन के आगे भी - लगाया जा सकता है. इससे पता चलता है कि पैकेज को अस्वीकार किया गया है.

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

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

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

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

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

उदाहरण

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

# from //test_data/BUILD

exports_files(["golden.txt"])

ग्लोब

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

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

अगर फ़ाइल का पैकेज-रिलेटिव पाथ, किसी भी 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/**/*.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 फ़ंक्शन में गड़बड़ी होगी. ऐसा तब होगा, जब नतीजा खाली हो.

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

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

  2. अगर किसी नियम का नाम और मेल खाने वाली सोर्स फ़ाइल का नाम एक ही है, तो यह नियम फ़ाइल को "शैडो" कर देगा.

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

  3. ग्लोब, सबडायरेक्ट्री की फ़ाइलों से मेल खा सकता है. साथ ही, सबडायरेक्ट्री के नाम वाइल्डकार्ड हो सकते हैं. हालांकि...

  4. लेबल को पैकेज की सीमा पार करने की अनुमति नहीं है और ग्लोब सबपैकेज की फ़ाइलों से मेल नहीं खाता.

    उदाहरण के लिए, अगर x/y पैकेज के तौर पर (x/y/BUILD के तौर पर या पैकेज-पाथ पर कहीं और) मौजूद है, तो x पैकेज में ग्लोब एक्सप्रेशन **/*.cc में x/y/z.cc शामिल नहीं होता. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा, BUILD फ़ाइलों के मौजूद होने पर निर्भर करता है. इसका मतलब है कि अगर x/y नाम का कोई पैकेज नहीं था या --deleted_packages फ़्लैग का इस्तेमाल करके, इसे 'मिटाया गया' के तौर पर मार्क किया गया था, तो उसी ग्लोब एक्सप्रेशन में x/y/z.cc शामिल होगा.

  5. ऊपर दी गई पाबंदी सभी ग्लोब एक्सप्रेशन पर लागू होती है. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस वाइल्डकार्ड का इस्तेमाल करते हैं.
  6. . से शुरू होने वाले फ़ाइल नाम वाली छिपी हुई फ़ाइल को ** और * वाइल्डकार्ड, दोनों से पूरी तरह मैच किया जाता है. अगर आपको किसी छिपी हुई फ़ाइल का मिलान किसी कंपाउंड पैटर्न से करना है, तो पैटर्न की शुरुआत . से होनी चाहिए. उदाहरण के लिए, * और .*.txt, .foo.txt से मेल खाएंगे, लेकिन *.txt नहीं. छिपी हुई डायरेक्ट्री भी इसी तरह से मैच की जाती हैं. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें हो सकती हैं जो इनपुट के तौर पर ज़रूरी नहीं हैं. साथ ही, इससे ग़ैर-ज़रूरी फ़ाइलों की संख्या बढ़ सकती है और मेमोरी का इस्तेमाल बढ़ सकता है. छिपी हुई डायरेक्ट्री को शामिल न करने के लिए, उन्हें सूची में मौजूद "बाहर रखें" आर्ग्युमेंट में जोड़ें.
  7. "**" वाइल्डकार्ड में एक कोने वाला केस होता है: "**" पैटर्न, पैकेज के डायरेक्ट्री पाथ से मेल नहीं खाता. इसका मतलब यह है कि 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 को छोड़कर, सभी txt फ़ाइलों को testdata डायरेक्ट्री में शामिल करें. ध्यान दें कि टेस्टडेटा की सबडायरेक्ट्री की फ़ाइलों को शामिल नहीं किया जाएगा. अगर आपको उन फ़ाइलों को शामिल करना है, तो रिकर्सिव ग्लोब (**) का इस्तेमाल करें.

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

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

यह टेस्ट, टेस्ट डेटा डायरेक्ट्री में मौजूद सभी 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 एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. इसके लिए, लेबल की सामान्य सूची के असाइनमेंट को select कॉल से बदला जा सकता है. यह वैल्यू, कॉन्फ़िगरेशन की शर्तों को मैच करने वाली वैल्यू पर मैप करती है. हर शर्त, config_setting या constraint_value का एक लेबल रेफ़रंस होती है. अगर टारगेट का कॉन्फ़िगरेशन, वैल्यू के अनुमानित सेट से मेल खाता है, तो यह "मैच करता है". इसके बाद, mytarget#srcs की वैल्यू उस लेबल की सूची बन जाएगी जो मौजूदा लेबल की सूची से मेल खाती है.

ध्यान दें:

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