फ़ंक्शन

कॉन्टेंट

• पैकेज
• package_group
• exports_files
• ग्लोब
• चुनें
• सबपैकेज

पैकेज

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

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

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

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

तर्क

उदाहरण

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

उदाहरण

यहां दिए गए उदाहरण में, 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() पथ की गणना करते हैं, इसलिए अन्य नियमों में 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/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 है.