.bzl फ़ाइलें

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

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

सदस्य

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 string; या None; डिफ़ॉल्ट तौर पर यह None
होता है. इससे दस्तावेज़ जनरेट करने वाले टूल की मदद से तैयार किए गए पहलू के बारे में जानकारी मिलती है.
apply_to_generating_rules डिफ़ॉल्ट तौर पर, यह वैल्यू 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 ज़रूरी है
उस कॉन्फ़िगरेशन फ़्रैगमेंट का नाम जिसमें लेट-बाउंड वैल्यू शामिल है.
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 सीक्वेंस या 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 string की क्रम; डिफ़ॉल्ट [] है
एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कंस्ट्रेंट की सूची.

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 एंट्री के लिए, 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. 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)

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

पैरामीटर

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

नियम

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

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

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

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

पैरामीटर

पैरामीटर ब्यौरा
implementation ज़रूरी है
इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह एक्शन बनाकर, एलान किए गए सभी आउटपुट जनरेट करेगा.
test bool; डिफ़ॉल्ट तौर पर unbound
होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test कमांड का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप कार्यान्वित माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. वैल्यू डिफ़ॉल्ट रूप से False पर सेट होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
attrs शब्दकोश; नियम की सभी विशेषताओं का एलान करने के लिए, डिफ़ॉल्ट रूप से {}
डिक्शनरी है. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (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 string की क्रम; डिफ़ॉल्ट रूप से []
उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी नियम के लिए होस्ट कॉन्फ़िगरेशन में ज़रूरत होती है.
_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 है
एक्सपेरिमेंटल: नियम के एट्रिब्यूट को शुरू करने वाला Stlark फ़ंक्शन.

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

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

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

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

जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए **kwargs का इस्तेमाल करना अच्छा होता है.

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

parent डिफ़ॉल्ट रूप से None
होता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg को, इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद लागू किया जाता है.
extendable bool; या Label; या string; या None; डिफ़ॉल्ट तौर पर None
एक्सपेरिमेंटल: अनुमति वाली सूची का लेबल, जो यह तय करता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि समयसीमा बढ़ाने की अनुमति हमेशा दी जा सके या हमेशा से रोकी जा सके. Basel को डिफ़ॉल्ट रूप से, एक्सटेंशन को अनुमति देने की सुविधा मिलती है.
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 शब्दकोश; डिफ़ॉल्ट रूप से {}
सब रूल के सभी (निजी) एट्रिब्यूट का एलान करने के लिए डिक्शनरी है.

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