BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

इस पेज का अनुवाद Cloud Translation API से किया गया है.

.bzl फ़ाइलें

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

पैरामीटर ब्यौरा

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

पैरामीटर	ब्यौरा
`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`	dict; डिफ़ॉल्ट रूप से `{}` है शब्दकोश, जो पहलू की सभी विशेषताओं के बारे में बताता है. यह एट्रिब्यूट के नाम से, एट्रिब्यूट ऑब्जेक्ट पर मैप होता है, जैसे कि `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`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिन्हें टारगेट कॉन्फ़िगरेशन में उस पहलू के लिए ज़रूरी है.
`host_fragments`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिनकी होस्ट कॉन्फ़िगरेशन में उस पहलू के लिए ज़रूरत होती है.
`toolchains`	क्रम; डिफ़ॉल्ट रूप से `[]` है अगर सेट हो, तो इस नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, इसे `ctx.toolchain` के ज़रिए नियम लागू करने के लिए उपलब्ध कराया जाएगा.
`incompatible_use_toolchain_transition`	डिफ़ॉल्ट रूप से `False` है अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए. अब यह काम नहीं कर रहा है.
`doc`	string; या `None`; डिफ़ॉल्ट रूप से `None` है उस पहलू के बारे में जानकारी जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.
`apply_to_generating_rules`	डिफ़ॉल्ट रूप से `False` है अगर सही है, तो आउटपुट फ़ाइल पर लागू किया जाएगा. इसके बजाय, उस आसपेक्ट को आउटपुट फ़ाइल के जनरेट करने के नियम पर लागू किया जाएगा. उदाहरण के लिए, मान लें कि कोई पहलू `deps` के ज़रिए ट्रांज़िट तरीके से फैलता है और इसे `ऐल्फ़ा` को टारगेट करने पर लागू किया जाता है. मान लीजिए कि `अल्फ़ा` में `deps = [':beta_Output']` है. इसमें `beta_Output` किसी टारगेट `बीटा` का एलान किया गया आउटपुट है. मान लीजिए कि `बीटा` का लक्ष्य `चार्ली` अपने एक `डेप्स` के रूप में है. अगर पहलू के लिए `apply_to_generting_rules=True` लागू होता है, तो पक्ष `अल्फ़ा`, `बीटा` और `चार्ली` के ज़रिए फैल जाएगा. अगर गलत है, तो आसपेक्ट रेशियो सिर्फ़ `ऐल्फ़ा` में चलेगा. डिफ़ॉल्ट रूप से 'गलत'.
`exec_compatible_with`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस पहलू के सभी इंस्टेंस पर लागू होती है.
`exec_groups`	dict; या `None`; डिफ़ॉल्ट रूप से `None` है `exec_group`s तक चलने वाले ग्रुप के नाम (स्ट्रिंग) को लिखवाना. अगर नीति सेट की जाती है, तो इससे डाइमेंशन को एक ही इंस्टेंस में, इसे लागू करने वाले कई प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, लागू किए जाने वाले ग्रुप का दस्तावेज़ देखें.
`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)

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

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

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

साथ ही, यह ज़रूरी है कि मौजूदा समय में एलिमेंट में बदलाव न किया जा सके. हालांकि, आने वाले समय में यह पाबंदी हट जाएगी.

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

पैरामीटर ब्यौरा

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

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)

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	ज़रूरी है इस मॉड्यूल एक्सटेंशन को लागू करने वाला फ़ंक्शन. एक पैरामीटर होना ज़रूरी है, `module_ctx`. बिल्ड की शुरुआत में इस फ़ंक्शन को एक बार कॉल किया जाता है, ताकि उपलब्ध डेटा स्टोर करने की जगहों का सेट तय किया जा सके.
`tag_classes`	डिफ़ॉल्ट रूप से `{}` है एक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास के बारे में जानकारी देने के लिए डिक्शनरी. यह टैग क्लास के नाम से `tag_class` ऑब्जेक्ट पर मैप होता है.
`doc`	string; या `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
है दस्तावेज़ जनरेट करने वाले टूल की मदद से, सेवा देने वाली कंपनी के बारे में जानकारी.

