कॉन्टेंट
पैकेज
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
यह फ़ंक्शन, पैकेज के हर नियम पर लागू होने वाले मेटाडेटा के बारे में बताता है. किसी पैकेज (BUILD फ़ाइल) में इसका इस्तेमाल ज़्यादा से ज़्यादा एक बार किया जा सकता है.
पूरे रिपॉज़िटरी के हर नियम पर लागू होने वाले मेटाडेटा के लिए, अपने रिपॉज़िटरी के रूट में मौजूद REPO.bazel
फ़ाइल में repo()
फ़ंक्शन का इस्तेमाल करें.
repo()
फ़ंक्शन, package()
फ़ंक्शन के जैसे ही आर्ग्युमेंट लेता है.
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
एट्रिब्यूट में दिया जा सकता है.
पैकेज ग्रुप का इस्तेमाल मुख्य रूप से, 'किसको दिखे' सेटिंग कंट्रोल के लिए किया जाता है. सोर्स ट्री में मौजूद हर पैकेज से, सार्वजनिक तौर पर दिखने वाले टारगेट का रेफ़रंस दिया जा सकता है. निजी तौर पर दिखने वाले टारगेट का रेफ़रंस सिर्फ़ उसके खुद के पैकेज (सबपैकेज नहीं) में दिया जा सकता है. इन दोनों स्थितियों के बीच, टारगेट अपने पैकेज के साथ-साथ, एक या उससे ज़्यादा पैकेज ग्रुप के बताए गए किसी भी पैकेज का ऐक्सेस दे सकता है. 'किसको दिखे' सेटिंग के बारे में ज़्यादा जानकारी के लिए, visibility एट्रिब्यूट देखें.
किसी पैकेज को ग्रुप में तब शामिल माना जाता है, जब वह packages
एट्रिब्यूट से मैच करता हो या includes
एट्रिब्यूट में बताए गए किसी अन्य पैकेज ग्रुप में पहले से शामिल हो.
तकनीकी तौर पर, पैकेज ग्रुप को टारगेट किया जाता है. हालांकि, वे नियमों के हिसाब से नहीं बनाए जाते. साथ ही, पैकेज ग्रुप के लिए 'किसको दिखे' सेटिंग भी नहीं होती.
तर्क
एट्रिब्यूट | ब्यौरा |
---|---|
name |
नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम. |
packages |
स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से शून्य या उससे ज़्यादा पैकेज के बारे में खास जानकारी की सूची. पैकेज की जानकारी देने वाली हर स्ट्रिंग, इनमें से किसी एक तरह की हो सकती है:
इसके अलावा, पैकेज के पहले दो तरह के स्पेसिफ़िकेशन के शुरू में भी पैकेज ग्रुप में ऐसा कोई भी पैकेज शामिल होता है जो कम से कम किसी एक
पॉज़िटिव स्पेसिफ़िकेशन से मेल खाता हो और किसी भी नेगेटिव स्पेसिफ़िकेशन से मेल न खाता हो.
उदाहरण के लिए, वैल्यू सार्वजनिक तौर पर दिखने के अलावा, डेटा स्टोर करने की मौजूदा जगह के बाहर के पैकेज के बारे में सीधे तौर पर बताने का कोई तरीका नहीं है. अगर यह एट्रिब्यूट मौजूद नहीं है, तो यह इसे खाली सूची पर सेट करने जैसा ही है. इसका मतलब इसे सिर्फ़ ध्यान दें: Bazel 6.0 से पहले, ध्यान दें: Basel 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
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
फ़ंक्शन गड़बड़ी दिखाएगा. ऐसा तब होगा, जब नतीजा खाली सूची होगा.
इस सुविधा में कुछ ज़रूरी सीमाएं और सावधानियां हैं:
-
glob()
, बिल्ड फ़ाइल की जांच के दौरान चलता है. इसलिए,glob()
, सिर्फ़ आपके सोर्स ट्री की फ़ाइलों को मैच करता है, कभी जनरेट नहीं की गई फ़ाइलें. अगर आपको ऐसा टारगेट बनाना है जिसके लिए सोर्स और जनरेट की गई फ़ाइलों, दोनों की ज़रूरत है, तो आपको जनरेट की गई फ़ाइलों की एक अलग सूची को ग्लोब में जोड़ना होगा.:mylib
और:gen_java_srcs
के साथ नीचे दिया गया उदाहरण देखें. -
अगर किसी नियम का नाम और मेल खाने वाली सोर्स फ़ाइल का नाम एक ही है, तो यह नियम फ़ाइल को "शैडो" कर देगा.
इसे समझने के लिए, याद रखें कि
glob()
, पाथ की सूची दिखाता है. इसलिए, दूसरे नियमों के एट्रिब्यूट (जैसे,srcs = glob(["*.cc"])
) मेंglob()
का इस्तेमाल करने से, मेल खाने वाले पाथ की सटीक जानकारी देने जैसा ही असर पड़ता है. उदाहरण के लिए, अगरglob()
से["Foo.java", "bar/Baz.java"]
मिलता है, लेकिन पैकेज में "Foo.java" नाम का एक नियम भी है (इसकी अनुमति है, हालांकि Bazel इसके बारे में चेतावनी देता है), तोglob()
का इस्तेमाल करने वाला व्यक्ति "Foo.java" फ़ाइल के बजाय, "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub की समस्या #10395 देखें. - ग्लोब, सबडायरेक्ट्री में मौजूद फ़ाइलों से मेल खा सकते हैं. साथ ही, सबडायरेक्ट्री के नाम वाइल्डकार्ड हो सकते हैं. हालांकि...
-
लेबल, पैकेज की सीमा से बाहर नहीं जा सकते और ग्लोब, सबपैकेज में मौजूद फ़ाइलों से मैच नहीं करता.
उदाहरण के लिए, अगर
x/y
पैकेज के तौर पर मौजूद है, तो पैकेजx
में ग्लोब एक्सप्रेशन**/*.cc
मेंx/y/z.cc
शामिल नहीं होता. पैकेजx/y
,x/y/BUILD
के तौर पर या पैकेज-पाथ पर कहीं और मौजूद हो सकता है. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा, 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 डायरेक्ट्री में शामिल करें. ध्यान दें कि 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 के लिए एक अलग 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()
एक हेल्पर फ़ंक्शन है, जो नियम एट्रिब्यूट को कॉन्फ़िगर करने लायक बनाता है.
यह किसी भी एट्रिब्यूट असाइनमेंट के
करीब
दाएं हिस्से को बदल सकता है. इसलिए, इसकी वैल्यू, कमांड-लाइन बेज़ल फ़्लैग पर निर्भर करती है.
उदाहरण के लिए, इसका इस्तेमाल प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या अलग-अलग रिसॉर्स को एम्बेड करने के लिए किया जा सकता है. यह इस बात पर निर्भर करता है कि नियम "डेवलपर" बनाम "रिलीज़" मोड में बनाया गया है या नहीं.
इसका बुनियादी इस्तेमाल इस तरह किया जाता है:
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 के सभी फ़्लैग और पाबंदी की वैल्यू के साथ-साथ कुछ अतिरिक्त फ़्लैग या पाबंदी की वैल्यू भी हों. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को ऑर्डर बनाने के लिए डिज़ाइन नहीं किया गया है, जैसा कि दूसरे उदाहरण में बताया गया है.
- अगर कई शर्तें मैच करती हैं और कोई एक शर्त, बाकी सभी शर्तों की विशेषता नहीं है, तो Bazel गड़बड़ी का मैसेज दिखाता है. ऐसा तब तक होता रहेगा, जब तक सभी शर्तें एक ही वैल्यू पर न पहुंच जाएं.
- अगर कोई दूसरी शर्त मैच नहीं होती है, तो खास स्यूडो-लेबल
//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 फ़ाइल का ही है. शामिल करने और बाहर रखने के पैटर्न के बारे में ज़्यादा जानकारी और उदाहरणों के लिए, glob देखें.दिखाए गए सबपैकेज की सूची, क्रम से लगी है. इसमें लोड होने वाले मौजूदा पैकेज के पाथ शामिल हैं. ये पाथ,
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 के 'सब-पैकेज' मॉड्यूल का इस्तेमाल करना चाहिए.