.bzl फ़ाइलें

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

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

सदस्य

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

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

पैरामीटर

ब्यौरा

settings

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

आसपेक्ट

Aspect aspect(implementation, attr_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])

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

पैरामीटर

पैरामीटर	ब्यौरा
implementation	ज़रूरी है यह एक Starlark फ़ंक्शन है, जो इस ऐस्पेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: टारगेट (वह टारगेट जिस पर ऐस्पेक्ट लागू किया जाता है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया जाता है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. विश्लेषण के दौरान, इस फ़ंक्शन का आकलन किया जाता है. ऐसा, टारगेट में किसी एस्पेक्ट के हर ऐप्लिकेशन के लिए किया जाता है.
attr_aspects	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] होता है एट्रिब्यूट के नामों की सूची. यह ऐस्पेक्ट, इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के साथ प्रॉपगेट होता है. यहां सामान्य वैल्यू में deps और exports शामिल हैं. सूची में एक स्ट्रिंग "*" भी शामिल हो सकती है, ताकि किसी टारगेट की सभी डिपेंडेंसी के साथ प्रॉपेगेट किया जा सके.
attrs	dict; डिफ़ॉल्ट रूप से {} होता है यह एक डिक्शनरी है, जिसमें आसपेक्ट के सभी एट्रिब्यूट की जानकारी होती है. यह किसी एट्रिब्यूट के नाम को `attr.label` या `attr.string` जैसे एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. आसपेक्ट एट्रिब्यूट, लागू करने वाले फ़ंक्शन के लिए ctx पैरामीटर के फ़ील्ड के तौर पर उपलब्ध होते हैं. _ से शुरू होने वाले इनपुट एट्रिब्यूट की डिफ़ॉल्ट वैल्यू होनी चाहिए. साथ ही, इनका टाइप label या label_list होना चाहिए. साफ़ तौर पर एट्रिब्यूट की जानकारी देने वाले एट्रिब्यूट का टाइप string होना चाहिए. साथ ही, इनमें values पाबंदी का इस्तेमाल किया जाना चाहिए. साफ़ तौर पर बताए गए एट्रिब्यूट, ऐसेपेक्ट को सिर्फ़ उन नियमों के साथ इस्तेमाल करने की पाबंदी लगाते हैं जिनमें पाबंदी के हिसाब से एक ही नाम, टाइप, और मान्य वैल्यू वाले एट्रिब्यूट हों.
required_providers	डिफ़ॉल्ट तौर पर [] होता है इस एट्रिब्यूट की मदद से, ऐसेसपेक्ट को सिर्फ़ उन टारगेट तक सीमित किया जा सकता है जिनके नियमों में, ज़रूरी सेवा देने वाली कंपनियों का विज्ञापन किया जाता है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है. नेस्ट नहीं की गई सेवा देने वाली कंपनियों की सूची, अपने-आप एक सूची में बदल जाएगी. इसका मतलब है कि [FooInfo, BarInfo] की सदस्यता, [[FooInfo, BarInfo]] की सदस्यता में अपने-आप बदल जाएगी. किसी नियम (उदाहरण के लिए, some_rule) को किसी पहलू के लिए टारगेट के तौर पर दिखाने के लिए, some_rule को सेवा देने वाली कम से कम एक ज़रूरी सूची में शामिल सभी कंपनियों का विज्ञापन दिखाना होगा. उदाहरण के लिए, अगर किसी पहलू का required_providers [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] है, तो यह पहलू some_rule टारगेट तब ही देख सकता है, जब some_rule FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों उपलब्ध कराता हो.
required_aspect_providers	डिफ़ॉल्ट तौर पर, इसकी वैल्यू [] होती है इस एट्रिब्यूट की मदद से, इस पहलू से दूसरे पहलुओं की जांच की जा सकती है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है. नेस्ट नहीं की गई सेवा देने वाली कंपनियों की सूची, अपने-आप एक सूची में बदल जाएगी. इसका मतलब है कि [FooInfo, BarInfo] की सदस्यता, [[FooInfo, BarInfo]] की सदस्यता में अपने-आप बदल जाएगी. किसी दूसरे पहलू (जैसे, other_aspect) को इस पहलू के लिए दिखाने के लिए, other_aspect को कम से कम एक सूची में मौजूद सभी प्रोवाइडर की जानकारी देनी होगी. [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] के उदाहरण में, यह एस्पेक्ट other_aspect को सिर्फ़ तब देख सकता है, जब other_aspect में FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों मौजूद हों.
provides	डिफ़ॉल्ट तौर पर [] सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.
requires	ऐस्पेक्ट का क्रम; डिफ़ॉल्ट रूप से [] होता है इस ऐस्पेक्ट से पहले, प्रॉपेगेट किए जाने वाले ऐस्पेक्ट की सूची.
fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में, ऐस्पेक्ट को ज़रूरत होती है.
host_fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी होस्ट कॉन्फ़िगरेशन में, ऐस्पेक्ट को ज़रूरत होती है.
toolchains	sequence; डिफ़ॉल्ट तौर पर [] सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
incompatible_use_toolchain_transition	डिफ़ॉल्ट False है यह विकल्प अब काम नहीं करता. इसे हटा दिया जाना चाहिए.
doc	स्ट्रिंग या None; डिफ़ॉल्ट तौर पर None दस्तावेज़ जनरेट करने वाले टूल से निकाले जा सकने वाले हिस्से की जानकारी.
apply_to_generating_rules	डिफ़ॉल्ट तौर पर, यह वैल्यू False होती है अगर यह वैल्यू 'सही' पर सेट है, तो आउटपुट फ़ाइल पर लागू होने पर, आसपेक्ट आउटपुट फ़ाइल को जनरेट करने वाले नियम पर लागू होगा. उदाहरण के लिए, मान लें कि कोई एस्पेक्ट, एट्रिब्यूट `deps` के ज़रिए ट्रांज़िटिव तौर पर प्रसारित होता है और इसे टारगेट `alpha` पर लागू किया जाता है. मान लें कि `alpha` में `deps = [':beta_output']` है, जहां `beta_output` टारगेट `beta` का एलान किया गया आउटपुट है. मान लें कि `beta` में, `deps` में से एक टारगेट `charlie` है. अगर एस्पेक्ट के लिए `apply_to_generating_rules=True` है, तो एस्पेक्ट `alpha`, `beta`, और `charlie` के ज़रिए प्रसारित होगा. अगर यह False है, तो एस्पेक्ट सिर्फ़ `alpha` पर प्रसारित होगा. डिफ़ॉल्ट रूप से गलत.
exec_compatible_with	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] होता है इस एस्पेक्ट के सभी इंस्टेंस पर लागू होने वाले, एक्सीक्यूशन प्लैटफ़ॉर्म की पाबंदियों की सूची.
exec_groups	dict या None; डिफ़ॉल्ट None एक्सीक्यूशन ग्रुप के नाम (स्ट्रिंग) की डायक्शनरी को exec_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)

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

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

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

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

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

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