पैरामीटर	ब्यौरा
`doc`	string; या `None`; डिफ़ॉल्ट रूप से `None` है दस्तावेज़ जनरेट करने वाले टूल की मदद से, सेवा देने वाली कंपनी के बारे में जानकारी.
`fields`	स्ट्रिंग का सीक्वेंस; या शब्दकोश; या `None`; डिफ़ॉल्ट `None` है अगर तय किया गया है, तो अनुमति वाले फ़ील्ड के सेट को सीमित करता है. संभावित मान ये हैं: फ़ील्ड की सूची: provider(fields = ['a', 'b']) शब्दकोश फ़ील्ड का नाम -> दस्तावेज़: provider( fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' }) सभी फ़ील्ड ज़रूरी नहीं हैं.
`init`	कॉल करने लायक; या `None`; डिफ़ॉल्ट रूप से `None` है इंस्टैंशिएट करने के दौरान, सेवा देने वाली कंपनी की फ़ील्ड वैल्यू की प्री-प्रोसेस और पुष्टि करने के लिए एक वैकल्पिक कॉलबैक. अगर `init` बताया गया है, तो `provider()` दो एलिमेंट का टपल दिखाता है: सामान्य प्रोवाइडर का सिंबल और रॉ कंस्ट्रक्टर. इसके बाद, कॉन्टेंट के बारे में सटीक जानकारी दी जाती है; आसान चर्चा और इस्तेमाल के उदाहरणों के लिए, नियम (सेवा देने वाली कंपनियों को अपने हिसाब से शुरू करने की सुविधा) देखें. `P` को `provider()` को कॉल करके बनाया गया, सेवा देने वाली कंपनी का सिंबल बनाएं. सैद्धांतिक तौर पर, `P` का इंस्टेंस, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन `c(args, kwargs)` को कॉल करके जनरेट किया जाता है. यह फ़ंक्शन ये काम करता है: अगर `args` खाली नहीं है, तो कोई गड़बड़ी होगी. अगर `provider()` को कॉल करते समय `fields` पैरामीटर बताया गया था और `kwargs` में कोई ऐसी कुंजी मौजूद है जो `fields` में नहीं दी गई है, तो गड़बड़ी होती है. ऐसा नहीं करने पर, `c` एक नया इंस्टेंस दिखाता है, जिसमें `kwargs` में हर `k: v` एंट्री के लिए, `v` वैल्यू वाली `k` फ़ील्ड होती है. ऐसे मामले में जहां `init` कॉलबैक नहीं* दिया जाता है, वहां सिंबल `P` को किया जाने वाला कॉल, अपने-आप डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन `c` को कॉल के तौर पर काम करता है; दूसरे शब्दों में, `P(args, kwargs)`, `c(args, *kwargs)` दिखाता है. उदाहरण के लिए, MyInfo = provider() m = MyInfo(foo = 1) इसे सीधे तौर पर ऐसे बना देगा कि `m`, `m.foo == 1` के साथ एक `MyInfo` इंस्टेंस है. हालांकि, जहां `init` बताया गया है, वहां कॉल `P(args, *kwargs)` इसके बजाय नीचे दिए गए चरणों को पूरा करेगा: कॉलबैक को `init(args, kwargs)` के तौर पर शुरू किया जाता है. इसका मतलब है कि वह ठीक उसी पोज़िशनल और कीवर्ड आर्ग्युमेंट के साथ होता है जो `P` को पास किए गए थे. `init` की रिटर्न वैल्यू एक डिक्शनरी, `d` होनी चाहिए जिसकी कुंजियां, फ़ील्ड के नाम वाली स्ट्रिंग हैं. अगर ऐसा नहीं है, तो एक गड़बड़ी होती है. `d` की एंट्री वाले डिफ़ॉल्ट कंस्ट्रक्टर को कीवर्ड आर्ग्युमेंट के तौर पर कॉल करने पर, `P` का नया इंस्टेंस जनरेट होता है, जैसा कि `c(d)` में होता है. ध्यान दें: ऊपर दिए गए चरण बताते हैं कि `args` या `kwargs`, `init` के हस्ताक्षर से मेल नहीं खाता या `init` के मुख्य हिस्से की जांच नहीं हो पाई (ऐसा जान-बूझकर `fail()` पर कॉल करके किया गया) या `init` की रिटर्न वैल्यू सही स्कीमा वाली डिक्शनरी नहीं है. इस तरह `init` कॉलबैक, सेवा देने वाली कंपनी के सामान्य तरीके को सामान्य बनाता है. इसके लिए, प्री-प्रोसेसिंग और पुष्टि करने के लिए पोज़िशनल आर्ग्युमेंट और आर्बिट्रेरी लॉजिक की अनुमति दी जाती है. इस नीति से, मंज़ूर किए गए `fields` की सूची को गच्चा देने की सुविधा चालू नहीं* होती है. `init` के बारे में बताने पर, `provider()` की रिटर्न वैल्यू ट्यूपल `(P, r)` बन जाती है. यहां `r`, रॉ कंस्ट्रक्टर है. असल में, `r` का व्यवहार ठीक ऊपर बताए गए डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन `c` जैसा ही है. आम तौर पर, `r` ऐसे वैरिएबल से जुड़ा होता है जिसके नाम से पहले अंडरस्कोर लगा होता है. ऐसा इसलिए है, ताकि सिर्फ़ मौजूदा .bzl फ़ाइल के पास उसका सीधा ऐक्सेस हो: MyInfo, _new_myinfo = provider(init = ...)

fields

स्ट्रिंग का सीक्वेंस; या शब्दकोश; या None; डिफ़ॉल्ट None
है अगर तय किया गया है, तो अनुमति वाले फ़ील्ड के सेट को सीमित करता है.
संभावित मान ये हैं:

फ़ील्ड की सूची:
```
provider(fields = ['a', 'b'])
```
शब्दकोश फ़ील्ड का नाम -> दस्तावेज़:
```
provider(
       fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })
```

सभी फ़ील्ड ज़रूरी नहीं हैं.

init

कॉल करने लायक; या None; डिफ़ॉल्ट रूप से None
है इंस्टैंशिएट करने के दौरान, सेवा देने वाली कंपनी की फ़ील्ड वैल्यू की प्री-प्रोसेस और पुष्टि करने के लिए एक वैकल्पिक कॉलबैक. अगर init बताया गया है, तो provider() दो एलिमेंट का टपल दिखाता है: सामान्य प्रोवाइडर का सिंबल और रॉ कंस्ट्रक्टर.

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

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

अगर args खाली नहीं है, तो कोई गड़बड़ी होगी.
अगर provider() को कॉल करते समय fields पैरामीटर बताया गया था और kwargs में कोई ऐसी कुंजी मौजूद है जो fields में नहीं दी गई है, तो गड़बड़ी होती है.
ऐसा नहीं करने पर, c एक नया इंस्टेंस दिखाता है, जिसमें kwargs में हर k: v एंट्री के लिए, v वैल्यू वाली k फ़ील्ड होती है.

ऐसे मामले में जहां init कॉलबैक नहीं दिया जाता है, वहां सिंबल P को किया जाने वाला कॉल, अपने-आप डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c को कॉल के तौर पर काम करता है; दूसरे शब्दों में, P(*args, **kwargs), c(*args, **kwargs) दिखाता है. उदाहरण के लिए,

MyInfo = provider()
m = MyInfo(foo = 1)

इसे सीधे तौर पर ऐसे बना देगा कि m, m.foo == 1 के साथ एक MyInfo इंस्टेंस है.

हालांकि, जहां init बताया गया है, वहां कॉल P(*args, **kwargs) इसके बजाय नीचे दिए गए चरणों को पूरा करेगा:

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	ज़रूरी है वह फ़ंक्शन जो इस नियम को लागू करता है. एक ही पैरामीटर होना चाहिए, `repository_ctx`. नियम के हर इंस्टेंस के लिए, फ़ंक्शन को लोड होने के दौरान कॉल किया जाता है.
`attrs`	dict; या `None`; डिफ़ॉल्ट रूप से `None` है शब्दकोश का इस्तेमाल करें. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (attr मॉड्यूल देखें). `_` से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल के लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटा स्टोर करने का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं कर सकता. `name` विशेषता को निहित रूप से जोड़ा गया है और उसे बताया नहीं जाना चाहिए.
`local`	डिफ़ॉल्ट रूप से `False` है इससे पता चलता है कि इस नियम के तहत लोकल सिस्टम से सब कुछ फ़ेच किया जाता है. साथ ही, हर बार फ़ेच करने पर इसका फिर से आकलन किया जाना चाहिए.
`environ`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है अब काम नहीं करता. यह पैरामीटर अब काम नहीं करता. इसके बजाय, `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`; या फ़ंक्शन; डिफ़ॉल्ट रूप से `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"` में, डायरनेम `a` है और बेसनाम `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`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.
`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`	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट `[]` है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस नियम के टाइप के सभी टारगेट पर लागू होती है.
`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_group`s तक चलने वाले ग्रुप के नाम (स्ट्रिंग) को लिखवाना. अगर यह नीति सेट की जाती है, तो इससे नियमों को किसी एक टारगेट में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, लागू किए जाने वाले ग्रुप का दस्तावेज़ देखें.
`initializer`	डिफ़ॉल्ट रूप से `None` है एक्सपेरिमेंटल: नियम की विशेषताओं को शुरू करने वाला Stlark फ़ंक्शन. नियम की हर आवृत्ति के लिए फ़ंक्शन को लोड समय पर कॉल किया जाता है. इसे `name` और नियम के मुताबिक तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू की मदद से कॉल किया जाता है (सामान्य एट्रिब्यूट के साथ नहीं, जैसे कि `tags`). इसे एट्रिब्यूट के नाम से, पसंद की वैल्यू के लिए डिक्शनरी देनी होगी. जिन एट्रिब्यूट को दिखाया नहीं जाता उन पर कोई असर नहीं पड़ता. `None` को वैल्यू के तौर पर रिटर्न करने पर, एट्रिब्यूट की परिभाषा में बताए गए डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. किसी एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू से पहले, शुरू करने वालों का आकलन किया जाता है. ऐसे में, अगर शुरू करने वाले के हस्ताक्षर में मौजूद किसी पैरामीटर में डिफ़ॉल्ट वैल्यू है, तो वह एट्रिब्यूट की परिभाषा (अगर `None` है, तो) को छोड़कर, डिफ़ॉल्ट वैल्यू को बदल देती है. इसी तरह, अगर शुरू करने वाले के हस्ताक्षर में कोई पैरामीटर डिफ़ॉल्ट नहीं है, तो पैरामीटर ज़रूरी हो जाएगा. ऐसे मामलों में, किसी एट्रिब्यूट की डेफ़िनिशन में मौजूद डिफ़ॉल्ट/ज़रूरी सेटिंग को हटा देना बेहतर रहता है. जो एट्रिब्यूट मैनेज नहीं किए जाते उनके लिए `**kwargs` का इस्तेमाल करना एक अच्छा तरीका है. लागू किए गए नियमों के मामले में, सभी शुरू करने वाले को चाइल्ड से लेकर ऐन्सेस्टर पर जाना कहा जाता है. हर शुरू करने वाला टूल सिर्फ़ उन सार्वजनिक एट्रिब्यूट को पास करता है जिनके बारे में उसे पता है.
`parent`	डिफ़ॉल्ट रूप से `None` है प्रयोग के तौर पर: स्टालार्क का नियम बढ़ाया गया है. सेट किए जाने पर सार्वजनिक एट्रिब्यूट को विज्ञापन देने वाली कंपनियों के साथ मर्ज कर दिया जाता है. यह नियम, पैरंट की ओर से दी गई `executable` और `test` से मेल खाता है. `fragments`, `toolchains`, `exec_compatible_with`, और `exec_groups` की वैल्यू मर्ज कर दी गई हैं. ऐसा हो सकता है कि लेगसी या काम न करने वाले पैरामीटर सेट न किए जाएं. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद पैरंट कॉन्फ़िगरेशन `cfg` का ट्रांज़िशन लागू होगा.
`extendable`	bool; या लेबल; या स्ट्रिंग; या `None`; डिफ़ॉल्ट `None` है प्रयोग के तौर पर: अनुमति वाली सूची का लेबल, जिससे यह तय होता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अनुमति न देने के लिए, इसे 'सही/गलत' पर भी सेट किया जा सकता है. Basel को डिफ़ॉल्ट रूप से, एक्सटेंशन को अनुमति देने की सुविधा मिलती है.
`subrules`	सबरूल का क्रम; डिफ़ॉल्ट `[]` है प्रयोगात्मक: इस नियम द्वारा उपयोग किए जाने वाले उप-नियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

पैरामीटर ब्यौरा

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

no_match_error डिफ़ॉल्ट रूप से ''
है अगर कोई शर्त मेल नहीं खाती है, तो रिपोर्ट करने के लिए वैकल्पिक कस्टम गड़बड़ी.

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

सबरुल

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	फ़ंक्शन; ज़रूरी है इस सबरूल को लागू करने वाला Starlark फ़ंक्शन
`attrs`	dict; डिफ़ॉल्ट रूप से `{}` है सबरूल के सभी (निजी) एट्रिब्यूट के बारे में जानकारी देने के लिए डिक्शनरी. उप-नियम में केवल लेबल-टाइप की गई निजी विशेषताएं (जैसे लेबल या लेबल-सूची) हो सकती हैं. इन लेबल से जुड़ी समाधान की गई वैल्यू, सबरुल के लागू करने वाले फ़ंक्शन में, नाम वाले आर्ग्युमेंट के तौर पर अपने-आप पास हो जाती हैं. इसलिए, लागू करने के फ़ंक्शन के लिए, एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करना ज़रूरी है. ये वैल्यू इस तरह की होंगी: `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
है टैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.

पैरामीटर	ब्यौरा
`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"` वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, `"//..."` को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.

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" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.