फ़ंक्शन

सामग्री

• package
• package_group
• exports_files
• glob
• select
• subpackages

package

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

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

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

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

तर्क

उदाहरण

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

package_group

package_group(name, packages, includes)

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

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

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

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

आर्ग्युमेंट

उदाहरण

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 फ़ंक्शन में गड़बड़ी दिखेगी.

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

1. glob() , BUILD फ़ाइल के आकलन के दौरान चलता है. इसलिए, 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. Glob, सबडायरेक्ट्री में मौजूद फ़ाइलों से मैच कर सकता है. साथ ही, सबडायरेक्ट्री के नामों में वाइल्डकार्ड का इस्तेमाल किया जा सकता है. हालांकि...

4. लेबल को पैकेज की सीमा से बाहर इस्तेमाल नहीं किया जा सकता. साथ ही, glob, सब-पैकेज में मौजूद फ़ाइलों से मैच नहीं करता.

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

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

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

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

Glob के उदाहरण

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

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

रिकर्सिव Glob के उदाहरण

टेस्ट को testdata डायरेक्ट्री और उसकी किसी भी सबडायरेक्ट्री (और उनकी सबडायरेक्ट्री वगैरह) में मौजूद सभी txt फ़ाइलों पर निर्भर बनाएं. BUILD फ़ाइल वाली सबडायरेक्ट्री को अनदेखा किया जाता है. (ऊपर दी गई सीमाएं और चेतावनियां देखें.)

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

इस डायरेक्ट्री और सभी सबडायरेक्ट्री में मौजूद सभी java फ़ाइलों से एक लाइब्रेरी बनाएं. हालांकि, इसमें ऐसी सबडायरेक्ट्री शामिल नहीं की जाएंगी जिनके पाथ में testing नाम की डायरेक्ट्री शामिल है. अगर हो सके, तो इस पैटर्न का इस्तेमाल नहीं करना चाहिए. इससे बिल्ड की इंक्रीमेंटैलिटी कम हो सकती है और इसलिए, बिल्ड में लगने वाला समय बढ़ सकता है.

java_library(
    name = "mylib",
    srcs = glob(
        ["**/*.java"],
        exclude = ["**/testing/**"],
    ),
)

Glob के बड़े किए गए उदाहरण

मौजूदा डायरेक्ट्री में मौजूद *_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

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 में हैं. साथ ही, इसमें कुछ अतिरिक्त फ़्लैग या कंस्ट्रेंट वैल्यू भी मौजूद हों. इसका मतलब यह भी है कि स्पेशलाइज़ेशन रिज़ॉल्यूशन को ऑर्डरिंग बनाने के लिए डिज़ाइन नहीं किया गया है. जैसा कि नीचे दिए गए दूसरे उदाहरण में दिखाया गया है.
• अगर एक से ज़्यादा शर्तें मैच करती हैं और उनमें से कोई एक, अन्य सभी शर्तों का स्पेशलाइज़ेशन नहीं है, तो Bazel में गड़बड़ी दिखती है. हालांकि, ऐसा तब नहीं होता, जब सभी शर्तों की वैल्यू एक जैसी हो.
• अगर कोई अन्य शर्त मैच नहीं करती है, तो खास स्यूडो-लेबल //conditions:default को मैच करने वाला माना जाता है. अगर इस शर्त को छोड़ दिया जाता है, तो गड़बड़ी से बचने के लिए, किसी अन्य नियम को मैच करना होगा.
• select को, एट्रिब्यूट के बड़े असाइनमेंट में एम्बेड किया जा सकता है. इसलिए, srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...}) और srcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]}) मान्य एक्सप्रेशन हैं.
• select, ज़्यादातर एट्रिब्यूट के साथ काम करता है. हालांकि, सभी के साथ नहीं. असंगत एट्रिब्यूट को उनके दस्तावेज़ में nonconfigurable के तौर पर मार्क किया जाता है.

  subpackages

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