.bzl फ़ाइलें

समस्या की शिकायत करें

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

पैसे चुकाकर बने सदस्यों के लिए

• analysis_test_transition
• आसपेक्ट
• configuration_field
• डिप्सेट
• exec_group
• module_extension
• सेवा देने वाली कंपनी
• repository_rule
• नियम
• चुनें
• सब रूल
• tag_class
• विज़िबिलिटी

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

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

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

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

हैश पर आधारित सेट का इस्तेमाल, इटरेशन के दौरान डुप्लीकेट को हटाने के लिए किया जाता है. इसलिए, डिप्सेट के सभी एलिमेंट हैश होने चाहिए. हालांकि, फ़िलहाल सभी कंस्ट्रक्टर में, इस इन्वैरिएंट की लगातार जांच नहीं की जाती. लगातार जांच करने की सुविधा चालू करने के लिए, --inसक्रिय_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	string की क्रम; डिफ़ॉल्ट [] है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कंस्ट्रेंट की सूची.

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	string की क्रम; डिफ़ॉल्ट तौर पर [] एनवायरमेंट वैरिएबल की सूची होती है, जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में किसी एनवायरमेंट वैरिएबल में बदलाव होता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.
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	string या dict या 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	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" में, डायरनेम 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	string की क्रम; डिफ़ॉल्ट रूप से [] उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी नियम के लिए टारगेट कॉन्फ़िगरेशन में ज़रूरत होती है.
host_fragments	string का क्रम; यह डिफ़ॉल्ट रूप से [] उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनके लिए नियम को होस्ट कॉन्फ़िगरेशन में रखना ज़रूरी है.
_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 या 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	string की क्रम; डिफ़ॉल्ट तौर पर यह [] कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची होती है, जिसके लिए टारगेट कॉन्फ़िगरेशन में सब-रुल की ज़रूरत होती है.
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" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "डेटा स्टोर करने की मौजूदा जगह में मौजूद सभी पैकेज" के तौर पर दिखाया जाता है.