कॉन्टेंट
- पैकेज
- package_group (पैकेज_ग्रुप)
- exports_files
- ग्लोब
- चुनें
- सब-पैकेज
पैकेज
package(default_deprecation, default_testonly, default_visibility, features)
यह फ़ंक्शन उस मेटाडेटा के बारे में बताता है जो पैकेज के बाद के हर नियम पर लागू होता है. इसका इस्तेमाल किसी पैकेज (BUILD फ़ाइल) में ज़्यादा से ज़्यादा एक बार किया जाता है.
किसी भी नियम से पहले, package() फ़ंक्शन को फ़ाइल के सबसे ऊपर, load() स्टेटमेंट के ठीक बाद कॉल किया जाना चाहिए.
तर्क
एट्रिब्यूट | जानकारी |
---|---|
default_visibility |
इस पैकेज के नियमों की डिफ़ॉल्ट दृश्यता. इस पैकेज के हर नियम में, 'किसको दिखे' इस एट्रिब्यूट में दिया गया है. ऐसा तब तक होगा, जब तक नियम के |
default_deprecation |
इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट
|
default_testonly |
इस पैकेज में सभी नियमों के लिए, डिफ़ॉल्ट
|
features |
इस BUILD फ़ाइल के अर्थशास्त्र को प्रभावित करने वाले विभिन्न फ़्लैग सेट करता है. यह सुविधा मुख्य रूप से बिल्ड सिस्टम पर काम करने वाले लोग, उन पैकेज को टैग करने के लिए करते हैं जिन्हें किसी खास हैंडलिंग की ज़रूरत होती है. इसका इस्तेमाल तब तक न करें, जब तक कि बिल्ड सिस्टम पर काम करने वाले किसी व्यक्ति ने साफ़ तौर पर इसका अनुरोध न किया हो. |
उदाहरण
यहां दिए गए एलान में बताया गया है कि इस पैकेज के नियम, सिर्फ़//foo:target
ग्रुप ग्रुप के सदस्यों को दिखते हैं. अगर किसी नियम के लिए, विज़िबिलिटी से जुड़े एलान की जानकारी दी गई है, तो इस खास जानकारी को बदलें.
package(default_visibility = ["//foo:target"])
package_group (पैकेज_ग्रुप)
package_group(name, packages, includes)
यह फ़ंक्शन पैकेज के एक सेट के बारे में बताता है और उस सेट के साथ एक लेबल जोड़ता है. इस लेबल का संदर्भ visibility
एट्रिब्यूट में दिया जा सकता है.
पैकेज ग्रुप का इस्तेमाल मुख्य तौर पर विज़िबिलिटी कंट्रोल के लिए किया जाता है. सार्वजनिक तौर पर दिखने वाले टारगेट को, सोर्स ट्री के हर पैकेज से रेफ़र किया जा सकता है. निजी रूप से दिखने वाले टारगेट का रेफ़रंस सिर्फ़ उसके पैकेज में दिया जा सकता है (सब-पैकेज नहीं) इन सीमाओं के बीच, टारगेट अपने खुद के पैकेज और ऐसे किसी भी पैकेज को ऐक्सेस कर सकता है जिसके बारे में एक या ज़्यादा पैकेज ग्रुप ने बताया हो. विज़िबिलिटी सिस्टम के बारे में ज़्यादा जानकारी के लिए, विज़िबिलिटी एट्रिब्यूट देखें.
अगर दिया गया पैकेज packages
एट्रिब्यूट से मेल खाता है या पहले से ही includes
एट्रिब्यूट में बताए गए किसी दूसरे पैकेज ग्रुप में शामिल है, तो उसे ग्रुप में शामिल माना जाता है.
पैकेज ग्रुप तकनीकी रूप से टारगेट होते हैं, लेकिन वे नियमों से नहीं बनाए जाते. साथ ही, इनसे किसी भी तरह की दृश्यता सुरक्षा नहीं मिलती है.
तर्क
एट्रिब्यूट | जानकारी |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
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
फ़ंक्शन में गड़बड़ी दिखेगी.
हालांकि, इससे जुड़ी कुछ ज़रूरी सीमाएं हैं:
-
glob()
, BUILD फ़ाइल के आकलन के दौरान चलता है. इसलिए,glob()
का मिलान सिर्फ़ आपके सोर्स ट्री में मौजूद फ़ाइलों से होता है, कभी भी जनरेट की गई फ़ाइलों से नहीं. अगर आपने कोई ऐसा टारगेट बनाया है जिसमें सोर्स और जनरेट की गई फ़ाइल, दोनों की ज़रूरत हो, तो आपको ग्लोब में जनरेट की गई फ़ाइलों की एक साफ़ सूची जोड़नी होगी.:mylib
और:gen_java_srcs
के नीचे उदाहरण देखें. -
अगर किसी नियम का नाम मेल खाने वाले सोर्स फ़ाइल जैसा है, तो वह नियम फ़ाइल को शैडो और कोट करेगा.
इसे समझने के लिए, याद रखें कि
glob()
पाथ की एक सूची दिखाता है. इसलिए, दूसरे नियमों और #39 (उदाहरण के लिए,srcs = glob(["*.cc"])
) मेंglob()
का इस्तेमाल करने पर, मेल खाने वाले पाथ की जानकारी साफ़ तौर पर मिलती है. उदाहरण के लिए, अगरglob()
,["Foo.java", "bar/Baz.java"]
दिखाता है, लेकिन "Foo.java" (जिसकी अनुमति है, लेकिन बेज़ल इसके बारे में चेतावनी देता है) पैकेज में एक नियम भी है, तोglob()
का उपभोक्ता, &FootJava.quot; फ़ाइल के बजाय "Foo.java" आउटपुट (इसके आउटपुट) का इस्तेमाल करेगा. ज़्यादा जानकारी के लिए, GitHub समस्या #10395 देखें. - ग्लोब, सबडायरेक्ट्री में मौजूद फ़ाइलों से मेल खा सकते हैं. साथ ही, सबडायरेक्ट्री के नामों में वाइल्डकार्ड हो सकते हैं. हालांकि...
-
लेबल को पैकेज की सीमा को पार करने और ग्लोब में सब पैकेज से फ़ाइलों का मिलान करने की अनुमति नहीं है.
उदाहरण के लिए, पैकेज
x
में ग्लोब एक्सप्रेशन**/*.cc
में,x/y/z.cc
को शामिल नहीं किया जाता, अगरx/y
पैकेज के रूप में (x/y/BUILD
के तौर पर या पैकेज पाथ पर कहीं और मौजूद है). इसका मतलब यह है कि ग्लोब एक्सप्रेशन का नतीजा असल में BLILD फ़ाइलों के मौजूद होने पर निर्भर करता है. इसका मतलब है कि अगरx/y
कोई पैकेज नहीं है या --deleted_packages फ़्लैग का इस्तेमाल करके इसे 'मिटाया गया' के तौर पर मार्क किया गया है, तो ग्लोब एक्सप्रेशनx/y/z.cc
शामिल होगा. - ऊपर बताई गई पाबंदी सभी ग्लोब एक्सप्रेशन पर लागू होती है, चाहे वे किसी भी वाइल्डकार्ड का इस्तेमाल करते हों.
-
.
से शुरू होने वाली, फ़ाइल के नाम वाली छिपी हुई फ़ाइल,**
और*
वाइल्डकार्ड, दोनों से पूरी तरह मेल खाती है. अगर आपको किसी छिपी हुई फ़ाइल को किसी कंपाउंड पैटर्न के साथ देखना है, तो पैटर्न को.
से शुरू करना होगा. उदाहरण के लिए,*
और.*.txt
का मिलान.foo.txt
से होगा, लेकिन*.txt
का मिलान नहीं होगा. छिपी हुई डायरेक्ट्री का भी इसी तरह से मिलान होता है. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें शामिल हो सकती हैं जिनकी इनपुट के तौर पर ज़रूरत नहीं हो. इससे, गै़र-ज़रूरी फ़ाइलें अपने-आप मिट जाती हैं और उनकी मेमोरी बढ़ जाती है. छिपी हुई डायरेक्ट्री हटाने के लिए, उन्हें "excluded" लिस्ट आर्ग्युमेंट में जोड़ें. -
"**" वाइल्डकार्ड का एक कॉर्नर केस है:
"**"
पैटर्न, पैकेज के डायरेक्ट्री पाथ से मेल नहीं खाता. इसका मतलब यह है किglob(["**"], exclude_directories = 0)
मौजूदा पैकेज की डायरेक्ट्री में समय-समय पर दी जाने वाली सभी फ़ाइलों और डायरेक्ट्री से मेल खाता है. हालांकि, पैकेज की डायरेक्ट्री में सब-प्रॉपर्टी का इस्तेमाल नहीं किया जाता है. पिछली डायरेक्ट्री देखें.
आम तौर पर, किसी ग्लब पैटर्न के लिए नंगे और #39;*' का इस्तेमाल करने के बजाय, आपको सही एक्सटेंशन देने की कोशिश करनी चाहिए (जैसे कि *.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 फ़ाइलें शामिल करें. ध्यान रखें कि टेस्ट डेटा की सबडायरेक्ट्री की फ़ाइलें शामिल नहीं की जाएंगी. अगर आप उन फ़ाइलों को शामिल करना चाहते हैं, तो दोहराए जाने वाले ग्लोब (**) का इस्तेमाल करें.
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/**"], ), )
बड़ा किए गए Glob के उदाहरण
अपनी मौजूदा डायरेक्ट्री में *_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()
एक हेल्पर फ़ंक्शन है, जो नियम वाले एट्रिब्यूट को
कॉन्फ़िगर किया जा सकता है.
यह किसी भी एट्रिब्यूट असाइनमेंट के
करीब
दाईं ओर बदल सकता है, इसलिए इसका मान कमांड-लाइन बेज़ल फ़्लैग पर निर्भर करता है.
उदाहरण के लिए, आप इसका इस्तेमाल प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या अलग-अलग रिसॉर्स को जोड़ने के लिए कर सकते हैं. यह इस बात पर निर्भर करता है कि नियम "developer"
बनाम बनाम "release" मोड में बनाया गया है या नहीं.
बुनियादी इस्तेमाल इस तरह है:
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 और कुछ फ़्लैग या कंस्ट्रेंट वैल्यू होती हैं. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को ऑर्डर करने के लिए नहीं बनाया गया है, जैसा कि नीचे उदाहरण 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 के मॉड्यूल के साथ #39;subpackages और#39 का इस्तेमाल करें.