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

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

.bzl फ़ाइलें

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

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

सदस्य

analysis_test_transition
aspect
configuration_field
depset
exec_group
module_extension
सेवा देने वाली कंपनी
repository_rule
नियम
चुनें
subrule
tag_class
विज़िबिलिटी

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

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

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`	sequence; डिफ़ॉल्ट तौर पर `[]` सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और `ctx.toolchain` के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
`incompatible_use_toolchain_transition`	डिफ़ॉल्ट `False` है यह विकल्प अब काम नहीं करता. इसे हटा दिया जाना चाहिए.
`doc`	स्ट्रिंग या `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_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)

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

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

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

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

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

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

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

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

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

module_extension

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`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 स्ट्रिंग या None; डिफ़ॉल्ट तौर पर None
सेवा देने वाली कंपनी की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.

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

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) इन चरणों को पूरा करेगा:

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	ज़रूरी है वह फ़ंक्शन जो इस नियम को लागू करता है. इसमें एक पैरामीटर, `repository_ctx` होना चाहिए. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोडिंग फ़ेज़ के दौरान कॉल किया जाता है.
`attrs`	dict या `None`; डिफ़ॉल्ट तौर पर `None` नियम के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). `_` से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल में लेबल पर लागू होने वाली डिपेंडेंसी जोड़ने के लिए किया जा सकता है. रिपॉज़िटरी का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं हो सकता. `name` एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती.
`local`	डिफ़ॉल्ट तौर पर यह `False` होता है इससे पता चलता है कि यह नियम, लोकल सिस्टम से सभी चीज़ें फ़ेच करता है. साथ ही, हर फ़ेच के बाद इसका फिर से आकलन किया जाना चाहिए.
`environ`	स्ट्रिंग का क्रम; डिफ़ॉल्ट तौर पर, `[]` होता है इस रेपॉज़िटरी नियम के लिए, एनवायरमेंट वैरिएबल की सूची उपलब्ध कराता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो रिपॉज़िटरी को फिर से फ़ेच किया जाएगा.
`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=[])

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

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह एक्शन बनाकर, एलान किए गए सभी आउटपुट जनरेट करेगा.
`test`	bool; डिफ़ॉल्ट तौर पर `unbound` होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह `blaze test` कमांड का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप कार्यान्वित माना जाता है. किसी टेस्ट नियम के लिए, `executable = True` को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. डिफ़ॉल्ट रूप से, इसकी वैल्यू `False` होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
`attrs`	dict; डिफ़ॉल्ट तौर पर `{}` नियम के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). `_` से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है. `name` एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती. `visibility`, `deprecation`, `tags`, `testonly`, और `features` एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन, एट्रिब्यूट के साइज़ पर एक सीमा लगाता है.
`outputs`	dict; या `None`; या function; डिफ़ॉल्ट `None` अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इस पर भरोसा न करें. `---incompatible_no_rule_outputs_param` के साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपका कोड, जल्द ही हटाए जाने वाले वर्शन के साथ काम करता है. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, `OutputGroupInfo` या `attr.output` का इस्तेमाल करने के लिए नियमों को माइग्रेट करें. पहले से तय किए गए आउटपुट तय करने के लिए स्कीमा. `output` और `output_list` एट्रिब्यूट के उलट, उपयोगकर्ता इन फ़ाइलों के लिए लेबल तय नहीं करता. पहले से तय किए गए आउटपुट के बारे में ज़्यादा जानने के लिए, नियमों का पेज देखें. इस आर्ग्युमेंट की वैल्यू, कोई डिक्शनरी या कॉलबैक फ़ंक्शन होती है, जो डिक्शनरी बनाता है. कॉलबैक, कैलकुलेट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच किए जाते हैं. उदाहरण के लिए, अगर आपने परिभाषा `def _my_func(srcs, deps): ...` के साथ `outputs = _my_func` पास किया है, तो फ़ंक्शन के पास `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` अगर इसकी वैल्यू 'सही' है, तो फ़ाइलें bin डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है, तो इस फ़्लैग को सेट न करें. उदाहरण के लिए, C++ के लिए हेडर फ़ाइलें जनरेट करते समय.
`fragments`	स्ट्रिंग का क्रम; डिफ़ॉल्ट `[]` है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.
`host_fragments`	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से `[]` होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन में नियम के लिए होती है.
`_skylark_testable`	डिफ़ॉल्ट रूप से `False` (प्रयोग के तौर पर उपलब्ध) अगर यह 'सही' है, तो यह नियम `Actions` प्रोवाइडर के ज़रिए, उन नियमों की जांच के लिए अपनी कार्रवाइयों को ज़ाहिर करेगा जो इस नियम पर निर्भर हैं. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध है. इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में, इस फ़्लैग को हटाया जा सकता है.
`toolchains`	sequence; डिफ़ॉल्ट तौर पर `[]` सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या 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` है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे नियम के मुताबिक तय किए गए पब्लिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है, न कि सामान्य एट्रिब्यूट (उदाहरण के लिए, `name` या `tags`) के साथ. यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर `None` दिखाने पर, एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. किसी एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू से पहले, इनिशिएलाइज़र का आकलन किया जाता है. इसलिए, अगर इनिशलाइज़र के सिग्नेचर में किसी पैरामीटर की डिफ़ॉल्ट वैल्यू मौजूद है, तो वह एट्रिब्यूट की परिभाषा में मौजूद डिफ़ॉल्ट वैल्यू को बदल देती है. हालांकि, `None` दिखाने पर ऐसा नहीं होता. इसी तरह, अगर किसी पैरामीटर के लिए डिफ़ॉल्ट वैल्यू नहीं दी गई है, तो उसे पैरामीटर के तौर पर इस्तेमाल करना ज़रूरी हो जाएगा. ऐसे मामलों में, एट्रिब्यूट की परिभाषा में डिफ़ॉल्ट/ज़रूरी सेटिंग को शामिल न करना अच्छा होता है. जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए `**kwargs` का इस्तेमाल करना अच्छा होता है. एक्सटेंड किए गए नियमों के मामले में, सभी इनिशलाइज़र को चाइल्ड से लेकर पैरंट तक के क्रम में कॉल किया जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है.
`parent`	डिफ़ॉल्ट रूप से `None` होता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से `executable` और `test` से मेल खाता है. `fragments`, `toolchains`, `exec_compatible_with`, और `exec_groups` की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन `cfg` को, thisrule के इनकमिंग कॉन्फ़िगरेशन के बाद लागू किया जाता है.
`extendable`	bool; या Label; या string; या `None`; डिफ़ॉल्ट तौर पर `None` एक्सपेरिमेंटल: अनुमति वाली सूची का लेबल, जो यह तय करता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि हमेशा एक्सटेंशन की अनुमति दी जा सके या न दी जा सके. Bazel, डिफ़ॉल्ट रूप से एक्सटेंशन को हमेशा अनुमति देता है.
`subrules`	सबनियम का क्रम; डिफ़ॉल्ट रूप से `[]` होता है एक्सपेरिमेंटल: इस नियम में इस्तेमाल किए गए सबनियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

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

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

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

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

सबनियम

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

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

पैरामीटर

पैरामीटर	ब्यौरा
`implementation`	function; required यह सबनियम लागू करने वाला Starlark फ़ंक्शन
`attrs`	dict; डिफ़ॉल्ट तौर पर `{}` होता है यह एक डिक्शनरी है, जिसमें सबनियम के सभी (निजी) एट्रिब्यूट की जानकारी होती है. सबनियमों में सिर्फ़ निजी एट्रिब्यूट हो सकते हैं, जो लेबल-टाइप (जैसे, लेबल या लेबल-लिस्ट) के होते हैं. इन लेबल से जुड़ी हल की गई वैल्यू, Bazel अपने-आप सबनियम के लागू करने वाले फ़ंक्शन में नाम वाले आर्ग्युमेंट के तौर पर भेज देता है. इसलिए, लागू करने वाले फ़ंक्शन को एट्रिब्यूट के नाम से मैच करने वाले नाम वाले पैरामीटर स्वीकार करने होंगे. इन वैल्यू के टाइप ये होंगे: `executable=True` वाले लेबल एट्रिब्यूट के लिए `FilesToRunProvider` `allow_single_file=True` वाले लेबल एट्रिब्यूट के लिए `File` अन्य सभी लेबल एट्रिब्यूट के लिए `Target` सभी लेबल-लिस्ट एट्रिब्यूट के लिए `[Target]`
`toolchains`	sequence; डिफ़ॉल्ट तौर पर `[]` सेट होता है अगर सेट किया जाता है, तो इस सबनियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और `ctx.toolchains` के ज़रिए सबनियम लागू करने के लिए उपलब्ध कराए जाएंगे.
`fragments`	स्ट्रिंग का क्रम; डिफ़ॉल्ट `[]` है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में सबनियम को ज़रूरत होती है.
`subrules`	सबनियम का क्रम; डिफ़ॉल्ट `[]` है इस सबनियम के लिए ज़रूरी अन्य सबनियमों की सूची.

tag_class

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

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

पैरामीटर

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

कैसा दिखाई दे

None visibility(value)

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

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