.bzl फ़ाइलें

समस्या की शिकायत करें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

सभी .bzl फ़ाइलों में ग्लोबल तरीके उपलब्ध हैं.

सदस्य

analysis_test_transition

transition analysis_test_transition(settings)

विश्लेषण-टेस्ट नियम की डिपेंडेंसी पर लागू होने के लिए, कॉन्फ़िगरेशन ट्रांज़िशन बनाता है. यह ट्रांज़िशन, सिर्फ़ analysis_test = True वाले नियमों के एट्रिब्यूट पर लागू हो सकता है. इस तरह के नियमों पर, क्षमताओं के हिसाब से पाबंदी लगी होती है. उदाहरण के लिए, उनके डिपेंडेंसी ट्री का साइज़ सीमित होता है. इसलिए, transition() का इस्तेमाल करके बनाए गए ट्रांज़िशन की तुलना में, इस फ़ंक्शन का इस्तेमाल करके बनाए गए ट्रांज़िशन सीमित होते हैं.

इस फ़ंक्शन को मुख्य रूप से Analysis Test Framework की मुख्य लाइब्रेरी को आसान बनाने के लिए डिज़ाइन किया गया है. सबसे सही तरीके जानने के लिए, इसका दस्तावेज़ या इसे लागू करने का तरीका देखें.

पैरामीटर

पैरामीटर ब्यौरा
settings ज़रूरी है
यह एक डिक्शनरी है, जिसमें कॉन्फ़िगरेशन सेटिंग के बारे में जानकारी होती है. इस कॉन्फ़िगरेशन ट्रांज़िशन से, इन सेटिंग को सेट किया जाना चाहिए. कुंजियां, बिल्ड सेटिंग लेबल हैं और वैल्यू उनके नए पोस्ट-ट्रांज़िशन वैल्यू हैं. अन्य सभी सेटिंग में कोई बदलाव नहीं होगा. इसका इस्तेमाल, उन खास कॉन्फ़िगरेशन सेटिंग को बताने के लिए करें जिन्हें विश्लेषण टेस्ट पास करने के लिए सेट करना ज़रूरी है.

आसपेक्ट

Aspect aspect(implementation, attr_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])

