विषय सूची
पैकेज
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
यह फ़ंक्शन उस मेटाडेटा की जानकारी देता है जो पैकेज के हर एक नियम पर लागू होता है. पैकेज (BUILD फ़ाइल) में इसका ज़्यादा से ज़्यादा एक बार इस्तेमाल किया जा सकता है.
package() फ़ंक्शन को किसी भी नियम से पहले, फ़ाइल के सबसे ऊपर, सभी index() स्टेटमेंट के ठीक बाद कॉल किया जाना चाहिए.
तर्क
एट्रिब्यूट | जानकारी |
---|---|
default_applicable_licenses |
|
default_visibility |
इस पैकेज में नियमों की डिफ़ॉल्ट दृश्यता. इस पैकेज के हर नियम में, इस एट्रिब्यूट के दिखने की जानकारी दी गई है. हालांकि, इससे पहले |
default_deprecation |
इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट
|
default_package_metadata |
इस नीति से, मेटाडेटा टारगेट की डिफ़ॉल्ट सूची सेट होती है. यह सूची, पैकेज में मौजूद दूसरे सभी टारगेट पर लागू होती है. ये आम तौर पर, ओएसएस पैकेज और लाइसेंस से जुड़े एलानों से जुड़े टारगेट होते हैं. उदाहरण के लिए, नियम_लाइसेंस देखें. |
default_testonly |
इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट
|
features |
इस BUILD फ़ाइल के सिमेंटिक पर असर डालने वाले अलग-अलग फ़्लैग सेट करता है. यह सुविधा मुख्य रूप से, उन लोगों को इस्तेमाल करती है जो बिल्ड सिस्टम पर काम करते हैं. वे ऐसे पैकेज को टैग करते हैं जिन्हें किसी खास तरह की देखरेख की ज़रूरत होती है. यह तब तक इस्तेमाल न करें, जब तक कि बिल्ड सिस्टम पर काम करने वाला कोई व्यक्ति साफ़ तौर पर इसका अनुरोध न करे. |
उदाहरण
नीचे दिए गए एलान में बताया गया है कि इस पैकेज के नियम, सिर्फ़ पैकेज ग्रुप के सदस्यों को दिखते हैं//foo:target
. अगर किसी नियम के लिए 'किसको दिखे' एलान लागू है, तो इस खास जानकारी को बदल दें.
package(default_visibility = ["//foo:target"])
package_group (पैकेज_ग्रुप)
package_group(name, packages, includes)
यह फ़ंक्शन, पैकेज के एक सेट के बारे में बताता है और उस सेट से एक लेबल जोड़ता है. इस लेबल का संदर्भ
visibility
एट्रिब्यूट में दिया जा सकता है.
पैकेज ग्रुप का इस्तेमाल मुख्य तौर पर, विज़िबिलिटी कंट्रोल के लिए किया जाता है. सार्वजनिक रूप से दिखाई देने वाले टारगेट का संदर्भ, सोर्स ट्री के हर पैकेज में दिया जा सकता है. निजी रूप से दिखाई देने वाले टारगेट का संदर्भ सिर्फ़ उसके पैकेज में दिया जा सकता है (सबपैकेज नहीं). इन चरम सीमाओं के बीच में, टारगेट अपने खुद के पैकेज के साथ-साथ एक या ज़्यादा पैकेज ग्रुप में बताए गए किसी भी पैकेज को ऐक्सेस करने की अनुमति दे सकता है. किसको दिखे, इसके बारे में ज़्यादा जानने के लिए, किसको दिखे एट्रिब्यूट देखें.
अगर दिया गया पैकेज packages
एट्रिब्यूट से मेल खाता है या पहले से ही includes
एट्रिब्यूट में बताए गए किसी दूसरे पैकेज ग्रुप में शामिल है, तो माना जाता है कि वह ग्रुप है.
पैकेज ग्रुप तकनीकी रूप से टारगेट होते हैं, लेकिन ये नियमों के हिसाब से नहीं बनाए जाते, और इनमें किसी तरह की सुरक्षा भी नहीं होती.
तर्क
एट्रिब्यूट | जानकारी |
---|---|
name |
इस टारगेट के लिए खास नाम. |
packages |
शून्य या ज़्यादा पैकेज विशेषताओं की एक सूची. पैकेज की खास बातों की हर स्ट्रिंग में, इनमें से कोई एक फ़ॉर्म हो सकता है:
इसके अलावा, पहले दो तरह के पैकेज की खास बातों में पैकेज ग्रुप में ऐसा कोई भी पैकेज शामिल है जो उसके कम से कम एक पॉज़िटिव ब्यौरे से मेल खाता हो और उसका कोई भी नेगेटिव एट्रिब्यूट न हो. उदाहरण के लिए, सार्वजनिक जगहों के दिखने के अलावा, पैकेज को मौजूदा रिपॉज़िटरी से बाहर सीधे तौर पर तय करने का कोई तरीका नहीं है. यह एट्रिब्यूट मौजूद न होने पर, इसे किसी खाली सूची पर सेट किया जाता है.
साथ ही, इसे सिर्फ़ ध्यान दें: Bazel 6.0 से पहले, खास जानकारी ध्यान दें: Bazel 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"], )
Export_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 एक सहायक फ़ंक्शन है, जो खास पाथ पैटर्न से मेल खाने वाली सभी फ़ाइलें ढूंढता है. साथ ही, अपने पाथ की नई, बदली गई, बदली गई सूची दिखाता है. Glob केवल अपने पैकेज में फ़ाइलें खोजता है; और केवल स्रोत फ़ाइलों (न कि जनरेट की गई फ़ाइलें और न ही अन्य लक्ष्य) को खोजता है.
अगर फ़ाइल का पैकेज-रिलेटिव पाथ, include
पैटर्न और किसी भी exclude
पैटर्न से मेल नहीं खाता, तो सोर्स फ़ाइल का लेबल नतीजे में शामिल किया जाता है.
include
और exclude
सूचियों में पाथ के पैटर्न मौजूद हैं, जो मौजूदा पैकेज से जुड़े हैं. हर पैटर्न में एक या ज़्यादा पाथ सेगमेंट हो सकते हैं. हमेशा की तरह, यूनिक्स पाथ के साथ, इन सेगमेंट को /
से अलग किया जाता है. सेगमेंट में *
वाइल्डकार्ड हो सकता है. यह पाथ सेगमेंट में मौजूद किसी भी सबस्ट्रिंग (खाली सबस्ट्रिंग में भी) से मेल खाता है. इसमें डायरेक्ट्री सेपरेटर /
नहीं होता है. इस वाइल्डकार्ड का इस्तेमाल एक पाथ सेगमेंट में
कई बार किया जा सकता है. इसके अलावा, **
वाइल्डकार्ड का शून्य या उससे ज़्यादा पाथ सेगमेंट से मिलान हो सकता है, लेकिन यह एक स्टैंडअलोन पाथ सेगमेंट के तौर पर बताया जाना चाहिए.
foo/bar.txt
इस पैकेज में मौजूदfoo/bar.txt
फ़ाइल से मेल खाता है- अगर फ़ाइल
.txt
से खत्म होती है, तो यहfoo/
डायरेक्ट्री की हर फ़ाइल से मेल खाती है (जब तक किfoo/
एक सब-पैकेज न हो) foo/a*.htm*
,foo/
से जुड़ी हर उस फ़ाइल से मेल खाता है जोa
से शुरू होती है. इसके बाद, आर्बिट्ररी स्ट्रिंग (जो खाली हो सकती है) मौजूद होती है. इसके बाद,.htm
होती है और यह किसी दूसरी आर्बिट्ररी स्ट्रिंग पर खत्म होती है, जैसे किfoo/axx.htm
औरfoo/a.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()
, BUILD फ़ाइल के मूल्यांकन के दौरान चलता है, इसलिएglob()
सिर्फ़ सोर्स ट्री में मौजूद फ़ाइलों से मेल खाता है, लेकिन कभी भी जनरेट की गई फ़ाइलें नहीं. अगर आप कोई ऐसा टारगेट बनाते हैं जिसके लिए सोर्स और जनरेट की गई, दोनों तरह की फ़ाइलों की ज़रूरत होती है, तो आपको जनरेट की गई फ़ाइलों की एक साफ़ सूची, ग्लोब में जोड़नी होगी.:mylib
और:gen_java_srcs
के साथ, नीचे दिया गया उदाहरण देखें. -
अगर किसी नियम का नाम मेल खाने वाली सोर्स फ़ाइल जैसा है, तो नियम फ़ाइल को "शैडो" करेगा.
इसे समझने के लिए, ध्यान रखें कि
glob()
, पाथ की सूची दिखाता है. इसलिए, दूसरे नियमों के एट्रिब्यूट (जैसे,srcs = glob(["*.cc"])
) का इस्तेमाल करने से,glob()
में मेल खाने वाले पाथ की सूची पर असर पड़ता है. अगर उदाहरण के तौर पर,glob()
को["Foo.java", "bar/Baz.java"]
मिलता है, लेकिन "Foo.java" (जिसे बैजल इसके बारे में चेतावनी देता है) पैकेज में भी एक नियम है, तोglob()
का उपभोक्ता "Foo.java" फ़ाइल के बजाय "Foo.java" नियम (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub से जुड़ी समस्या #10395 देखें. - ग्लोब, सबडायरेक्ट्री की फ़ाइलों से मेल खा सकते हैं. सबडायरेक्ट्री के नामों में वाइल्डकार्ड का इस्तेमाल किया जा सकता है. हालांकि...
-
लेबल को पैकेज की सीमा पार करने और ग्लोब की मदद से, सबपैकेज में मौजूद फ़ाइलों से मेल खाने की अनुमति नहीं है.
उदाहरण के लिए, पैकेज
x
में ग्लोब एक्सप्रेशन**/*.cc
मेंx/y/z.cc
को शामिल नहीं किया जाता है, अगरx/y
पैकेज के रूप में (याx/y/BUILD
या पैकेज पाथ पर कहीं और मौजूद है) में शामिल होता है. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा असल में BUILD फ़ाइलों की मौजूदगी पर निर्भर करता है — अगरx/y
नाम का कोई पैकेज नहीं था, तो उसी ग्लोब एक्सप्रेशन मेंx/y/z.cc
को शामिल किया जाएगा या --delete_packages फ़्लैग का इस्तेमाल करके, उसे 'मिटाया गया' के तौर पर मार्क किया गया था. - ऊपर दी गई पाबंदी सभी ग्लोब एक्सप्रेशन पर लागू होती है. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस वाइल्डकार्ड का इस्तेमाल करते हैं.
-
.
से शुरू होने वाली, फ़ाइल नाम वाली छिपी हुई फ़ाइल का**
और*
वाइल्डकार्ड, दोनों से पूरी तरह मिलान किया जाता है. अगर आपको किसी छिपी हुई फ़ाइल का कंपाउंड पैटर्न बनाना है, तो आपका पैटर्न.
से शुरू होना चाहिए. उदाहरण के लिए,*
और.*.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", ], ... )
experiment.txt को छोड़कर, डायरेक्ट्री की जांच के डेटा में सभी txt फ़ाइलें शामिल करें. ध्यान दें कि टेस्ट डेटा की सबडायरेक्ट्री में मौजूद फ़ाइलें शामिल नहीं की जाएंगी. उन फ़ाइलों को शामिल करने के लिए, बार-बार दोहराए जाने वाले ग्लोब (**) का इस्तेमाल करें.
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob( ["testdata/*.txt"], exclude = ["testdata/experimental.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
एट्रिब्यूट को कॉन्फ़िगर करने लायक बना दिया जाता है. इसके लिए, srcs
को सामान्य लेबल
असाइन करने की जगह select
कॉल से बदल दिया जाता है.
यह कॉन्फ़िगरेशन की शर्तों को मेल खाने वाली वैल्यू के साथ मैप करता है. हर शर्त
config_setting
या
constraint_value
का एक लेबल रेफ़रंस होता है,
जो टारगेट की कॉन्फ़िगरेशन के
वैल्यू के होने पर, टारगेट के कॉन्फ़िगरेशन से मेल खाता है. इसके बाद, mytarget#srcs
की वैल्यू उस
लेबल की सूची बन जाती है जो मौजूदा वर्शन से मेल खाता है.
ध्यान दें:
- शुरू करने के किसी भी न्योते पर सिर्फ़ एक शर्त चुनी जाती है.
- अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त अन्य की विशेषज्ञता है, तो विशेषज्ञता को प्राथमिकता दी जाती है. शर्त B को स्थिति A की विशेषज्ञता माना जाता है. ऐसा तब होता है, जब B में सभी फ़्लैग और कंस्ट्रेंट वैल्यू, A के तौर पर एक जैसी हों. साथ ही, इसमें कुछ दूसरे फ़्लैग या कंस्ट्रेंट वैल्यू भी शामिल हों. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को ऑर्डर करने के लिए नहीं बनाया गया है, जैसा कि नीचे उदाहरण 2 में दिखाया गया है.
- अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त अन्य सभी के लिए विशेषज्ञता नहीं है, तो बेज़ल किसी गड़बड़ी के साथ काम नहीं करेगा. ऐसा तब तक होगा, जब तक सभी शर्तें एक ही वैल्यू के लिए ठीक नहीं हो जातीं.
- अगर कोई दूसरी शर्त मेल नहीं खाती है, तो खास स्यूडो-लेबल
//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/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 के 'सबपैकेज' मॉड्यूल का इस्तेमाल करें.