फ़ंक्शन

कॉन्टेंट

• पैकेज
• package_group (पैकेज_ग्रुप)
• exports_files
• ग्लोब
• चुनें
• सब-पैकेज

पैकेज

package(default_deprecation, default_testonly, default_visibility, features)

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

किसी भी नियम से पहले, 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"],
)

Export_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 एक हेल्पर फ़ंक्शन है, जो कुछ पाथ पैटर्न से मेल खाने वाली सभी फ़ाइलें ढूंढता है. साथ ही, अपने पाथ की एक नई, बदली जा सकने वाली सूची दिखाता है. Glob सिर्फ़ अपने पैकेज में फ़ाइलें खोजता है. साथ ही, सिर्फ़ स्रोत फ़ाइलों को खोजता है (न कि जनरेट की गई फ़ाइलों को, न ही किसी दूसरे टारगेट को).

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

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

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

अगर exclude_directories आर्ग्युमेंट चालू है (1 पर सेट है), तो किसी भी डायरेक्ट्री की फ़ाइलें, नतीजों में नहीं दिखेंगी (डिफ़ॉल्ट 1).

अगर allow_empty आर्ग्युमेंट False पर सेट है, तो नतीजे न होने पर glob फ़ंक्शन में गड़बड़ी दिखेगी.

हालांकि, इससे जुड़ी कुछ ज़रूरी सीमाएं हैं:

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

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

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

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

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

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

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

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

java_library(
    name = "mylib",
    srcs = glob(["*.java"]) + [":gen_java_srcs"],
    deps = "...",
)

genrule(
    name = "gen_java_srcs",
    outs = [
        "Foo.java",
        "Bar.java",
    ],
    ...
)

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

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

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

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

$ 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"
)

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