नया आसपेक्ट रेशियो बनाता है. इस फ़ंक्शन के नतीजे को ग्लोबल वैल्यू में स्टोर किया जाना चाहिए. ज़्यादा जानकारी के लिए, आसपेक्ट के बारे में जानकारी देखें.

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
यह एक Starlark फ़ंक्शन है, जो इस ऐस्पेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: टारगेट (वह टारगेट जिस पर ऐस्पेक्ट लागू किया जाता है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया जाता है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. इस फ़ंक्शन का आकलन, विश्लेषण के दौरान हर पहलू को लागू करने के लिए किया जाता है.
attr_aspects स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से []
होता है एट्रिब्यूट के नामों की सूची. यह पहलू इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के हिसाब से लागू होता है. यहां सामान्य वैल्यू में deps और exports शामिल हैं. सूची में एक स्ट्रिंग "*" भी शामिल हो सकती है, ताकि किसी टारगेट की सभी डिपेंडेंसी के साथ प्रॉपेगेट किया जा सके.
attrs शब्दकोश; डिफ़ॉल्ट रूप से {}
एक शब्दकोश है जो आसपेक्ट की सभी विशेषताओं के बारे में बताता है. यह एट्रिब्यूट के नाम से, एट्रिब्यूट ऑब्जेक्ट पर मैप होता है, जैसे कि `attr.label` या `attr.string` (attr मॉड्यूल देखें). आसपेक्ट एट्रिब्यूट, ctx पैरामीटर के फ़ील्ड के तौर पर लागू करने के लिए उपलब्ध हैं.

_ से शुरू होने वाले इनपुट एट्रिब्यूट की डिफ़ॉल्ट वैल्यू होनी चाहिए. साथ ही, इनका टाइप label या label_list होना चाहिए.

एक्सप्लिसिट एट्रिब्यूट के लिए string टाइप का होना ज़रूरी है. साथ ही, इनके लिए values पाबंदी का इस्तेमाल किया जाना चाहिए. साफ़ तौर पर बताए गए एट्रिब्यूट, ऐसेपेक्ट को सिर्फ़ उन नियमों के साथ इस्तेमाल करने की पाबंदी लगाते हैं जिनमें पाबंदी के हिसाब से एक ही नाम, टाइप, और मान्य वैल्यू वाले एट्रिब्यूट हों.

required_providers यह एट्रिब्यूट डिफ़ॉल्ट रूप से [] पर सेट होता है
यह एट्रिब्यूट, सिर्फ़ उन टारगेट को लागू करने की अनुमति देता है जिनके नियम, सेवा देने वाली ज़रूरी कंपनियों के लिए विज्ञापन दिखाते हैं. वैल्यू ऐसी सूची होनी चाहिए जिसमें अलग-अलग कंपनियों या कंपनियों की सूचियां हों, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.

बिना नेस्ट की गई सेवा देने वाली कंपनियों की सूची, अपने-आप सूची में बदल जाएगी. इसमें, सेवा देने वाली कंपनियों की एक सूची होगी. इसका मतलब है कि [FooInfo, BarInfo] अपने-आप [[FooInfo, BarInfo]] में बदल जाएगा.

किसी नियम (उदाहरण के लिए, some_rule) को किसी पहलू के लिए टारगेट के तौर पर दिखाने के लिए, some_rule को सेवा देने वाली कम से कम एक ज़रूरी सूची में शामिल सभी कंपनियों का विज्ञापन दिखाना होगा. उदाहरण के लिए, अगर किसी आसपेक्ट का required_providers [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] है, तो इस पहलू को some_rule टारगेट तब दिखेंगे, जब some_rule, FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों उपलब्ध कराता हो.

required_aspect_providers डिफ़ॉल्ट तौर पर []
है इस एट्रिब्यूट की मदद से, इस पहलू को दूसरे पहलुओं की जांच करने की अनुमति मिलती है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.

नेस्ट नहीं की गई सेवा देने वाली कंपनियों की सूची, अपने-आप एक सूची में बदल जाएगी. इसका मतलब है कि [FooInfo, BarInfo] की सदस्यता, [[FooInfo, BarInfo]] की सदस्यता में अपने-आप बदल जाएगी.

इस पहलू के किसी दूसरे पहलू (जैसे कि other_aspect) को दिखाने के लिए, other_aspect को कम से कम एक सूची में से सेवा देने वाली सभी कंपनियों की जानकारी देनी होगी. [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] के उदाहरण में, इस पहलू को other_aspect तब ही दिखेगा, जब other_aspect से FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों मिले हों.

provides डिफ़ॉल्ट तौर पर []
सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए.

अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं.

सूची का हर एलिमेंट, provider() से मिला एक *Info ऑब्जेक्ट है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के टारगेट का इस्तेमाल, किसी ऐसे टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है जो ज़रूरी कंपनी के बारे में बताता है, तो यहां उस प्रोवाइडर के बारे में बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसे इस्तेमाल करना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, आसपेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी होता है.

requires ऐस्पेक्ट का क्रम; डिफ़ॉल्ट रूप से []
होता है इस ऐस्पेक्ट से पहले, प्रॉपगेट किए जाने वाले ऐस्पेक्ट की सूची.
fragments string का क्रम; यह डिफ़ॉल्ट रूप से []
उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी ज़रूरत टारगेट कॉन्फ़िगरेशन के लिए होती है.
host_fragments string का क्रम; यह डिफ़ॉल्ट रूप से []
कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची है जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन के लिए होती है.
toolchains क्रम; डिफ़ॉल्ट तौर पर []
सेट होता है. अगर यह सेट है, तो इस नियम के लिए ज़रूरी टूलचेन के सेट का इस्तेमाल किया जाता है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, इसे ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराया जाएगा.
incompatible_use_toolchain_transition यह डिफ़ॉल्ट रूप से False पर सेट है
यह काम नहीं करता है. अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए.
doc string; या None; डिफ़ॉल्ट तौर पर यह None
होता है. इससे दस्तावेज़ जनरेट करने वाले टूल की मदद से तैयार किए गए पहलू के बारे में जानकारी मिलती है.
apply_to_generating_rules यह डिफ़ॉल्ट तौर पर False पर सेट होती है
अगर सही है, तो आसपेक्ट रेशियो को आउटपुट फ़ाइल पर लागू करने के बजाय, आउटपुट फ़ाइल के जनरेट करने के नियम पर लागू होगा.

उदाहरण के लिए, मान लें कि कोई एस्पेक्ट, एट्रिब्यूट `deps` के ज़रिए ट्रांज़िटिव तौर पर प्रसारित होता है और इसे टारगेट `alpha` पर लागू किया जाता है. मान लें कि `alpha` में `deps = [':beta_output']` है, जहां `beta_output` टारगेट `beta` का एलान किया गया आउटपुट है. मान लें कि `beta` में, `deps` में से एक टारगेट `charlie` है. अगर एस्पेक्ट के लिए `apply_to_generating_rules=True` है, तो एस्पेक्ट `alpha`, `beta`, और `charlie` के ज़रिए प्रसारित होगा. अगर यह False है, तो एस्पेक्ट सिर्फ़ `alpha` पर प्रसारित होगा.

डिफ़ॉल्ट रूप से गलत.
exec_compatible_with स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से []
होता है इस एस्पेक्ट के सभी इंस्टेंस पर लागू होने वाले, एक्सीक्यूशन प्लैटफ़ॉर्म की पाबंदियों की सूची.
exec_groups dict या None; डिफ़ॉल्ट तौर पर None
एक डिक्शनरी, जिसमें एक्सीक्यूशन ग्रुप का नाम (स्ट्रिंग) exec_groups में बदला जाता है. अगर नीति सेट की जाती है, तो इससे डाइमेंशन को एक ही इंस्टेंस में, इसे लागू करने वाले कई प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्सीक्यूशन ग्रुप का दस्तावेज़ देखें.
subrules सबनियम का क्रम; डिफ़ॉल्ट रूप से []
होता है एक्सपेरिमेंटल: इस एस्पेक्ट में इस्तेमाल किए गए सबनियमों की सूची.

configuration_field

LateBoundDefault configuration_field(fragment, name)

label टाइप के एट्रिब्यूट के लिए, लेट-बाउंड की गई डिफ़ॉल्ट वैल्यू का रेफ़रंस देता है. अगर किसी वैल्यू के लिए वैल्यू तय करने से पहले कॉन्फ़िगरेशन बनाने की ज़रूरत होती है, तो उसे 'देर से तय सीमा' माना जाता है. वैल्यू के तौर पर इसका इस्तेमाल करने वाला कोई भी एट्रिब्यूट निजी होना चाहिए.

इस्तेमाल का उदाहरण:

नियम के एट्रिब्यूट तय करें: 

'_foo': attr.label(default=configuration_field(fragment='java', name='toolchain'))

नियम लागू करने के दौरान ऐक्सेस करना: 

  def _rule_impl(ctx):
    foo_info = ctx.attr._foo
    ...

पैरामीटर

पैरामीटर ब्यौरा
fragment ज़रूरी है
कॉन्फ़िगरेशन फ़्रैगमेंट का नाम, जिसमें लेट-बाउंड वैल्यू शामिल है.
name ज़रूरी है
कॉन्फ़िगरेशन फ़्रैगमेंट से मिलने वाली वैल्यू का नाम.

Depset

depset depset(direct=None, order="default", *, transitive=None)

depset बनाता है. direct पैरामीटर, डेप्सेट के डायरेक्ट एलिमेंट की सूची है. वहीं, transitive पैरामीटर उन डिपसेट की सूची है जिनके एलिमेंट, बनाए गए डिप्सेट के इनडायरेक्ट एलिमेंट बन जाते हैं. डिप्सेट को सूची में बदलने पर, एलिमेंट किस क्रम में दिखाए जाते हैं, यह order पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, डिपसेट से जुड़ी खास जानकारी देखें.

किसी डेपसेट के सभी एलिमेंट (डायरेक्ट और इनडायरेक्ट) एक ही तरह के होने चाहिए, जैसा कि एक्सप्रेशन type(x) से मिलता है.

हैश पर आधारित सेट का इस्तेमाल, इटरेशन के दौरान डुप्लीकेट को हटाने के लिए किया जाता है. इसलिए, डिप्सेट के सभी एलिमेंट हैश होने चाहिए. हालांकि, फ़िलहाल सभी कन्स्ट्रक्टर में इस इनवैरिएंट की जांच लगातार नहीं की जाती. लगातार जांच करने की सुविधा चालू करने के लिए, --incompatible_always_check_depset_elements फ़्लैग का इस्तेमाल करें. आने वाले समय में रिलीज़ होने वाले वर्शन में, यह सुविधा डिफ़ॉल्ट रूप से चालू रहेगी. समस्या 10313 देखें.

इसके अलावा, फ़िलहाल एलिमेंट में बदलाव नहीं किया जा सकता. हालांकि, आने वाले समय में इस पाबंदी को हटा दिया जाएगा.

बनाए गए डेपसेट का क्रम, उसके transitive डेपसेट के क्रम के साथ काम करना चाहिए. "default" ऑर्डर किसी भी दूसरे ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर सिर्फ़ अपने ऑर्डर के साथ काम करते हैं.

पैरामीटर

पैरामीटर ब्यौरा
direct सीक्वेंस या None; डिफ़ॉल्ट रूप से None
डिप्सेट के डायरेक्ट एलिमेंट की सूची होती है.
order डिफ़ॉल्ट तौर पर, यह "default"
होता है नए डेपसेट के लिए ट्रैवर्सल की रणनीति. संभावित वैल्यू के लिए, यहां देखें.
transitive depset का sequence या None; डिफ़ॉल्ट तौर पर None
उन depset की सूची जिनके एलिमेंट, depset के इनडायरेक्ट एलिमेंट बन जाएंगे.

exec_group

exec_group exec_group(toolchains=[], exec_compatible_with=[])

एक्सीक्यूशन ग्रुप बनाता है. इसका इस्तेमाल, नियम लागू करने के दौरान किसी खास एक्सीक्यूशन प्लैटफ़ॉर्म के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.

पैरामीटर

पैरामीटर ब्यौरा
toolchains क्रम; डिफ़ॉल्ट तौर पर []
टूलचेन का वह सेट है जिसके लिए इस एक्ज़ीक्यूशन ग्रुप की ज़रूरत होती है. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं.
exec_compatible_with स्ट्रिंग का क्रम; डिफ़ॉल्ट तौर पर []
होता है यह, लागू करने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है.

module_extension

unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)