module_extension

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

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

पैरामीटर

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

provider

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

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

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

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

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

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

पैरामीटर

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

repository_rule

callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)

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

पैरामीटर

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

नियम

callable rule(implementation, *, test=unbound, attrs={}, outputs=None, executable=unbound, output_to_genfiles=False, fragments=[], host_fragments=[], _skylark_testable=False, toolchains=[], incompatible_use_toolchain_transition=False, doc=None, provides=[], exec_compatible_with=[], analysis_test=False, build_setting=None, cfg=None, exec_groups=None, initializer=None, parent=None, extendable=None, subrules=[])

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

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

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

पैरामीटर

पैरामीटर	ब्यौरा
implementation	ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह एक्शन बनाकर, एलान किए गए सभी आउटपुट जनरेट करेगा.
test	bool; डिफ़ॉल्ट तौर पर unbound होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test कमांड का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप कार्यान्वित माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. डिफ़ॉल्ट रूप से, इसकी वैल्यू False होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
attrs	dict; डिफ़ॉल्ट तौर पर {} नियम के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन, एट्रिब्यूट के साइज़ पर एक सीमा लगाता है.
outputs	dict; या None; या function; डिफ़ॉल्ट None अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इस पर भरोसा न करें. ---incompatible_no_rule_outputs_param के साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपका कोड, जल्द ही हटाए जाने वाले वर्शन के साथ काम करता है. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए नियमों को माइग्रेट करें. पहले से तय किए गए आउटपुट तय करने के लिए स्कीमा. output और output_list एट्रिब्यूट के उलट, उपयोगकर्ता इन फ़ाइलों के लिए लेबल तय नहीं करता. पहले से तय किए गए आउटपुट के बारे में ज़्यादा जानने के लिए, नियमों का पेज देखें. इस आर्ग्युमेंट की वैल्यू, कोई डिक्शनरी या कॉलबैक फ़ंक्शन होती है, जो डिक्शनरी बनाता है. कॉलबैक, कैलकुलेट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच किए जाते हैं. उदाहरण के लिए, अगर आपने परिभाषा def _my_func(srcs, deps): ... के साथ outputs = _my_func पास किया है, तो फ़ंक्शन के पास srcs और deps एट्रिब्यूट का ऐक्सेस होता है. डिक्शनरी को सीधे तौर पर या किसी फ़ंक्शन की मदद से तय करने पर, इसका मतलब इस तरह से निकाला जाता है. डिक्शनरी में हर एंट्री से पहले से तय किया गया आउटपुट बनता है. इसमें, की एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है. इससे आउटपुट का लेबल तय होता है. नियम लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर फ़ील्ड का नाम बन जाता है. इसका इस्तेमाल, ctx.outputs में आउटपुट के File को ऐक्सेस करने के लिए किया जाता है. आउटपुट के लेबल में वही पैकेज होता है जो नियम में होता है. पैकेज के बाद का हिस्सा, "%{ATTR}" फ़ॉर्म के हर प्लेसहोल्डर को एट्रिब्यूट ATTR की वैल्यू से बनाई गई स्ट्रिंग से बदलकर बनाया जाता है: स्ट्रिंग टाइप वाले एट्रिब्यूट की वैल्यू को हूबहू बदल दिया जाता है. लेबल टाइप वाले एट्रिब्यूट, पैकेज के बाद लेबल का हिस्सा बन जाते हैं. हालांकि, इनमें फ़ाइल एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, लेबल "//pkg:a/b.c", "a/b" हो जाता है. पैकेज के बाद, आउटपुट टाइप वाले एट्रिब्यूट, फ़ाइल एक्सटेंशन (ऊपर दिए गए उदाहरण के लिए, "a/b.c") के साथ लेबल का हिस्सा बन जाते हैं. प्लेसहोल्डर में इस्तेमाल किए जाने वाले, सूची वाले सभी एट्रिब्यूट (उदाहरण के लिए, attr.label_list) में एक ही एलिमेंट होना चाहिए. उनका कन्वर्ज़न, उनके नॉन-लिस्ट वर्शन (attr.label) जैसा ही है. ऐसा हो सकता है कि अन्य तरह के एट्रिब्यूट, प्लेसहोल्डर में न दिखें. एट्रिब्यूट के अलावा, खास प्लेसहोल्डर %{dirname} और %{basename}, नियम के लेबल के उन हिस्सों में बड़े हो जाते हैं जिनमें पैकेज शामिल नहीं होता. उदाहरण के लिए, "//pkg:a/b.c" में dirname, a है और basename, b.c है. आम तौर पर, बदले जाने वाले वैल्यू के लिए सबसे ज़्यादा इस्तेमाल होने वाला प्लेसहोल्डर "%{name}" होता है. उदाहरण के लिए, "foo" नाम के टारगेट के लिए, आउटपुट डायक्शनरी {"bin": "%{name}.exe"}, foo.exe नाम के एक आउटपुट को पहले से एलान करती है. इसे लागू करने वाले फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.
executable	bool; डिफ़ॉल्ट रूप से unbound यह तय करता है कि इस नियम को लागू किया जा सकता है या नहीं. इसका मतलब है कि क्या यह blaze run कमांड का विषय हो सकता है. यह डिफ़ॉल्ट रूप से False पर सेट होता है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
output_to_genfiles	डिफ़ॉल्ट रूप से False अगर इसकी वैल्यू 'सही' है, तो फ़ाइलें bin डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है, तो इस फ़्लैग को सेट न करें. उदाहरण के लिए, C++ के लिए हेडर फ़ाइलें जनरेट करते समय.
fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.
host_fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन में नियम के लिए होती है.
_skylark_testable	डिफ़ॉल्ट रूप से False (प्रयोग के तौर पर उपलब्ध) अगर यह 'सही' है, तो यह नियम Actions प्रोवाइडर के ज़रिए, उन नियमों की जांच के लिए अपनी कार्रवाइयों को ज़ाहिर करेगा जो इस नियम पर निर्भर हैं. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध है. इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में, इस फ़्लैग को हटाया जा सकता है.
toolchains	sequence; डिफ़ॉल्ट तौर पर [] सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
incompatible_use_toolchain_transition	डिफ़ॉल्ट False है यह विकल्प अब काम नहीं करता. इसे हटा दिया जाना चाहिए.
doc	string या None; डिफ़ॉल्ट तौर पर None नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.
provides	डिफ़ॉल्ट तौर पर [] सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.
exec_compatible_with	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] होता है लागू करने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची, जो इस तरह के नियम के सभी टारगेट पर लागू होती हैं.
analysis_test	डिफ़ॉल्ट रूप से False अगर यह 'सही' है, तो इस नियम को विश्लेषण टेस्ट के तौर पर माना जाता है. ध्यान दें: विश्लेषण की जांच के नियमों को मुख्य तौर पर, Starlark की मुख्य लाइब्रेरी में दिए गए इन्फ़्रास्ट्रक्चर का इस्तेमाल करके तय किया जाता है. दिशा-निर्देशों के लिए, जांच करना लेख देखें. अगर किसी नियम को विश्लेषण टेस्ट नियम के तौर पर तय किया जाता है, तो उसके एट्रिब्यूट पर analysis_test_transition का इस्तेमाल करके तय किए गए कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल किया जा सकता है. हालांकि, यह कुछ पाबंदियों के साथ काम करता है: इस नियम के टारगेट में, ट्रांज़िशन डिपेंडेंसी की संख्या सीमित होती है. इस नियम को टेस्ट नियम माना जाता है (जैसे कि test=True सेट किया गया हो). यह test की वैल्यू को बदल देता है हो सकता है कि नियम लागू करने वाला फ़ंक्शन कार्रवाइयों को रजिस्टर न कर पाए. इसके बजाय, AnalysisTestResultInfo की मदद से, पास/फ़ेल का नतीजा रजिस्टर करना होगा.
build_setting	BuildSetting या None; डिफ़ॉल्ट तौर पर None अगर यह सेट है, तो यह बताता है कि यह नियम किस तरह का build setting है. config मॉड्यूल देखें. अगर यह सेट है, तो इस नियम में "build_setting_default" नाम का ज़रूरी एट्रिब्यूट अपने-आप जुड़ जाता है. यह एट्रिब्यूट, यहां दी गई वैल्यू के हिसाब से टाइप के साथ जुड़ता है.
cfg	डिफ़ॉल्ट रूप से None अगर सेट किया जाता है, तो कॉन्फ़िगरेशन ट्रांज़िशन को इंगित करता है. विश्लेषण से पहले, नियम अपने कॉन्फ़िगरेशन पर लागू होगा.
exec_groups	dict या None; डिफ़ॉल्ट None एक्सीक्यूशन ग्रुप के नाम (स्ट्रिंग) की डायक्शनरी को exec_groups में बदलता है. अगर यह सेट है, तो नियमों को एक ही टारगेट में कई एक्सीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्सीक्यूशन ग्रुप का दस्तावेज़ देखें.
initializer	डिफ़ॉल्ट रूप से None है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे नियम के मुताबिक तय किए गए पब्लिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है, न कि सामान्य एट्रिब्यूट (उदाहरण के लिए, name या tags) के साथ. यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर None दिखाने पर, एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. किसी एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू से पहले, इनिशिएलाइज़र का आकलन किया जाता है. इसलिए, अगर इनिशलाइज़र के सिग्नेचर में किसी पैरामीटर की डिफ़ॉल्ट वैल्यू मौजूद है, तो वह एट्रिब्यूट की परिभाषा में मौजूद डिफ़ॉल्ट वैल्यू को बदल देती है. हालांकि, None दिखाने पर ऐसा नहीं होता. इसी तरह, अगर किसी पैरामीटर के लिए डिफ़ॉल्ट वैल्यू नहीं दी गई है, तो उसे पैरामीटर के तौर पर इस्तेमाल करना ज़रूरी हो जाएगा. ऐसे मामलों में, एट्रिब्यूट की परिभाषा में डिफ़ॉल्ट/ज़रूरी सेटिंग को शामिल न करना अच्छा होता है. जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए **kwargs का इस्तेमाल करना अच्छा होता है. एक्सटेंड किए गए नियमों के मामले में, सभी इनिशलाइज़र को चाइल्ड से लेकर पैरंट तक के क्रम में कॉल किया जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है.
parent	डिफ़ॉल्ट रूप से None होता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg को, thisrule के इनकमिंग कॉन्फ़िगरेशन के बाद लागू किया जाता है.
extendable	bool; या Label; या string; या None; डिफ़ॉल्ट तौर पर None एक्सपेरिमेंटल: अनुमति वाली सूची का लेबल, जो यह तय करता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि हमेशा एक्सटेंशन की अनुमति दी जा सके या न दी जा सके. Bazel, डिफ़ॉल्ट रूप से एक्सटेंशन को हमेशा अनुमति देता है.
subrules	सबनियम का क्रम; डिफ़ॉल्ट रूप से [] होता है एक्सपेरिमेंटल: इस नियम में इस्तेमाल किए गए सबनियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

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

