.bzl फ़ाइलें

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

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

पैसे चुकाकर बने सदस्य

analysis_test_transition

transition analysis_test_transition(settings)

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

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

पैरामीटर

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

आसपेक्ट

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

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

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
Starlark फ़ंक्शन, जो इस आसपेक्ट को लागू करने वाले दो पैरामीटर के साथ काम करता है: टारगेट (वह टारगेट जिस पर आसपेक्ट रेशियो लागू किया गया है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया गया है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. इस फ़ंक्शन का आकलन, विश्लेषण के दौरान किया जाता है. ऐसा, टारगेट पर लागू होने वाले हर पहलू के ऐप्लिकेशन के लिए किया जाता है.
attr_aspects स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से यह []
एट्रिब्यूट के नामों की सूची है. यह आसपेक्ट, इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के साथ लागू होती है. यहां सामान्य वैल्यू में 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 क्रम; डिफ़ॉल्ट रूप से [] सेट होता है
अगर यह सेट किया जाता है, तो इस नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. इन्हें किसी भी कॉम्बिनेशन में शामिल किया जा सकता है. टूल चेन मौजूदा प्लैटफ़ॉर्म की जांच करने पर मिलेगी और नियम लागू करने के लिए ctx.toolchain की मदद से उन्हें उपलब्ध कराया जाएगा.
incompatible_use_toolchain_transition डिफ़ॉल्ट तौर पर यह False पर सेट है
अब सेवा में नहीं है. इसका इस्तेमाल नहीं किया जा सकता. इसलिए, इसे हटा देना चाहिए.
doc string; या None; डिफ़ॉल्ट तौर पर None होता है
पहलू की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है.
apply_to_generating_rules डिफ़ॉल्ट तौर पर यह False पर सेट होता है
अगर विकल्प सही है, तो आउटपुट फ़ाइल पर लागू किए जाने पर, यह आउटपुट फ़ाइल को जनरेट करने के नियम पर लागू होगा.

उदाहरण के लिए, मान लें कि कोई आसपेक्ट, `deps` विशेषता के ज़रिए ट्रांज़िट रूप से लागू होता है और `ऐल्फ़ा` को टारगेट करने पर इसे लागू किया जाता है. मान लीजिए कि `ऐल्फ़ा` में `deps = [':beta_return']`, जहां `बीटा_आउटपुट` टारगेट `बीटा` का एलान किया गया आउटपुट है. मान लीजिए कि `बीटा` में कोई टारगेट `चार्ली` है, तो यह आसपेक्ट के ज़रिए लागू होगा.

डिफ़ॉल्ट रूप से 'गलत'.

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)

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

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

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

इसके अलावा, यह ज़रूरी है कि एलिमेंट ऐसे हों जिन्हें बदला न जा सके. हालांकि, आने वाले समय में इस पाबंदी में छूट दी जाएगी.

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

पैरामीटर

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

exec_group

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

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

पैरामीटर

पैरामीटर ब्यौरा
toolchains क्रम; डिफ़ॉल्ट तौर पर [] होता है
इस निष्पादन ग्रुप के लिए ज़रूरी टूलचेन का सेट. सूची में स्ट्रिंग, लेबल या 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 string; या None; डिफ़ॉल्ट रूप से None पर सेट होता है
मॉड्यूल एक्सटेंशन का ब्यौरा, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है.
environ स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से [] है
एनवायरमेंट वैरिएबल की सूची देता है, जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.
os_dependent डिफ़ॉल्ट पर सेट है False
इससे पता चलता है कि यह एक्सटेंशन, ओएस पर निर्भर करता है या नहीं
arch_dependent डिफ़ॉल्ट पर सेट है False
इससे पता चलता है कि यह एक्सटेंशन, आर्किटेक्चर पर निर्भर है या नहीं

कंपनी

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 स्ट्रिंग या dict का क्रम; या None; डिफ़ॉल्ट रूप से None
होता है. अगर बताया गया है, तो अनुमति वाले फ़ील्ड के सेट को प्रतिबंधित करता है.
संभावित मान ये हैं:
  • फ़ील्ड की सूची:
    provider(fields = ['a', 'b'])

  • शब्दकोश फ़ील्ड का नाम -> दस्तावेज़:
    provider(
           fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })
सभी फ़ील्ड ज़रूरी नहीं हैं.
init कॉल करने लायक; या None; डिफ़ॉल्ट तौर पर सेट है None
प्री-प्रोसेसिंग के लिए एक वैकल्पिक कॉलबैक और इंस्टैंशिएट करने के दौरान, प्रोवाइडर के फ़ील्ड वैल्यू की पुष्टि करें. अगर init बताया गया है, तो provider() दो एलिमेंट का टपल दिखाता है: नॉर्मल प्रोवाइडर सिंबल और रॉ कंस्ट्रक्टर.

इसके बारे में सटीक जानकारी दी गई है. बेहतर तरीके से चर्चा करने और इस्तेमाल के उदाहरणों के लिए, नियम (सेवा देने वाली कंपनियों को पसंद के मुताबिक बनाना) देखें.