नया मॉड्यूल एक्सटेंशन बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे use_extension के साथ MODULE.baकोई फ़ाइल में एक्सपोर्ट और इस्तेमाल किया जा सके.

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी
यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर, module_ctx होना चाहिए. उपलब्ध रिपॉज़िटरी का सेट तय करने के लिए, फ़ंक्शन को बिल्ड की शुरुआत में एक बार कॉल किया जाता है.
tag_classes {} डिफ़ॉल्ट है
एक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास के बारे में जानकारी देने के लिए एक डिक्शनरी. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट पर मैप करता है.
doc स्ट्रिंग या None; डिफ़ॉल्ट None
मॉड्यूल एक्सटेंशन की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.
environ स्ट्रिंग का क्रम; डिफ़ॉल्ट तौर पर []
होता है इस एनवायरमेंट वैरिएबल की सूची उपलब्ध कराता है जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में किसी एनवायरमेंट वैरिएबल में बदलाव होता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.
os_dependent डिफ़ॉल्ट तौर पर False है
इससे पता चलता है कि यह एक्सटेंशन, ओएस पर निर्भर है या नहीं
arch_dependent डिफ़ॉल्ट False
है इससे पता चलता है कि यह एक्सटेंशन, आर्किटेक्चर पर निर्भर है या नहीं

provider

unknown provider(doc=None, *, fields=None, init=None)

सेवा देने वाली कंपनी का निशान बताता है. सेवा देने वाली कंपनी को कॉल करके इंस्टैंशिएट किया जा सकता है या टारगेट से उस कंपनी के इंस्टेंस को वापस पाने के लिए, सीधे कुंजी के तौर पर इस्तेमाल किया जा सकता है. उदाहरण:
MyInfo = provider()
...
def _my_library_impl(ctx):
    ...
    my_info = MyInfo(x = 2, y = 3)
    # my_info.x == 2
    # my_info.y == 3
    ...

सेवा देने वाली कंपनियों के इस्तेमाल के तरीके के बारे में पूरी जानकारी देने वाली गाइड के लिए, नियम (सेवा देने वाली कंपनियां) देखें.

अगर init तय नहीं है, तो Provider कॉल करने लायक वैल्यू दिखाता है.

अगर init तय किया गया है, तो यह दो एलिमेंट का ट्यूपल दिखाता है: Provider कॉल की जा सकने वाली वैल्यू और रॉ कंस्ट्रक्टर कॉल की जा सकने वाली वैल्यू. ज़्यादा जानकारी के लिए, नियम (पसंद के मुताबिक सेवा देने वाली कंपनियों को अपने हिसाब से शुरू करने की सुविधा) और नीचे दिए गए init पैरामीटर के बारे में ज़्यादा जानकारी देखें.