सबनियम

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

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

पैरामीटर

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

tag_class

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

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

पैरामीटर

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

कैसा दिखाई दे

None visibility(value)

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

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

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

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

पैरामीटर

पैरामीटर

ब्यौरा

value

ज़रूरी है पैकेज की जानकारी देने वाली स्ट्रिंग की सूची या पैकेज की जानकारी देने वाली एक स्ट्रिंग. पैकेज की खास बातों के लिए, वही फ़ॉर्मैट इस्तेमाल किया जाता है जो package_group के लिए इस्तेमाल किया जाता है. हालांकि, पैकेज की नेगेटिव खास बातों की अनुमति नहीं है. इसका मतलब है कि स्पेसिफ़िकेशन में ये फ़ॉर्म हो सकते हैं: "//foo": पैकेज //foo "//foo/...": पैकेज //foo और उसके सभी सब-पैकेज. "public" या "private": सभी पैकेज या कोई पैकेज नहीं "@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के रिपॉज़िटरी के हिसाब से समझा जाता है. अगर value, स्ट्रिंग की सूची है, तो इस मॉड्यूल को दिखाए जाने की अनुमति वाले पैकेज का सेट, हर स्पेसिफ़िकेशन से दिखाए गए पैकेज का यूनियन होता है. (खाली सूची का असर वैसा ही होता है जैसा private का होता है.) अगर value एक स्ट्रिंग है, तो उसे सिंगलटन सूची [value] माना जाता है. ध्यान दें कि फ़्लैग --incompatible_package_group_has_public_syntax और --incompatible_fix_package_group_reporoot_syntax का इस आर्ग्युमेंट पर कोई असर नहीं पड़ता. "public" और "private" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.