फ़ंक्शन

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 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() लेते हैं.

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

तर्क

एट्रिब्यूट ब्यौरा
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/*.txt, foo/ डायरेक्ट्री में मौजूद हर फ़ाइल से मैच करता है, अगर फ़ाइल का आखिरी हिस्सा .txt है (जब तक कि 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" नाम का एक नियम भी है (इसकी अनुमति है, हालांकि Bazel इसके बारे में चेतावनी देता है), तो 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",
    ],
    ...
)

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

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 में बताया गया है.
  • अगर कई शर्तें मैच करती हैं और कोई एक शर्त, बाकी सभी शर्तों की विशेषता नहीं है, तो 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)

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

    सब-पैकेज की यह सूची, क्रम से लगाई गई होती है. इसमें, 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 के 'सब-पैकेज' मॉड्यूल का इस्तेमाल करना चाहिए.