पैरामीटर

पैरामीटर ब्यौरा
doc string; या None; डिफ़ॉल्ट रूप से None
सेवा देने वाले की जानकारी होती है. इसे दस्तावेज़ जनरेट करने वाले टूल की मदद से लिया जा सकता है.
fields स्ट्रिंग; या डिकशनरी या None का क्रम; डिफ़ॉल्ट तौर पर None
होता है अगर यह तय किया जाता है, तो अनुमति वाले फ़ील्ड के सेट पर पाबंदी लगा दी जाती है.
संभावित मान ये हैं:
  • फ़ील्ड की सूची:
    provider(fields = ['a', 'b'])

  • डिक्शनरी फ़ील्ड का नाम -> दस्तावेज़:
    provider(
       fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })
सभी फ़ील्ड ज़रूरी नहीं हैं.
init callable; या None; डिफ़ॉल्ट तौर पर None
प्रोवाइडर के फ़ील्ड की वैल्यू को पहले से प्रोसेस करने और इंस्टैंशिएशन के दौरान उनकी पुष्टि करने के लिए, एक वैकल्पिक कॉलबैक. अगर init दिया गया है, तो provider() दो एलिमेंट का ट्यूपल दिखाता है: सामान्य प्रोवाइडर सिंबल और रॉ कन्स्ट्रक्टर.

इसके बाद, सटीक जानकारी दी जाती है. आसान चर्चा और इस्तेमाल के उदाहरणों के लिए, नियम (सेवा देने वाली कंपनियों को अपने हिसाब से शुरू करना) देखें.

मान लें कि P, provider() को कॉल करके बनाया गया, सेवा देने वाली कंपनी का सिंबल है. सैद्धांतिक तौर पर, P का इंस्टेंस, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c(*args, **kwargs) को कॉल करके जनरेट किया जाता है. यह फ़ंक्शन ये काम करता है:

  • अगर args में कोई वैल्यू मौजूद है, तो गड़बड़ी का मैसेज दिखता है.
  • अगर provider() को कॉल करते समय fields पैरामीटर तय किया गया था और kwargs में कोई ऐसी कुंजी है जो fields में मौजूद नहीं थी, तो गड़बड़ी होती है.
  • ऐसा न होने पर, c एक नया इंस्टेंस दिखाता है. इसमें kwargs में मौजूद हर k: v एंट्री के लिए, k नाम का एक फ़ील्ड होता है, जिसकी वैल्यू v होती है.
अगर init कॉलबैक नहीं दिया गया है, तो सिंबल P को कॉल करने पर, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c को कॉल किया जाता है. दूसरे शब्दों में, P(*args, **kwargs) c(*args, **kwargs) दिखाता है. उदाहरण के लिए,
MyInfo = provider()
m = MyInfo(foo = 1)
यह आसानी से बना देगा कि m, m.foo == 1 वाला MyInfo इंस्टेंस है.

हालांकि, अगर init तय किया गया है, तो कॉल P(*args, **kwargs) इन चरणों को पूरा करेगा:

  1. कॉलबैक को init(*args, **kwargs) के तौर पर शुरू किया जाता है. इसका मतलब है कि वह ठीक उसी पोज़िशनल और कीवर्ड आर्ग्युमेंट के साथ होता है जो P को पास किए गए थे.
  2. init की रिटर्न वैल्यू एक डिक्शनरी, d होनी चाहिए जिसकी कुंजियां, फ़ील्ड के नाम वाली स्ट्रिंग हैं. अगर ऐसा नहीं है, तो एक गड़बड़ी होती है.
  3. P का नया इंस्टेंस, c(**d) की तरह ही जनरेट किया जाता है. इसके लिए, डिफ़ॉल्ट कंस्ट्रक्टर को d की एंट्री को कीवर्ड आर्ग्युमेंट के तौर पर कॉल करके बुलाया जाता है.

ध्यान दें: ऊपर दिए गए चरण बताते हैं कि *args या **kwargs, init के हस्ताक्षर से मेल नहीं खाता या init के मुख्य हिस्से की जांच नहीं हो पाई (ऐसा जान-बूझकर fail() पर कॉल करके किया गया) या init की रिटर्न वैल्यू सही स्कीमा वाली डिक्शनरी नहीं है.

इस तरह, init कॉलबैक, प्रीप्रोसेसिंग और पुष्टि करने के लिए, पोज़िशनल आर्ग्युमेंट और मनमुताबिक लॉजिक की अनुमति देकर, सामान्य प्रोवाइडर कंस्ट्रक्शन को सामान्य बनाता है. इस नीति से, मंज़ूर किए गए fields की सूची को गच्चा देने की सुविधा चालू नहीं होती है.

init के बारे में बताने पर, provider() की रिटर्न वैल्यू ट्यूपल (P, r) बन जाती है. यहां r, रॉ कंस्ट्रक्टर है. असल में, r का व्यवहार ठीक ऊपर बताए गए डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c जैसा ही है. आम तौर पर, r को ऐसे वैरिएबल से बंधा होता है जिसका नाम अंडरस्कोर से शुरू होता है, ताकि सिर्फ़ मौजूदा .bzl फ़ाइल का ही इसका सीधा ऐक्सेस हो:

MyInfo, _new_myinfo = provider(init = ...)

repository_rule

callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)

