.bzl फ़ाइलें

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

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

सदस्य

• analysis_test_transition
• aspect
• configuration_field
• depset
• exec_group
• exec_transition
• 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=[], 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	function; ज़रूरी है यह एक Starlark फ़ंक्शन है, जो इस ऐस्पेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: Target (वह टारगेट जिस पर ऐस्पेक्ट लागू किया जाता है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया जाता है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. विश्लेषण के दौरान, इस फ़ंक्शन का आकलन किया जाता है. ऐसा, टारगेट में किसी एस्पेक्ट के हर ऐप्लिकेशन के लिए किया जाता है.
attr_aspects	स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] होता है एट्रिब्यूट के नामों की सूची. यह पहलू इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के हिसाब से लागू होता है. यहां सामान्य वैल्यू में deps और exports शामिल हैं. सूची में एक स्ट्रिंग "*" भी शामिल हो सकती है, ताकि किसी टारगेट की सभी डिपेंडेंसी के साथ प्रॉपेगेट किया जा सके.
toolchains_aspects	sequence; डिफ़ॉल्ट तौर पर [] टूलचेन के टाइप की सूची. यह ऐस्पेक्ट, उन टारगेट टूलचेन पर लागू होता है जो इन टूलचेन टाइप से मेल खाते हैं.
attrs	dict; डिफ़ॉल्ट रूप से {} होता है यह एक डिक्शनरी है, जिसमें आसपेक्ट के सभी एट्रिब्यूट की जानकारी होती है. यह एट्रिब्यूट के नाम को attr.label या attr.string जैसे एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. आसपेक्ट एट्रिब्यूट, ctx पैरामीटर के फ़ील्ड के तौर पर लागू करने के लिए उपलब्ध हैं. _ से शुरू होने वाले इनपुट एट्रिब्यूट की डिफ़ॉल्ट वैल्यू होनी चाहिए. साथ ही, इनका टाइप label या label_list होना चाहिए. एक्सप्लिसिट एट्रिब्यूट के लिए string टाइप का होना ज़रूरी है. साथ ही, इनके लिए values पाबंदी का इस्तेमाल किया जाना चाहिए. साफ़ तौर पर बताए गए एट्रिब्यूट, ऐसेपेक्ट को सिर्फ़ उन नियमों के साथ इस्तेमाल करने की पाबंदी लगाते हैं जिनमें पाबंदी के हिसाब से एक ही नाम, टाइप, और मान्य वैल्यू वाले एट्रिब्यूट हों. एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
required_providers	sequence; डिफ़ॉल्ट [] है इस एट्रिब्यूट की मदद से, एस्पेक्ट को सिर्फ़ उन टारगेट तक सीमित किया जा सकता है जिनके नियमों में, ज़रूरी सेवा देने वाली कंपनियों का विज्ञापन किया जाता है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[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	sequence; डिफ़ॉल्ट तौर पर [] होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, आसपेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी होता है.
requires	ऐस्पेक्ट का क्रम; डिफ़ॉल्ट रूप से [] होता है इस ऐस्पेक्ट से पहले, प्रॉपगेट किए जाने वाले ऐस्पेक्ट की सूची.
fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में, ऐस्पेक्ट को ज़रूरत होती है.
host_fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी होस्ट कॉन्फ़िगरेशन में, ऐस्पेक्ट को ज़रूरत होती है.
toolchains	क्रम; [] डिफ़ॉल्ट तौर पर सेट होता है. अगर यह सेट है, तो इस पहलू के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए, ऐस्पेक्ट को लागू करने के लिए उपलब्ध कराए जाएंगे.
incompatible_use_toolchain_transition	bool; डिफ़ॉल्ट तौर पर False होता है इस्तेमाल नहीं किया जा सकता. इसे हटा दिया जाना चाहिए.
doc	स्ट्रिंग या None; डिफ़ॉल्ट तौर पर None दस्तावेज़ जनरेट करने वाले टूल से निकाले जा सकने वाले हिस्से की जानकारी.
apply_to_generating_rules	bool; डिफ़ॉल्ट तौर पर False है अगर यह सही है, तो आस्पेक्ट को आउटपुट फ़ाइल पर लागू करने पर, वह आउटपुट फ़ाइल को जनरेट करने वाले नियम पर लागू होगा. उदाहरण के लिए, मान लें कि कोई पहलू `deps` विशेषता के माध्यम से ट्रांज़िटिव रूप से फैलता है और इसे `अल्फ़ा` को लक्षित करने पर लागू किया जाता है. मान लीजिए `अल्फ़ा` में `deps = [':beta_input']` में, जहां `beta_Output` एक लक्ष्य `बीटा` का घोषित आउटपुट है. मान लीजिए कि `बीटा` में लक्ष्य `charley` के रूप में एक `deps (बीटा)` है. अगर यह पहलू ` अपग्रेड_बीटा` में लागू होगा, तो फ़िल्म को इस पक्ष को लागू करने में `सही_ जाएगी. {/4} डिफ़ॉल्ट रूप से गलत.
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) एक्सप्रेशन से मिला है.

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

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

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

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

exec_transition

transition exec_transition(implementation, inputs, outputs)

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

पैरामीटर

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

module_extension

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

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

पैरामीटर

पैरामीटर	ब्यौरा
implementation	callable; required यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. एक पैरामीटर होना ज़रूरी है, module_ctx. बिल्ड की शुरुआत में इस फ़ंक्शन को एक बार कॉल किया जाता है, ताकि उपलब्ध डेटा स्टोर करने की जगहों का सेट तय किया जा सके.
tag_classes	dict; डिफ़ॉल्ट रूप से {} होता है यह एक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास की जानकारी देने वाली डिक्शनरी है. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट पर मैप करता है.
doc	string या None; डिफ़ॉल्ट तौर पर None मॉड्यूल एक्सटेंशन की जानकारी होती है. इसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है.
environ	string की क्रम; डिफ़ॉल्ट तौर पर [] एनवायरमेंट वैरिएबल की सूची होती है, जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.
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	स्ट्रिंग या 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)

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

पैरामीटर

पैरामीटर	ब्यौरा
implementation	callable; ज़रूरी है यह वह फ़ंक्शन है जो इस नियम को लागू करता है. इसमें एक पैरामीटर, repository_ctx होना चाहिए. नियम के हर इंस्टेंस के लिए, फ़ंक्शन को लोड होने के दौरान कॉल किया जाता है.
attrs	dict या None; डिफ़ॉल्ट रूप से None एक डिक्शनरी है, जो डेटा स्टोर करने के नियम की सभी विशेषताओं के बारे में बताता है. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल के लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटा स्टोर करने का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं कर सकता. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती. एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
local	bool; डिफ़ॉल्ट False है यह बताएं कि यह नियम, स्थानीय सिस्टम से सभी चीज़ें फ़ेच करता है और हर फ़ेच के बाद, इसका फिर से आकलन किया जाना चाहिए.
environ	string का क्रम; यह डिफ़ॉल्ट [] अब काम नहीं करता है. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, 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=[], dependency_resolution_rule=False, 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	function; ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. नियम के हर इंस्टेंस के लिए, विश्लेषण के दौरान फ़ंक्शन को कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. सभी एलान किए गए आउटपुट जनरेट करने के लिए, इसमें कार्रवाइयां बनाई जानी चाहिए.
test	bool; डिफ़ॉल्ट तौर पर unbound होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test कमांड का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप कार्यान्वित माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. यह वैल्यू, डिफ़ॉल्ट तौर पर False पर सेट होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
attrs	dict; डिफ़ॉल्ट तौर पर {} नियम के सभी एट्रिब्यूट की जानकारी देने वाली डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल किसी लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, एट्रिब्यूट की संख्या तय की गई है. एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
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" में, Direname a और बेसनेम b.c है. व्यावहारिक रूप से, सबसे आम प्रतिस्थापन प्लेसहोल्डर "%{name}" है. उदाहरण के लिए, "foo" नाम के टारगेट के लिए, आउटपुट डायक्शनरी {"bin": "%{name}.exe"}, foo.exe नाम के एक आउटपुट को पहले से एलान करता है. इसे लागू करने वाले फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.
executable	bool; डिफ़ॉल्ट रूप से unbound यह तय करता है कि इस नियम को लागू किया जा सकता है या नहीं. इसका मतलब है कि क्या यह blaze run कमांड का विषय हो सकता है. यह डिफ़ॉल्ट रूप से False पर सेट होता है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
output_to_genfiles	bool; डिफ़ॉल्ट तौर पर, इसकी वैल्यू False होती है अगर इसकी वैल्यू 'सही' है, तो फ़ाइलें bin डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है, तो इस फ़्लैग को सेट न करें. उदाहरण के लिए, C++ के लिए हेडर फ़ाइलें जनरेट करते समय.
fragments	स्ट्रिंग का क्रम; डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.
host_fragments	string की क्रम; डिफ़ॉल्ट रूप से [] उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी नियम के लिए होस्ट कॉन्फ़िगरेशन में ज़रूरत होती है.
_skylark_testable	bool; डिफ़ॉल्ट रूप से False पर सेट है (प्रयोग के तौर पर उपलब्ध) अगर सही है, तो यह नियम उन नियमों के मुताबिक जांच के लिए अपनी कार्रवाइयां दिखाएगा जो Actions की सेवा देने वाली कंपनी के ज़रिए इस पर निर्भर करते हैं. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध है. इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में, इस फ़्लैग को हटाया जा सकता है.
toolchains	sequence; डिफ़ॉल्ट तौर पर [] सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
incompatible_use_toolchain_transition	bool; डिफ़ॉल्ट तौर पर False होता है इस्तेमाल नहीं किया जा सकता. इसे हटा दिया जाना चाहिए.
doc	string या None; डिफ़ॉल्ट तौर पर None नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.
provides	क्रम; डिफ़ॉल्ट रूप से [] सेवा देने वाली कंपनियों की ऐसी सूची है जिसे लागू करने वाले फ़ंक्शन को लौटाना ज़रूरी है. अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.
dependency_resolution_rule	bool; डिफ़ॉल्ट तौर पर False होता है अगर सेट किया जाता है, तो नियम, एट्रिब्यूट के ज़रिए डिपेंडेंसी हो सकता है. साथ ही, इसे मटीरियलाइज़र में उपलब्ध के तौर पर भी मार्क किया जा सकता है. इस फ़्लैग के साथ सेट किए गए नियमों के हर एट्रिब्यूट को, मेटालिज़र में भी उपलब्ध के तौर पर मार्क किया जाना चाहिए. ऐसा इसलिए है, ताकि मार्क किए गए नियम, मार्क नहीं किए गए नियमों पर निर्भर न हों.
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 है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे name और नियम के मुताबिक तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है, न कि जेनरिक एट्रिब्यूट (उदाहरण के लिए, tags) के साथ. यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती उन पर कोई असर नहीं पड़ता. None को वैल्यू के तौर पर रिटर्न करने पर, एट्रिब्यूट की परिभाषा में बताए गए डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. किसी एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू से पहले, इनिशिएलाइज़र का आकलन किया जाता है. ऐसे में, अगर शुरू करने वाले के हस्ताक्षर में मौजूद किसी पैरामीटर में डिफ़ॉल्ट वैल्यू है, तो वह एट्रिब्यूट की परिभाषा (अगर None है, तो) को छोड़कर, डिफ़ॉल्ट वैल्यू को बदल देती है. इसी तरह, अगर शुरू करने वाले के हस्ताक्षर में कोई पैरामीटर डिफ़ॉल्ट नहीं है, तो पैरामीटर ज़रूरी हो जाएगा. ऐसे मामलों में, एट्रिब्यूट की परिभाषा में डिफ़ॉल्ट/ज़रूरी सेटिंग को हटाना अच्छा होता है. जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए **kwargs का इस्तेमाल करना अच्छा होता है. एक्सटेंड किए गए नियमों के मामले में, सभी इनिशलाइज़र को चाइल्ड से लेकर पैरंट तक के क्रम में कॉल किया जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है.
parent	डिफ़ॉल्ट तौर पर यह None है एक्सपेरिमेंटल: स्टैलार्क नियम बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद पैरंट कॉन्फ़िगरेशन से जुड़ा cfg ट्रांज़िशन लागू किया गया है.
extendable	bool; या Label; या string; या None; डिफ़ॉल्ट तौर पर None एक्सपेरिमेंटल: अनुमति वाली सूची का लेबल, जो यह तय करता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि समयसीमा बढ़ाने की अनुमति हमेशा दी जा सके या हमेशा से रोकी जा सके. Bazel, डिफ़ॉल्ट रूप से एक्सटेंशन को हमेशा अनुमति देता है.
subrules	सबनियम का क्रम; डिफ़ॉल्ट रूप से [] होता है एक्सपेरिमेंटल: इस नियम में इस्तेमाल किए गए सबनियमों की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

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

सबनियम

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

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

पैरामीटर

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

tag_class

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

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

पैरामीटर

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