.bzl फ़ाइलें

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

सदस्य

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

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

aspect

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 फ़ंक्शन है, जो इस आसपेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: Target (वह टारगेट जिस पर आसपेक्ट लागू किया जाता है) और 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 sequence of Aspects; डिफ़ॉल्ट रूप से []
होता है इस आसपेक्ट से पहले, लागू किए जाने वाले आसपेक्ट की सूची.
fragments sequence of strings; डिफ़ॉल्ट रूप से []
होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है.
host_fragments sequence of strings; डिफ़ॉल्ट तौर पर यह []
होता है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी होस्ट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है.
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 sequence of strings; डिफ़ॉल्ट रूप से []
होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची है जो इस आसपेक्ट के सभी इंस्टेंस पर लागू होती हैं
exec_groups dict या None; डिफ़ॉल्ट रूप से None
होता है एक डिक्शनरी, जिसमें एक्ज़ीक्यूशन ग्रुप का नाम (स्ट्रिंग) exec_group में बदला जाता है. अगर यह सेट है, तो आसपेक्ट, एक ही इंस्टेंस में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर ऐक्शन चला सकता है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप का दस्तावेज़ देखें.
subrules sequence of 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 पैरामीटर, depset के डायरेक्ट एलिमेंट की सूची है. वहीं, transitive पैरामीटर, उन depset की सूची है जिनके एलिमेंट, बनाए गए depset के इनडायरेक्ट एलिमेंट बन जाते हैं. depset को सूची में बदलने पर, एलिमेंट किस क्रम में दिखाए जाते हैं, यह order पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, Depsets की खास जानकारी देखें.

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

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

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

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

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

module_extension

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

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

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर होना चाहिए, module_ctx. उपलब्ध रिपॉज़िटरी का सेट तय करने के लिए, फ़ंक्शन को बिल्ड की शुरुआत में एक बार कॉल किया जाता है.
tag_classes डिफ़ॉल्ट रूप से {}
होता है एक्सटेंशन के ज़रिए इस्तेमाल की जाने वाली सभी टैग क्लास की जानकारी देने के लिए डिक्शनरी. यह टैग क्लास के नाम को tag_class ऑब्जेक्ट से मैप करता है.
doc string; या None; डिफ़ॉल्ट रूप से None
होता है मॉड्यूल एक्सटेंशन की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.
environ sequence of strings; डिफ़ॉल्ट तौर पर []
होता है एनवायरमेंट वैरिएबल की वह सूची उपलब्ध कराता है जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.
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 sequence of strings; या 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 एंट्री के लिए, k नाम का एक फ़ील्ड होता है. इसकी वैल्यू v होती है.
अगर init को कॉलबैक किया गया हो, तो सिंबल P को कॉल करने पर, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c को कॉल किया जाता है. दूसरे शब्दों में, P(*args, **kwargs) c(*args, **kwargs) दिखाता है. उदाहरण के लिए,
MyInfo = provider()
m = MyInfo(foo = 1)
, इसे सीधे बना देगा, ताकि m को m.foo == 1 वाला MyInfo इंस्टेंस बनाया जा सके.

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

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

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

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

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

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह ऐक्शन बनाकर, तय किए गए सभी आउटपुट जनरेट करेगा.
test bool; डिफ़ॉल्ट तौर पर unbound
होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test निर्देश का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप एक्ज़ीक्यूटेबल माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. डिफ़ॉल्ट रूप से, इसकी वैल्यू False होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
attrs dict; डिफ़ॉल्ट तौर पर {}
होता है नियम के सभी एट्रिब्यूट की जानकारी देने वाली डिक्शनरी. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन, attrs के साइज़ पर सीमा लगाता है.
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" नाम के टारगेट के लिए, आउटपुट dict {"bin": "%{name}.exe"}, foo.exe नाम के एक आउटपुट को पहले से तय करती है. इसे लागू करने वाले फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.

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

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

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

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

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

exec_compatible_with sequence of strings; डिफ़ॉल्ट रूप से []
होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची है जो इस नियम टाइप के सभी टारगेट पर लागू होती हैं.
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 में बदला जाता है. अगर यह सेट होता है, तो नियमों को एक ही टारगेट में, कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप का दस्तावेज़ देखें.
initializer डिफ़ॉल्ट रूप से None
होता है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है.

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

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

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

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

ऐसे एट्रिब्यूट के लिए **kwargs का इस्तेमाल करना सबसे सही तरीका है जिन्हें हैंडल नहीं किया जाता.

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

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

select

unknown select(x, no_match_error='')

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

पैरामीटर

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

सबनियम

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

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

पैरामीटर

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

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

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

tag_class

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

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

पैरामीटर

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

visibility

None visibility(value)

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

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

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

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

पैरामीटर

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

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

  • "//foo": the package //foo
  • "//foo/...": the package //foo and all of its subpackages.
  • "public" या "private": सभी पैकेज या कोई पैकेज नहीं

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

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

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