नया डेटा स्टोर करने की जगह का नियम बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे module extension लागू करने वाले फ़ंक्शन से लोड और कॉल किया जा सके या use_repo_rule का इस्तेमाल किया जा सके.

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
इस नियम को लागू करने वाला फ़ंक्शन. इसमें एक पैरामीटर, repository_ctx होना चाहिए. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोडिंग फ़ेज़ के दौरान कॉल किया जाता है.
attrs dict; या None; नियम की सभी विशेषताओं का एलान करने के लिए, None
डिक्शनरी डिफ़ॉल्ट रूप से सेट है. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल में लेबल पर लागू होने वाली डिपेंडेंसी जोड़ने के लिए किया जा सकता है. रिपॉज़िटरी का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं हो सकता. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती.
local डिफ़ॉल्ट तौर पर यह False
होता है इससे पता चलता है कि यह नियम, लोकल सिस्टम से सभी चीज़ें फ़ेच करता है. साथ ही, हर फ़ेच के बाद इसका फिर से आकलन किया जाना चाहिए.
environ string का क्रम; यह डिफ़ॉल्ट []
अब काम नहीं करता है. यह पैरामीटर अब काम नहीं करता. इसके बजाय, repository_ctx.getenv पर माइग्रेट करें.
इससे उस एनवायरमेंट वैरिएबल की सूची मिलती है जिस पर यह रिपॉज़िटरी नियम निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो रिपॉज़िटरी को फिर से लाया जाएगा.
configure डिफ़ॉल्ट रूप से False
होता है यह बताता है कि कॉन्फ़िगरेशन के मकसद से, रिपॉज़िटरी सिस्टम की जांच करता है
remotable डिफ़ॉल्ट तौर पर, यह False
एक्सपेरिमेंटल होता है. इस पैरामीटर को अभी आज़माया जा रहा है और इसमें किसी भी समय बदलाव किया जा सकता है. कृपया इस पर भरोसा न करें. इसे एक्सपेरिमेंट के तौर पर चालू किया जा सकता है. इसके लिए, ---experimental_repo_remote_exec
रिमोट से एक्ज़ीक्यूट करने की सुविधा के साथ काम करता है
doc string; या None; डिफ़ॉल्ट रूप से None
रिपॉज़िटरी (डेटा स्टोर करने की जगह) के नियम की जानकारी होती है. इस जानकारी को दस्तावेज़ जनरेट करने वाले टूल की मदद से एक्सट्रैक्ट किया जा सकता है.

नियम

callable rule(implementation, *, test=unbound, attrs={}, outputs=None, executable=unbound, output_to_genfiles=False, fragments=[], host_fragments=[], _skylark_testable=False, toolchains=[], incompatible_use_toolchain_transition=False, doc=None, provides=[], exec_compatible_with=[], analysis_test=False, build_setting=None, cfg=None, exec_groups=None, initializer=None, parent=None, extendable=None, subrules=[])

एक नया नियम बनाता है, जिसे लक्ष्य बनाने के लिए किसी बिल्ड फ़ाइल या मैक्रो से कॉल किया जा सकता है.

नियम, .bzl फ़ाइल में ग्लोबल वैरिएबल के लिए असाइन होने चाहिए. ग्लोबल वैरिएबल का नाम ही नियम का नाम होता है.

टेस्ट के नियमों का नाम _test पर खत्म होना ज़रूरी है, जबकि बाकी सभी नियमों में यह सफ़िक्स नहीं होना चाहिए. (यह पाबंदी सिर्फ़ नियमों पर लागू होती है, उनके टारगेट पर नहीं.)

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
इस नियम को लागू करने वाले Starlark फ़ंक्शन में सिर्फ़ एक पैरामीटर होना चाहिए: ctx. नियम के हर इंस्टेंस के लिए, विश्लेषण के दौरान फ़ंक्शन को कॉल किया जाता है. यह उपयोगकर्ता की ओर से दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह एक्शन बनाकर, एलान किए गए सभी आउटपुट जनरेट करेगा.
test bool; डिफ़ॉल्ट तौर पर unbound
होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test कमांड का विषय हो सकता है. जांच के सभी नियमों को अपने-आप लागू किया जा सकने वाला मान लिया जाता है. जांच के नियम के लिए साफ़ तौर पर executable = True सेट करना ज़रूरी नहीं है (और ऐसा करने से मना किया जाता है). यह वैल्यू, डिफ़ॉल्ट तौर पर False पर सेट होती है. ज़्यादा जानकारी के लिए, नियमों वाला पेज देखें.
attrs dict; डिफ़ॉल्ट तौर पर {}
की वैल्यू होती है नियम के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल किसी लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट को किसी और तरीके से जोड़ा गया है और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन attr की वैल्यू की सीमा तय करता है.
outputs dict; या None; या Function; डिफ़ॉल्ट रूप से None
अब काम नहीं करता है. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इस पर निर्भर न रहें. ---incompatible_no_rule_outputs_param के साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपका कोड, जल्द ही हटाए जाने वाले वर्शन के साथ काम करता है.
यह पैरामीटर अब काम नहीं करता. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए नियमों को माइग्रेट करें.

पहले से तय किए गए आउटपुट को तय करने के लिए स्कीमा. उपयोगकर्ता इन फ़ाइलों के लिए लेबल नहीं बताता है, जबकि output और output_list एट्रिब्यूट की वैल्यू नहीं दी जाती. पहले से तय किए गए आउटपुट के बारे में ज़्यादा जानने के लिए, नियमों का पेज देखें.

इस आर्ग्युमेंट की वैल्यू, डिक्शनरी या कॉलबैक फ़ंक्शन है, जो डिक्शनरी तैयार करता है. कॉलबैक, कंप्यूट किए गए डिपेंडेंसी एट्रिब्यूट की तरह काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच करते हैं. उदाहरण के लिए, अगर outputs = _my_func को def _my_func(srcs, deps): ... डेफ़िनिशन के साथ पास किया जाता है, तो फ़ंक्शन के पास srcs और deps एट्रिब्यूट का ऐक्सेस होता है. डायक्शनरी को सीधे तौर पर या किसी फ़ंक्शन के ज़रिए तय करने पर, इसका मतलब इस तरह से निकाला जाता है.

