फ़ंक्शन

कॉन्टेंट

• पैकेज
• package_group
• exports_files
• glob
• चुनें
• सबपैकेज

पैकेज

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

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

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

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

तर्क

उदाहरण

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

package_group

package_group(name, packages, includes)

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

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

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

तकनीकी तौर पर, पैकेज ग्रुप को टारगेट किया जाता है. हालांकि, वे नियमों के हिसाब से नहीं बनाए जाते. साथ ही, वे ये काम करते हैं उसके पास कोई विज़िबिलिटी सुरक्षा न हो.

तर्क

उदाहरण

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

उदाहरण

यहां दिए गए उदाहरण में, test_data पैकेज से golden.txt टेक्स्ट फ़ाइल को एक्सपोर्ट किया गया है, ताकि अन्य पैकेज इसका इस्तेमाल कर सकें. उदाहरण के लिए, टेस्ट के 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" नाम का एक नियम भी है (इसकी अनुमति है, हालांकि Bazel इसके बारे में चेतावनी देता है), तो glob() का इस्तेमाल करने वाला व्यक्ति "Foo.java" फ़ाइल के बजाय, "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub पर मौजूद समस्या #10395 देखें.

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

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

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

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 के लिए एक अलग 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"]
    })
)

इससे srcs एट्रिब्यूट sh_binary का ऐसा लेबल जिसे उसके सामान्य लेबल की जगह इस्तेमाल करके कॉन्फ़िगर किया जा सकता है 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)

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