.bzl फ़ाइलें

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

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

सदस्य

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

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

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

आसपेक्ट

Aspect aspect(implementation, attr_aspects=[], toolchains_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 शामिल हैं. टारगेट की सभी डिपेंडेंसी के हिसाब से, सूची में एक स्ट्रिंग "*" भी हो सकती है.
toolchains_aspects	क्रम; डिफ़ॉल्ट रूप से [] है प्रयोग के तौर पर: टूलचेन के टाइप की सूची. यह पहलू इन टूलचेन टाइप से मेल खाने वाले टारगेट टूलचेन में लागू होता है.
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	bool; डिफ़ॉल्ट रूप से False है अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए. अब यह काम नहीं कर रहा है.
doc	string; या None; डिफ़ॉल्ट रूप से None है उस पहलू के बारे में जानकारी जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.
apply_to_generating_rules	bool; डिफ़ॉल्ट रूप से False है अगर सही है, तो आउटपुट फ़ाइल पर लागू किया जाएगा. इसके बजाय, उस आसपेक्ट को आउटपुट फ़ाइल के जनरेट करने के नियम पर लागू किया जाएगा. उदाहरण के लिए, मान लें कि कोई पहलू `deps` के ज़रिए ट्रांज़िट तरीके से फैलता है और इसे `ऐल्फ़ा` को टारगेट करने पर लागू किया जाता है. मान लीजिए कि `ऐल्फ़ा` में `deps = [':beta_Output']` है, जहां `beta_Output` किसी टारगेट `बीटा` का एलान किया गया आउटपुट है. मान लीजिए कि `बीटा` का लक्ष्य `चार्ली` अपने एक `डेप्स` के रूप में है. अगर पहलू के लिए `apply_to_generting_rules=True` लागू होता है, तो पक्ष `अल्फ़ा`, `बीटा` और `चार्ली` के ज़रिए फैल जाएगा. अगर गलत है, तो आसपेक्ट रेशियो सिर्फ़ `ऐल्फ़ा` में चलेगा. डिफ़ॉल्ट रूप से 'गलत'.
exec_compatible_with	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट [] है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस पहलू के सभी इंस्टेंस पर लागू होती है.
exec_groups	dict; या None; डिफ़ॉल्ट रूप से None है exec_groups तक ग्रुप के नाम (स्ट्रिंग) को एक्ज़ीक्यूट करने की सुविधा. अगर नीति को सेट किया जाता है, तो इससे आसपेक्ट को एक ही इंस्टेंस में, इसे लागू करने वाले कई प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, लागू किए जाने वाले ग्रुप का दस्तावेज़ देखें.
subrules	सबरूल का क्रम; डिफ़ॉल्ट [] है प्रयोग के तौर पर: इस पहलू के लिए इस्तेमाल किए गए सबनियमों की सूची.

configuration_field

LateBoundDefault configuration_field(fragment, name)

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

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

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

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

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

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

पैरामीटर

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

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	string; डिफ़ॉल्ट रूप से "default" है नए डिपसेट के लिए ट्रैवर्सल रणनीति. संभावित वैल्यू के लिए यहां देखें.
transitive	डिप्सेट का सीक्वेंस; या None; डिफ़ॉल्ट None है ऐसे डेपसेट की सूची जिनके एलिमेंट, डिप्सेट के इनडायरेक्ट एलिमेंट बन जाएंगे.

exec_group

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

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

पैरामीटर

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

exec_transition

transition exec_transition(implementation, inputs, outputs)

transition() का एक खास वर्शन, जिसका इस्तेमाल एक्ज़ीक्यूशन ट्रांज़िशन के बारे में बताने के लिए किया जाता है. सबसे सही तरीकों के बारे में जानने के लिए, इसके दस्तावेज़ या इसे लागू करने का तरीका देखें. इस सुविधा का इस्तेमाल सिर्फ़ Basel बिल्टइन के साथ किया जा सकता है.

पैरामीटर

पैरामीटर	ब्यौरा
implementation	कॉल करने लायक; ज़रूरी है
inputs	स्ट्रिंग का सीक्वेंस; ज़रूरी है
outputs	स्ट्रिंग का सीक्वेंस; ज़रूरी है

module_extension

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

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

पैरामीटर

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

provider

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

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

MyInfo = provider()
...
def _my_library_impl(ctx):
    ...
    my_info = MyInfo(x = 2, y = 3)
    # my_info.x == 2
    # my_info.y == 3
    ...

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

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

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

पैरामीटर

पैरामीटर	ब्यौरा
doc	string; या None; डिफ़ॉल्ट रूप से None है दस्तावेज़ जनरेट करने वाले टूल की मदद से, सेवा देने वाली कंपनी के बारे में जानकारी.
fields	स्ट्रिंग का सीक्वेंस; या शब्दकोश; या None; डिफ़ॉल्ट None है अगर तय किया गया है, तो अनुमति वाले फ़ील्ड के सेट को सीमित करता है. संभावित मान ये हैं: फ़ील्ड की सूची: provider(fields = ['a', 'b']) शब्दकोश फ़ील्ड का नाम -> दस्तावेज़: provider( fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' }) सभी फ़ील्ड ज़रूरी नहीं हैं.
init	कॉल करने लायक; या 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)

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

पैरामीटर

पैरामीटर	ब्यौरा
implementation	कॉल करने लायक; ज़रूरी है वह फ़ंक्शन जो इस नियम को लागू करता है. एक ही पैरामीटर होना चाहिए, repository_ctx. नियम के हर इंस्टेंस के लिए, फ़ंक्शन को लोड होने के दौरान कॉल किया जाता है.
attrs	dict; या None; डिफ़ॉल्ट रूप से None है शब्दकोश का इस्तेमाल करें. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल के लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटा स्टोर करने का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं कर सकता. name विशेषता को निहित रूप से जोड़ा गया है और उसे बताया नहीं जाना चाहिए.
local	bool; डिफ़ॉल्ट रूप से False है इससे पता चलता है कि इस नियम के तहत लोकल सिस्टम से सब कुछ फ़ेच किया जाता है. साथ ही, हर बार फ़ेच करने पर इसका फिर से आकलन किया जाना चाहिए.
environ	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट [] है अब काम नहीं करता. यह पैरामीटर अब काम नहीं करता. इसके बजाय, repository_ctx.getenv पर माइग्रेट करें. इससे एनवायरमेंट वैरिएबल की ऐसी सूची मिलती है जिस पर डेटा स्टोर करने की जगह का यह नियम निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो रिपॉज़िटरी को फिर से लाया जाएगा.
configure	bool; डिफ़ॉल्ट रूप से False है इससे पता चलता है कि डेटा स्टोर करने की जगह, कॉन्फ़िगरेशन के लिए सिस्टम की जांच करती है
remotable	bool; डिफ़ॉल्ट रूप से 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 एट्रिब्यूट को किसी और तरीके से जोड़ा गया है और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, सिर्फ़ कुछ एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, एलान किए जा सकने वाले एट्रिब्यूट की संख्या की सीमा तय की गई है.
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	bool; डिफ़ॉल्ट रूप से False है अगर सही है, तो फ़ाइलें बिन डायरेक्ट्री के बजाय genfile की डायरेक्ट्री में जनरेट की जाएंगी. जब तक आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत न हो (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय), तब तक इस फ़्लैग को सेट न करें.
fragments	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.
host_fragments	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी नियम के लिए होस्ट कॉन्फ़िगरेशन में ज़रूरत होती है.
_skylark_testable	bool; डिफ़ॉल्ट रूप से False है (प्रयोग के तौर पर उपलब्ध) अगर यह नियम सही है, तो इस नियम के तहत, Actions की सेवा देने वाली कंपनी के नियमों के हिसाब से, जांच के लिए कार्रवाइयां की जाएंगी. सेवा देने वाली कंपनी, ctx.created_actions() को कॉल करके अपने नियम खुद भी उपलब्ध करा सकती है. इसका इस्तेमाल सिर्फ़ Starlark के नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में इस फ़्लैग को हटाया जा सकता है.
toolchains	क्रम; डिफ़ॉल्ट रूप से [] है अगर सेट हो, तो इस नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, इसे ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराया जाएगा.
incompatible_use_toolchain_transition	bool; डिफ़ॉल्ट रूप से False है अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए. अब यह काम नहीं कर रहा है.
doc	string; या None; डिफ़ॉल्ट रूप से None है नियम के बारे में जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.
provides	क्रम; डिफ़ॉल्ट रूप से [] है उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना ज़रूरी है. अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने का फ़ंक्शन ऐसी अतिरिक्त कंपनियां दिखा सकता है जो यहां नहीं दी गई हैं. सूची का हर एलिमेंट, provider() से मिला एक *Info ऑब्जेक्ट है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के टारगेट का इस्तेमाल, किसी ऐसे टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है जो ज़रूरी कंपनी के बारे में बताता है, तो यहां उस प्रोवाइडर के बारे में बताना ज़रूरी नहीं है. इतना काफ़ी होता है कि लागू करने वाला फ़ंक्शन इसे लौटाता है. हालांकि, इसे इस्तेमाल करना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, आसपेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी होता है.
exec_compatible_with	स्ट्रिंग का सीक्वेंस; डिफ़ॉल्ट [] है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस नियम के टाइप के सभी टारगेट पर लागू होती है.
analysis_test	bool; डिफ़ॉल्ट रूप से 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; या लेबल; या स्ट्रिंग; या None; डिफ़ॉल्ट None है प्रयोग के तौर पर: अनुमति वाली सूची का लेबल, जिससे यह तय होता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अनुमति न देने के लिए, इसे 'सही/गलत' पर भी सेट किया जा सकता है. Basel को डिफ़ॉल्ट रूप से, एक्सटेंशन को अनुमति देने की सुविधा मिलती है.
subrules	सबरूल का क्रम; डिफ़ॉल्ट [] है प्रयोगात्मक: इस नियम द्वारा उपयोग किए जाने वाले उप-नियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

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

सबरुल

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	dict; डिफ़ॉल्ट रूप से {} है इस टैग क्लास के सभी एट्रिब्यूट के बारे में जानकारी देने के लिए डिक्शनरी. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (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" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.