शब्दकोश में मौजूद हर एंट्री, पहले से तय किया गया एक आउटपुट बनाती है, जिसमें कुंजी एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है, जो आउटपुट का लेबल तय करती है. नियम के लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर उस फ़ील्ड का नाम बन जाता है जिसका इस्तेमाल ctx.outputs में आउटपुट के File को ऐक्सेस करने के लिए किया जाता है. आउटपुट के लेबल में वही पैकेज होता है जो नियम में होता है. पैकेज के बाद का हिस्सा, "%{ATTR}" फ़ॉर्म के हर प्लेसहोल्डर को एट्रिब्यूट ATTR की वैल्यू से बनाई गई स्ट्रिंग से बदलकर बनाया जाता है:

  • स्ट्रिंग टाइप वाले एट्रिब्यूट की वैल्यू को हूबहू बदल दिया जाता है.
  • लेबल टाइप वाले एट्रिब्यूट, पैकेज के बाद लेबल का हिस्सा बन जाते हैं. हालांकि, इनमें फ़ाइल एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, लेबल "//pkg:a/b.c", "a/b" हो जाता है.
  • आउटपुट-टाइप किए गए एट्रिब्यूट, पैकेज के बाद लेबल का हिस्सा बन जाते हैं. इनमें फ़ाइल एक्सटेंशन भी शामिल है (ऊपर दिए गए उदाहरण के लिए, "a/b.c").
  • प्लेसहोल्डर में इस्तेमाल किए जाने वाले, सूची वाले सभी एट्रिब्यूट (उदाहरण के लिए, attr.label_list) में एक ही एलिमेंट होना चाहिए. उनका कन्वर्ज़न, उनके नॉन-लिस्ट वर्शन (attr.label) जैसा ही है.
  • अन्य तरह के एट्रिब्यूट शायद प्लेसहोल्डर में न दिखें.
  • बिना एट्रिब्यूट वाले खास प्लेसहोल्डर %{dirname} और %{basename} नियम के लेबल के उन हिस्सों में बड़े हो जाते हैं. हालांकि, इसमें पैकेज को शामिल नहीं किया जाता. उदाहरण के लिए, "//pkg:a/b.c" में dirname, a है और basename, b.c है.

आम तौर पर, बदले जाने वाले वैल्यू के लिए सबसे ज़्यादा इस्तेमाल किया जाने वाला प्लेसहोल्डर "%{name}" होता है. उदाहरण के लिए, "foo" नाम के टारगेट के लिए, आउटपुट निर्देश {"bin": "%{name}.exe"}, foo.exe नाम के ऐसे आउटपुट का पहले से एलान करता है जिसे लागू करने के फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.

executable bool; डिफ़ॉल्ट वैल्यू unbound है
क्या इस नियम को एक्ज़ीक्यूट किया जा सकता है यानी इसे एक्ज़ीक्यूट किया जा सकता है. ऐसा हो सकता है कि इस पर blaze run निर्देश लागू हो. यह डिफ़ॉल्ट रूप से False पर सेट होता है. ज़्यादा जानकारी के लिए, नियमों वाला पेज देखें.
output_to_genfiles False डिफ़ॉल्ट है
अगर सही है, तो फ़ाइलें बिन डायरेक्ट्री के बजाय genfile की डायरेक्ट्री में जनरेट की जाएंगी. जब तक आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत न हो (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय), तब तक इस फ़्लैग को सेट न करें.
fragments string की क्रम; डिफ़ॉल्ट रूप से []
उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी नियम के लिए टारगेट कॉन्फ़िगरेशन में ज़रूरत होती है.
host_fragments स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से []
होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन में नियम के लिए होती है.
_skylark_testable डिफ़ॉल्ट रूप से False
(प्रयोग के तौर पर उपलब्ध)

अगर यह 'सही' है, तो यह नियम Actions प्रोवाइडर के ज़रिए, उन नियमों की जांच के लिए अपनी कार्रवाइयों को ज़ाहिर करेगा जो इस नियम पर निर्भर हैं. सेवा देने वाली कंपनी, ctx.created_actions() को कॉल करके अपने नियम खुद भी उपलब्ध करा सकती है.

इसका इस्तेमाल सिर्फ़ Starlark के नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में, इस फ़्लैग को हटाया जा सकता है.
toolchains क्रम; डिफ़ॉल्ट तौर पर []
सेट होता है. अगर यह सेट है, तो इस नियम के लिए ज़रूरी टूलचेन के सेट का इस्तेमाल किया जाता है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
incompatible_use_toolchain_transition यह डिफ़ॉल्ट रूप से False पर सेट है
यह काम नहीं करता है. अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए.
doc string; या None; डिफ़ॉल्ट रूप से None
नियम का ब्यौरा होता है. इसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.
provides डिफ़ॉल्ट तौर पर यह [] है
सेवा देने वाली कंपनियों की ऐसी सूची जिसे लागू करने वाले फ़ंक्शन को दिखाना ज़रूरी है.

अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं.

सूची का हर एलिमेंट, provider() से मिला एक *Info ऑब्जेक्ट है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के टारगेट का इस्तेमाल, किसी ऐसे टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है जो ज़रूरी कंपनी के बारे में बताता है, तो यहां उस प्रोवाइडर के बारे में बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसे इस्तेमाल करना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.

exec_compatible_with string की क्रम; डिफ़ॉल्ट रूप से []
लागू होने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है, जो इस नियम के टाइप के सभी टारगेट पर लागू होती है.
analysis_test डिफ़ॉल्ट वैल्यू False है
अगर सही है, तो इस नियम को विश्लेषण वाली जांच माना जाता है.

