विषय सूची
पैकेज
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
यह फ़ंक्शन, पैकेज के हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताता है. इसका इस्तेमाल किसी पैकेज (BUILD फ़ाइल) के अंदर ज़्यादा से ज़्यादा एक बार किया जाता है.
पूरे डेटा स्टोर करने की जगह में हर नियम पर मेटाडेटा लागू करने का एलान करने वाले काउंटरपार्ट के लिए, अपने रेपो के रूट में REPO.bazel
फ़ाइल में repo()
फ़ंक्शन का इस्तेमाल करें.
repo()
फ़ंक्शन ठीक वही तर्क लेता है जो package()
लेते हैं.
पैकेज() फ़ंक्शन को किसी भी नियम से पहले, फ़ाइल के सबसे ऊपर मौजूद सभी load() स्टेटमेंट के ठीक बाद कॉल किया जाना चाहिए.
तर्क
एट्रिब्यूट | कंपनी का ब्यौरा |
---|---|
default_applicable_licenses |
|
default_visibility |
लेबल की सूची; डिफ़ॉल्ट इस पैकेज में नियम डिफ़ॉल्ट तौर पर दिखते हैं. इस पैकेज के हर नियम के लिए, इस एट्रिब्यूट में 'किसको दिखे' सेटिंग
बताई गई है. ऐसा तब तक होगा, जब तक कि नियम के |
default_deprecation |
स्ट्रिंग; डिफ़ॉल्ट तौर पर इस पैकेज में मौजूद सभी नियमों के लिए, डिफ़ॉल्ट
|
default_package_metadata |
लेबल की सूची; डिफ़ॉल्ट मेटाडेटा टारगेट की डिफ़ॉल्ट सूची सेट करती है. यह सूची पैकेज के दूसरे सभी टारगेट पर लागू होती है. आम तौर पर, ये टारगेट ओएसएस पैकेज और लाइसेंस के एलान से जुड़े होते हैं. उदाहरणों के लिए rules_license से जुड़े उदाहरण देखें. |
default_testonly |
बूलियन; बताए गए के अलावा इस पैकेज में मौजूद सभी नियमों के लिए, डिफ़ॉल्ट
|
features |
लिस्ट स्ट्रिंग; डिफ़ॉल्ट तौर पर इस BUILD फ़ाइल के सिमैंटिक पर असर डालने वाले अलग-अलग फ़्लैग सेट करता है. इस सुविधा का इस्तेमाल मुख्य रूप से, बिल्ड सिस्टम पर काम करने वाले लोग करते हैं. इसका इस्तेमाल, ऐसे पैकेज को टैग करने के लिए किया जाता है जिन्हें किसी खास तरीके से हैंडल करने की ज़रूरत होती है. इसका इस्तेमाल तब तक न करें, जब तक कि बिल्ड सिस्टम पर काम करने वाले किसी व्यक्ति ने साफ़ तौर पर इसके लिए अनुरोध न किया हो. |
उदाहरण
यहां दिए गए एलान में बताया गया है कि इस पैकेज के नियम सिर्फ़ पैकेज ग्रुप//foo:target
के सदस्यों को दिखते हैं. अगर किसी नियम में यह जानकारी मौजूद है, तो उसे बदल दिया जाएगा.
package(default_visibility = ["//foo:target"])
package_group
package_group(name, packages, includes)
यह फ़ंक्शन पैकेज के सेट के बारे में बताता है और सेट के साथ लेबल जोड़ता है. इस लेबल का रेफ़रंस visibility
एट्रिब्यूट में दिया जा सकता है.
पैकेज ग्रुप का इस्तेमाल मुख्य रूप से, 'किसको दिखे' सेटिंग कंट्रोल के लिए किया जाता है. सोर्स ट्री में मौजूद हर पैकेज से, सार्वजनिक तौर पर दिखने वाले टारगेट का रेफ़रंस दिया जा सकता है. निजी तौर पर दिखने वाले टारगेट का रेफ़रंस सिर्फ़ उसके खुद के पैकेज (सबपैकेज नहीं) में दिया जा सकता है. इन सीमाओं के दौरान, कोई टारगेट अपने खुद के पैकेज के साथ-साथ, एक या एक से ज़्यादा पैकेज ग्रुप की ओर से बताए गए किसी भी पैकेज को ऐक्सेस करने की अनुमति दे सकता है. 'किसको दिखे' सेटिंग के बारे में ज़्यादा जानने के लिए, विज़िबिलिटी एट्रिब्यूट देखें.
किसी दिए गए पैकेज को तब ग्रुप में शामिल माना जाता है, जब वह packages
एट्रिब्यूट से मेल खाता हो या पहले से ही includes
एट्रिब्यूट में बताए गए किसी दूसरे पैकेज ग्रुप में मौजूद हो.
तकनीकी तौर पर, पैकेज ग्रुप को टारगेट किया जाता है. हालांकि, वे नियमों के हिसाब से नहीं बनाए जाते. साथ ही, पैकेज ग्रुप के लिए 'किसको दिखे' सेटिंग भी नहीं होती.
तर्क
एट्रिब्यूट | कंपनी का ब्यौरा |
---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. |
packages |
स्ट्रिंग की सूची; डिफ़ॉल्ट शून्य या उससे ज़्यादा पैकेज के बारे में खास जानकारी की सूची. पैकेज के लिए बने स्पेसिफ़िकेशन वाली हर स्ट्रिंग में इनमें से कोई एक फ़ॉर्म हो सकता है:
इसके अलावा, पैकेज के पहले दो तरह के स्पेसिफ़िकेशन के आगे भी पैकेज ग्रुप में ऐसा कोई भी पैकेज शामिल होता है जो कम से कम किसी एक
पॉज़िटिव स्पेसिफ़िकेशन से मेल खाता हो और किसी भी नेगेटिव स्पेसिफ़िकेशन से मेल न खाता हो.
उदाहरण के लिए, वैल्यू सार्वजनिक तौर पर दिखने के अलावा, डेटा स्टोर करने की मौजूदा जगह के बाहर के पैकेज के बारे में सीधे तौर पर बताने का कोई तरीका नहीं है. अगर यह एट्रिब्यूट मौजूद नहीं है, तो यह इसे खाली सूची पर सेट करने जैसा ही है. इसका मतलब इसे सिर्फ़ ध्यान दें: Basel 6.0 से पहले, स्पेसिफ़िकेशन ध्यान दें: Baze 6.0 से पहले के वर्शन में, जब इस एट्रिब्यूट को
|
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)
ग्लोब एक हेल्पर फ़ंक्शन है, जो कुछ पाथ पैटर्न से मेल खाने वाली सभी फ़ाइलें ढूंढता है और उनके पाथ की नई, बदली जा सकने वाली, क्रम से लगाई गई सूची दिखाता है. ग्लोब सिर्फ़ अपने पैकेज में फ़ाइलें खोजता है और सिर्फ़ सोर्स फ़ाइलों को ढूंढता है (जनरेट की गई फ़ाइलें या दूसरे टारगेट नहीं).
अगर फ़ाइल का पैकेज-रिलेटिव पाथ, किसी भी include
पैटर्न से मेल खाता है और किसी भी exclude
पैटर्न से मेल नहीं खाता, तो सोर्स फ़ाइल का लेबल, नतीजे में शामिल किया जाता है.
include
और exclude
सूचियों में ऐसे पाथ पैटर्न मौजूद हैं जो मौजूदा पैकेज से मिलते-जुलते हैं. हर पैटर्न में एक या उससे ज़्यादा पाथ सेगमेंट हो सकते हैं. हमेशा की तरह, यूनिक्स पाथ के साथ भी ये सेगमेंट /
से अलग किए जाते हैं. पैटर्न में शामिल सेगमेंट का मिलान पाथ के सेगमेंट से किया जाता है. सेगमेंट में *
वाइल्डकार्ड हो सकता है: यह पाथ सेगमेंट की किसी भी सबस्ट्रिंग (यहां तक कि खाली सबस्ट्रिंग भी) से मेल खाता है. हालांकि, इसमें डायरेक्ट्री सेपरेटर /
का इस्तेमाल नहीं किया जाता. इस वाइल्डकार्ड का इस्तेमाल, पाथ के एक सेगमेंट में
कई बार किया जा सकता है. इसके अलावा, **
वाइल्डकार्ड, शून्य या उससे ज़्यादा पूरे पाथ सेगमेंट से मैच कर सकता है, लेकिन इसे स्टैंडअलोन पाथ सेगमेंट के तौर पर एलान करना ज़रूरी है.
foo/bar.txt
इस पैकेज में मौजूदfoo/bar.txt
फ़ाइल से पूरी तरह मेल खाता है (जब तक किfoo/
एक सबपैकेज न हो)- अगर फ़ाइल
.txt
पर खत्म होती है, तोfoo/*.txt
,foo/
डायरेक्ट्री की हर फ़ाइल से मेल खाता है (जब तक कि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
फ़ंक्शन में गड़बड़ी होगी. ऐसा तब होगा, जब नतीजा खाली हो.
इसकी कई अहम सीमाएं और सावधानियां हैं:
-
glob()
, बिल्ड फ़ाइल की जांच के दौरान चलता है. इसलिए,glob()
, सिर्फ़ आपके सोर्स ट्री की फ़ाइलों को मैच करता है, कभी जनरेट नहीं की गई फ़ाइलें. अगर कोई ऐसा टारगेट बनाया जा रहा है जिसके लिए सोर्स और जनरेट की गई फ़ाइलें, दोनों की ज़रूरत है, तो आपको ग्लोब में जनरेट की गई फ़ाइलों की एक खास सूची जोड़नी होगी.:mylib
और:gen_java_srcs
के साथ नीचे दिया गया उदाहरण देखें. -
अगर किसी नियम का नाम और मेल खाने वाली सोर्स फ़ाइल का नाम एक ही है, तो यह नियम फ़ाइल को "शैडो" कर देगा.
इसे समझने के लिए, याद रखें कि
glob()
, पाथ की सूची दिखाता है. इसलिए, दूसरे नियमों के एट्रिब्यूट (जैसे,srcs = glob(["*.cc"])
) मेंglob()
का इस्तेमाल करने से, मेल खाने वाले पाथ की सटीक जानकारी देने जैसा ही असर पड़ता है. उदाहरण के लिए, अगरglob()
से["Foo.java", "bar/Baz.java"]
मिलता है, लेकिन पैकेज में "Foo.java" नाम का एक नियम भी है (जिसकी अनुमति है, हालांकि Basel इसके बारे में चेतावनी देता है), तोglob()
का उपभोक्ता "Foo.java" फ़ाइल के बजाय "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub की समस्या #10395 देखें. - ग्लोब, सबडायरेक्ट्री की फ़ाइलों से मेल खा सकता है. साथ ही, सबडायरेक्ट्री के नाम वाइल्डकार्ड हो सकते हैं. हालांकि...
-
लेबल को पैकेज की सीमा पार करने की अनुमति नहीं है और ग्लोब सबपैकेज की फ़ाइलों से मेल नहीं खाता.
उदाहरण के लिए, अगर
x/y
पैकेज के तौर पर (x/y/BUILD
के तौर पर या पैकेज-पाथ पर कहीं और) मौजूद है, तोx
पैकेज में ग्लोब एक्सप्रेशन**/*.cc
मेंx/y/z.cc
शामिल नहीं होता. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा, BUILD फ़ाइलों के मौजूद होने पर निर्भर करता है. इसका मतलब है कि अगरx/y
नाम का कोई पैकेज नहीं था या --deleted_packages फ़्लैग का इस्तेमाल करके, इसे 'मिटाया गया' के तौर पर मार्क किया गया था, तो उसी ग्लोब एक्सप्रेशन मेंx/y/z.cc
शामिल होगा. - ऊपर दी गई पाबंदी सभी ग्लोब एक्सप्रेशन पर लागू होती है. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस वाइल्डकार्ड का इस्तेमाल करते हैं.
-
.
से शुरू होने वाले फ़ाइल नाम वाली छिपी हुई फ़ाइल को**
और*
वाइल्डकार्ड, दोनों से पूरी तरह मैच किया जाता है. अगर आपको किसी छिपी हुई फ़ाइल का मिलान किसी कंपाउंड पैटर्न से करना है, तो पैटर्न की शुरुआत.
से होनी चाहिए. उदाहरण के लिए,*
और.*.txt
,.foo.txt
से मेल खाएंगे, लेकिन*.txt
नहीं. छिपी हुई डायरेक्ट्री भी इसी तरह से मैच की जाती हैं. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें हो सकती हैं जो इनपुट के तौर पर ज़रूरी नहीं हैं. साथ ही, इससे ग़ैर-ज़रूरी फ़ाइलों की संख्या बढ़ सकती है और मेमोरी का इस्तेमाल बढ़ सकता है. छिपी हुई डायरेक्ट्री को शामिल न करने के लिए, उन्हें सूची में मौजूद "बाहर रखें" आर्ग्युमेंट में जोड़ें. -
"**" वाइल्डकार्ड में एक कोने वाला केस होता है:
"**"
पैटर्न, पैकेज के डायरेक्ट्री पाथ से मेल नहीं खाता. इसका मतलब यह है कि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", ], ... )
प्रयोग के तौर पर इस्तेमाल होने वाले.txt को छोड़कर, सभी txt फ़ाइलों को testdata डायरेक्ट्री में शामिल करें. ध्यान दें कि टेस्टडेटा की सबडायरेक्ट्री की फ़ाइलों को शामिल नहीं किया जाएगा. अगर आपको उन फ़ाइलों को शामिल करना है, तो रिकर्सिव ग्लोब (**) का इस्तेमाल करें.
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob( ["testdata/*.txt"], exclude = ["testdata/experimental.txt"], ), )
बार-बार लागू होने वाले ग्लोब के उदाहरण
यह टेस्ट, टेस्ट डेटा डायरेक्ट्री में मौजूद सभी 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()
एक हेल्पर फ़ंक्शन है, जो नियम एट्रिब्यूट को
कॉन्फ़िगर किया जा सकने वाला बनाता है.
यह किसी भी एट्रिब्यूट असाइनमेंट के
करीब
दाएं हिस्से को बदल सकता है. इसलिए, इसकी वैल्यू, कमांड-लाइन बेज़ल फ़्लैग पर निर्भर करती है.
उदाहरण के लिए, इसका इस्तेमाल प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या अलग-अलग रिसॉर्स को एम्बेड करने के लिए किया जा सकता है. यह इस बात पर निर्भर करता है कि नियम "डेवलपर" बनाम "रिलीज़" मोड में बनाया गया है या नहीं.
सामान्य इस्तेमाल के बारे में यहां बताया गया है:
sh_binary( name = "mytarget", srcs = select({ ":conditionA": ["mytarget_a.sh"], ":conditionB": ["mytarget_b.sh"], "//conditions:default": ["mytarget_default.sh"] }) )
इससे
sh_binary
के srcs
एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. इसके लिए,
लेबल की सामान्य सूची के असाइनमेंट को 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)
subpackages()
एक हेल्पर फ़ंक्शन है, जोglob()
की तरह है. यह फ़ाइलों और डायरेक्ट्री के बजाय सबपैकेज की सूची बनाता है. इसमें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 के 'सबपैकेज' मॉड्यूल का इस्तेमाल करें.