फ़ंक्शन

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

कॉन्टेंट

पैकेज

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

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

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

पैकेज() फ़ंक्शन को फ़ाइल में डालें.

तर्क

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

default_package_metadata के लिए दूसरा ईमेल पता.

default_visibility

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

इस पैकेज में नियम डिफ़ॉल्ट तौर पर दिखते हैं.

इस पैकेज के हर नियम की 'किसको दिखे' सेटिंग, इसमें एट्रिब्यूट का इस्तेमाल करें, जब तक कि visibility में इसके बारे में अलग से न बताया गया हो एट्रिब्यूट की वैल्यू सबमिट करें. इसके सिंटैक्स के बारे में ज़्यादा जानकारी के लिए विशेषता के लिए, विज़िबिलिटी से जुड़ा दस्तावेज़ देखें. पैकेज डिफ़ॉल्ट दृश्यता इस पर लागू नहीं होती है exports_files, जो कि डिफ़ॉल्ट रूप से सार्वजनिक.

default_deprecation

String; "" डिफ़ॉल्ट है

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

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

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

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

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

उदाहरणः
  • 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 फ़ंक्शन में गड़बड़ी होती है खाली सूची.

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

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

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

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

  3. ग्लोब, सबडायरेक्ट्री की फ़ाइलों से मेल खा सकता है. और सबडायरेक्ट्री के नाम वाइल्डकार्ड वाला फ़ॉर्मैट इस्तेमाल कर सकता है. हालांकि...
  4. लेबल को पैकेज की सीमा पार करने की अनुमति नहीं है और ग्लोब को सबपैकेज की फ़ाइलों से मेल नहीं खाएगा.

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

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

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

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

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

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

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"],
    ),
)

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

जांच को, 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 के लिए अलग-अलग जेन रूल बनाएं जो फ़ाइल में मौजूद लाइनों की गिनती करती है.

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

सामान्य इस्तेमाल के बारे में यहां बताया गया है:

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

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

ध्यान दें:

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

    glob() से मिलता-जुलता, subpackages() एक हेल्पर फ़ंक्शन है जिसमें फ़ाइलों और डायरेक्ट्री के बजाय सबपैकेज की सूची होती है. यह उसी पाथ पैटर्न को glob() की तरह इस्तेमाल करता है. साथ ही, वह किसी भी ऐसे सबपैकेज से मेल खा सकता है जो जो अभी लोड हो रही BUILD फ़ाइल का डायरेक्ट डिसेंडेंट है. प्रॉडक्ट और सेवाओं को शामिल करने और पैटर्न शामिल न करें.

    वापस लौटाए गए सबपैकेज की सूची क्रम से दी गई है और इसमें यह शामिल है लोड होने वाले मौजूदा पैकेज के ऐसे पाथ जो नीचे दिए गए पैटर्न से मेल खाते हैं 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 है.