ध्यान दें: विश्लेषण की जांच के नियमों को मुख्य तौर पर, Starlark की मुख्य लाइब्रेरी में दिए गए इन्फ़्रास्ट्रक्चर का इस्तेमाल करके तय किया जाता है. दिशा-निर्देशों के लिए, जांच करना लेख देखें.

अगर कोई नियम, विश्लेषण की जांच करने के नियम के तौर पर तय किया गया है, तो वह अपने एट्रिब्यूट पर analysis_test_transition का इस्तेमाल करके तय किए गए कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल कर सकता है. हालांकि, यह कुछ पाबंदियों में शामिल हो जाता है:

  • इस नियम के टारगेट, ट्रांज़िटिव डिपेंडेंसी की संख्या तक सीमित हैं.
  • इस नियम को टेस्ट नियम माना जाता है (जैसे कि test=True सेट किया गया हो). यह test की वैल्यू की जगह लागू होगा
  • नियम लागू करने का फ़ंक्शन, कार्रवाइयां रजिस्टर नहीं कर सकता. इसके बजाय, AnalysisTestResultInfo की मदद से, पास/फ़ेल का नतीजा रजिस्टर करना होगा.
build_setting BuildSetting; या None; डिफ़ॉल्ट तौर पर यह None है
अगर इसे सेट किया जाता है, तो इससे पता चलता है कि यह नियम किस तरह का build setting है. config मॉड्यूल देखें. अगर इसे सेट किया जाता है, तो "build_setting_default" नाम का एक ज़रूरी एट्रिब्यूट अपने-आप इस नियम में जोड़ दिया जाता है. इस एट्रिब्यूट का टाइप, यहां दी गई वैल्यू से जुड़ा होता है.
cfg डिफ़ॉल्ट रूप से None
अगर सेट किया जाता है, तो कॉन्फ़िगरेशन ट्रांज़िशन को इंगित करता है. विश्लेषण से पहले, नियम अपने कॉन्फ़िगरेशन पर लागू होगा.
exec_groups dict; या None; यह डिफ़ॉल्ट रूप से None
एक्ज़ीक्यूशन ग्रुप का नाम (स्ट्रिंग) लिखकर exec_groups पर सेट होता है. अगर यह सेट है, तो नियमों को एक ही टारगेट में कई एक्सीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, निष्पादक समूह का दस्तावेज़ देखें.
initializer डिफ़ॉल्ट तौर पर, None है
एक्सपेरिमेंटल: नियम के एट्रिब्यूट को शुरू करने वाला Stlark फ़ंक्शन.

फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे name और नियम के मुताबिक तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू की मदद से कॉल किया जाता है (सामान्य एट्रिब्यूट के साथ नहीं, जैसे कि tags).

यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट को दिखाया नहीं जाता उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर None दिखाने पर, एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है.

किसी एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू से पहले, शुरू करने वालों का आकलन किया जाता है. इसलिए, अगर इनिशलाइज़र के सिग्नेचर में किसी पैरामीटर की डिफ़ॉल्ट वैल्यू मौजूद है, तो वह एट्रिब्यूट की परिभाषा से डिफ़ॉल्ट वैल्यू को बदल देती है. हालांकि, None दिखाने पर ऐसा नहीं होता.

इसी तरह, अगर शुरू करने वाले के हस्ताक्षर में कोई पैरामीटर डिफ़ॉल्ट नहीं है, तो पैरामीटर ज़रूरी हो जाएगा. ऐसे मामलों में, किसी एट्रिब्यूट की डेफ़िनिशन में मौजूद डिफ़ॉल्ट/ज़रूरी सेटिंग को हटा देना बेहतर रहता है.

जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए **kwargs का इस्तेमाल करना अच्छा होता है.

लागू किए गए नियमों के मामले में, सभी शुरू करने वाले को चाइल्ड से लेकर ऐन्सेस्टर पर जाना कहा जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है.

parent डिफ़ॉल्ट तौर पर यह None है
एक्सपेरिमेंटल: स्टैलार्क नियम बढ़ाया गया है. सेट किए जाने पर सार्वजनिक एट्रिब्यूट को विज्ञापन देने वाली कंपनियों के साथ मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज कर दी गई हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg को, इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद लागू किया जाता है.
extendable bool; या Label; या string; या None; डिफ़ॉल्ट None है
प्रयोग के तौर पर: अनुमति वाली सूची का लेबल, जो बताता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अनुमति न देने के लिए, इसे 'सही/गलत' पर भी सेट किया जा सकता है. Basel को डिफ़ॉल्ट रूप से, एक्सटेंशन को अनुमति देने की सुविधा मिलती है.
subrules सबनियम का क्रम; डिफ़ॉल्ट रूप से []
होता है एक्सपेरिमेंटल: इस नियम में इस्तेमाल किए गए सबनियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

पैरामीटर ब्यौरा
x ज़रूरी है
ऐसा लिखवाने की सुविधा जो कॉन्फ़िगरेशन की स्थितियों को वैल्यू पर मैप करती है. हर कुंजी एक लेबल या लेबल स्ट्रिंग होती है, जो config_setting या constraint_value इंस्टेंस की पहचान करती है. स्ट्रिंग के बजाय लेबल का इस्तेमाल कब करना है, यह जानने के लिए मैक्रो के बारे में दस्तावेज़ देखें.
no_match_error '' डिफ़ॉल्ट है
अगर कोई शर्त मेल नहीं खाती है, तो रिपोर्ट करने के लिए कस्टम गड़बड़ी ज़रूरी नहीं है.

सबरुल

Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])

किसी सबनियम का नया इंस्टेंस बनाता है. इस फ़ंक्शन के नतीजे का इस्तेमाल करने से पहले, इसे ग्लोबल वैरिएबल में सेव किया जाना चाहिए.

पैरामीटर