P को provider() को कॉल करके सेवा देने वाला सिंबल बनाएं. सैद्धान्तिक तौर पर, P का इंस्टेंस, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c(*args, **kwargs) को कॉल करके जनरेट होता है, जो ये काम करता है:

  • अगर args खाली नहीं है, तो गड़बड़ी होती है.
  • अगर provider() को कॉल करते समय fields पैरामीटर दिया गया था और kwargs में कोई ऐसी कुंजी है जो fields में शामिल नहीं थी, तो गड़बड़ी होती है.
  • ऐसा न करने पर, c एक नया इंस्टेंस दिखाता है, जिसमें kwargs की हर k: v एंट्री के लिए, v वैल्यू वाले k नाम का फ़ील्ड होता है.
अगर init कॉलबैक नहीं दिया गया है, तो P सिंबल पर किया गया कॉल, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c के लिए कॉल के तौर पर काम करता है. दूसरे शब्दों में, P(*args, **kwargs) c(*args, **kwargs) देता है. उदाहरण के लिए,
MyInfo = provider()
m = MyInfo(foo = 1)
इसे सीधे तौर पर बना देगा, ताकि m, m.foo == 1 के साथ MyInfo इंस्टेंस हो.

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

  1. कॉलबैक को init(*args, **kwargs) के तौर पर शुरू किया जाता है. इसका मतलब है कि इसमें ठीक वैसा ही पोज़िशनल और कीवर्ड आर्ग्युमेंट इस्तेमाल किया जाता है जैसा P को पास किया गया था.
  2. init की रिटर्न वैल्यू एक डिक्शनरी, d होनी चाहिए. इसकी कुंजियां फ़ील्ड के नाम वाली स्ट्रिंग होती हैं. अगर ऐसा नहीं है, तो गड़बड़ी होती है.
  3. d की एंट्री के साथ, डिफ़ॉल्ट कंस्ट्रक्टर को कॉल करके, P का नया इंस्टेंस जनरेट किया जाता है, जैसे कि c(**d) में.

ध्यान दें: ऊपर दिए गए तरीके के मुताबिक, अगर *args या **kwargs, init के सिग्नेचर से मेल नहीं खाते हैं या init के मुख्य हिस्से की जांच नहीं हो पाती है (शायद fail() पर कॉल करके), या init की रिटर्न वैल्यू, स्कीमा के हिसाब से सही डिक्शनरी नहीं है, तो ऐसा होता है.

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

जब init तय किया जाता है, तो provider() की रिटर्न वैल्यू टपल (P, r) बन जाती है. इसमें r रॉ कंस्ट्रक्टर है. r का व्यवहार, ऊपर बताए गए डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c के जैसा ही है. आम तौर पर, r एक ऐसे वैरिएबल से जुड़ा होता है जिसके नाम के आगे अंडरस्कोर मौजूद होता है. ऐसा इसलिए, ताकि सिर्फ़ मौजूदा .bzl फ़ाइल से ही उसे ऐक्सेस किया जा सके:

MyInfo, _new_myinfo = provider(init = ...)

repository_rule

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

डेटा स्टोर करने की जगह का नया नियम बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे लोड किया जा सके और 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 एट्रिब्यूट को साफ़ तौर पर जोड़ा गया है और उसे बदला नहीं जा सकता. ज़्यादातर नियमों में कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन attrs के साइज़ पर कैप लागू करता है.
outputs dict; या None; या फ़ंक्शन; डिफ़ॉल्ट रूप से 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" में, दिशा नाम a है और बेसनाम b.c है.

व्यावहारिक रूप से, सबसे सामान्य प्रतिस्थापन प्लेसहोल्डर "%{name}" है. उदाहरण के लिए, "foo" नाम के टारगेट के लिए, आउटपुट डिक्शनरी {"bin": "%{name}.exe"}, foo.exe नाम के आउटपुट के बारे में पहले से बताती है. इसे लागू करने वाले फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.

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

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

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

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

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

exec_compatible_with स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से []
एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची होती है जो इस नियम के सभी टारगेट पर लागू होती हैं.
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
पर सेट होता है एक्सपेरिमेंटल: ऐसा स्टैलार्क नियम, जिसे बढ़ाया गया है. सेट किए जाने पर सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट फ़ोल्डर के executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज कर दी गई हैं. लेगसी या अब काम नहीं करने वाले पैरामीटर सेट नहीं किए जा सकते.
extendable bool; या लेबल; या स्ट्रिंग; या None; डिफ़ॉल्ट है None
प्रयोग के तौर पर उपलब्ध: अनुमति वाली सूची का लेबल, जो तय करता है कि कौनसे नियम इस नियम का दायरा बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अस्वीकार करने के लिए, इसे सही/गलत पर भी सेट किया जा सकता है. Bazel डिफ़ॉल्ट रूप से, एक्सटेंशन को हमेशा अनुमति देता है.
subrules उप-नियम का क्रम; डिफ़ॉल्ट तौर पर []
एक्सपेरिमेंटल: इस नियम के लिए इस्तेमाल किए गए सब-नियम की सूची.

चुनें

unknown select(x, no_match_error='')

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

पैरामीटर

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

सबरूल

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

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

पैरामीटर

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

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

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

tag_class

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

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

पैरामीटर

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