पैरामीटर ब्यौरा
implementation फ़ंक्शन; ज़रूरी
इस सबरूल को लागू करने वाला Starlark फ़ंक्शन
attrs शब्दकोश; डिफ़ॉल्ट रूप से {}
सब रूल के सभी (निजी) एट्रिब्यूट का एलान करने के लिए डिक्शनरी है.

सबनियमों में सिर्फ़ निजी एट्रिब्यूट हो सकते हैं, जो लेबल-टाइप (जैसे, लेबल या लेबल-लिस्ट) के होते हैं. इन लेबल से जुड़ी समाधान की गई वैल्यू, सबरुल के लागू करने वाले फ़ंक्शन में, नाम वाले आर्ग्युमेंट के तौर पर अपने-आप पास हो जाती हैं. इसलिए, लागू करने के फ़ंक्शन के लिए, एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करना ज़रूरी है. ये वैल्यू इस तरह की होंगी:

  • executable=True वाले लेबल एट्रिब्यूट के लिए FilesToRunProvider
  • allow_single_file=True वाले लेबल एट्रिब्यूट के लिए File
  • अन्य सभी लेबल एट्रिब्यूट के लिए Target
  • सभी लेबल-लिस्ट एट्रिब्यूट के लिए [Target]
toolchains क्रम; डिफ़ॉल्ट तौर पर []
सेट होता है. अगर इसे सेट किया जाता है, तो इस सब-नियम के लिए टूलचेन के सेट की ज़रूरत होती है. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, ctx.toolchains के ज़रिए सब-रुल को लागू करने के लिए उपलब्ध कराई जाएगी.
fragments स्ट्रिंग का क्रम; डिफ़ॉल्ट []
है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में सबनियम को ज़रूरत होती है.
subrules सबरूल का क्रम; डिफ़ॉल्ट रूप से []
इस सब रूल के लिए ज़रूरी अन्य सबनियमों की सूची है.

tag_class

tag_class tag_class(attrs={}, *, doc=None)

यह एक नया tag_class ऑब्जेक्ट बनाता है, जो टैग की क्लास के लिए एट्रिब्यूट स्कीमा तय करता है. ये ऐसे डेटा ऑब्जेक्ट होते हैं जिनका इस्तेमाल मॉड्यूल एक्सटेंशन कर सकता है.

पैरामीटर

पैरामीटर ब्यौरा
attrs {}
डिफ़ॉल्ट है, जो इस टैग क्लास के सभी एट्रिब्यूट के बारे में जानकारी देने के लिए डिक्शनरी है. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें).
doc string; या None; डिफ़ॉल्ट रूप से यह None होता है
. यह टैग क्लास की जानकारी होती है, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है.

कैसा दिखाई दे

None visibility(value)

फ़िलहाल, जिस .bzl मॉड्यूल को शुरू किया जा रहा है उसकी लोड विज़िबिलिटी सेट करता है.

मॉड्यूल के लोड होने की सेटिंग से यह तय होता है कि अन्य बिल्ड और .bzl फ़ाइलों को लोड किया जा सकता है या नहीं. (यह, .bzl सोर्स फ़ाइल के टारगेट के दिखने से अलग है. इससे यह तय होता है कि फ़ाइल, दूसरे टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड दिखने की सुविधा, पैकेज के लेवल पर काम करती है: किसी मॉड्यूल को लोड करने के लिए, लोड करने वाली फ़ाइल को उस पैकेज में होना चाहिए जिसे मॉड्यूल को दिखने की अनुमति दी गई है. मॉड्यूल को हमेशा उसके अपने पैकेज में लोड किया जा सकता है, चाहे उसकी दृश्यता कुछ भी हो.

visibility() को हर .bzl फ़ाइल में सिर्फ़ एक बार और सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, न कि किसी फ़ंक्शन में. इस कॉल को load() स्टेटमेंट और आर्ग्युमेंट तय करने के लिए ज़रूरी छोटे लॉजिक के ठीक नीचे रखना सबसे सही है.

अगर फ़्लैग --check_bzl_visibility को 'गलत है' पर सेट किया जाता है, तो लोड दिखने से जुड़े उल्लंघनों की चेतावनियां मिलेंगी. हालांकि, इससे बिल्ड पूरा नहीं होगा.

पैरामीटर

पैरामीटर ब्यौरा
value ज़रूरी है
पैकेज स्पेसिफ़िकेशन वाली स्ट्रिंग या किसी पैकेज के लिए स्पेसिफ़िकेशन वाली स्ट्रिंग की सूची.

पैकेज की जानकारी, package_group के फ़ॉर्मैट के हिसाब से ही होती है. हालांकि, पैकेज की नेगेटिव जानकारी की अनुमति नहीं है. इसका मतलब है कि किसी स्पेसिफ़िकेशन के ये फ़ॉर्म हो सकते हैं:

  • "//foo": पैकेज //foo
  • "//foo/...": //foo पैकेज और इसके सभी सबपैकेज.
  • "public" या "private": क्रम के हिसाब से, सभी पैकेज या कोई पैकेज नहीं

"@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के रिपॉज़िटरी के हिसाब से समझा जाता है.

अगर value स्ट्रिंग की एक सूची है, तो इस मॉड्यूल को दिखाए जाने वाले पैकेज का सेट, हर स्पेसिफ़िकेशन के मुताबिक दिखाए जाने वाले पैकेज का कॉम्बिनेशन होता है. (खाली सूची का असर private जैसा ही होता है.) अगर value एक स्ट्रिंग है, तो इसे सिंगलटन सूची [value] के तौर पर माना जाता है.

ध्यान दें कि फ़्लैग --incompatible_package_group_has_public_syntax और --incompatible_fix_package_group_reporoot_syntax का इस आर्ग्युमेंट पर कोई असर नहीं पड़ता. "public" और "private" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.