.bzl फ़ाइलें

_ से शुरू होने वाले ऐसे एट्रिब्यूट जिनकी वैल्यू का साफ़ तौर पर पता नहीं चलता है उनकी वैल्यू डिफ़ॉल्ट होनी चाहिए. साथ ही, इनका टाइप label या label_list होना चाहिए.

ऐसे एट्रिब्यूट जिनकी वैल्यू का पता साफ़ तौर पर चलता है, उनका टाइप string होना चाहिए. साथ ही, उनमें values पाबंदी का इस्तेमाल होना चाहिए. ऐसे एट्रिब्यूट जिनकी वैल्यू का पता साफ़ तौर पर चलता है, आसपेक्ट को सिर्फ़ उन नियमों के साथ इस्तेमाल करने की पाबंदी लगाते हैं जिनमें पाबंदी के हिसाब से एक ही नाम, टाइप, और मान्य वैल्यू वाले एट्रिब्यूट हों.

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

सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि [FooInfo, BarInfo] अपने-आप [[FooInfo, BarInfo]] में बदल जाएगी.

किसी नियम (उदाहरण के लिए, some_rule) के टारगेट को किसी आसपेक्ट के लिए दिखाने के लिए, some_rule को सेवा देने वाली कम से कम एक ज़रूरी सूची में शामिल सभी कंपनियों का विज्ञापन दिखाना होगा. उदाहरण के लिए, अगर किसी आसपेक्ट के required_providers, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] हैं, तो यह आसपेक्ट some_rule टारगेट तब ही देख सकता है, जब some_rule FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों उपलब्ध कराता हो.

सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि [FooInfo, BarInfo] अपने-आप [[FooInfo, BarInfo]] में बदल जाएगी.

किसी दूसरे आसपेक्ट (जैसे, other_aspect) को इस आसपेक्ट के लिए दिखाने के लिए, other_aspect को कम से कम एक सूची में मौजूद सभी प्रोवाइडर की जानकारी देनी होगी. [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] के उदाहरण में, यह आसपेक्ट other_aspect को सिर्फ़ तब देख सकता है, जब other_aspect में FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों मौजूद हों.

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

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

उदाहरण के लिए, मान लें कि कोई आसपेक्ट, एट्रिब्यूट `deps` के ज़रिए ट्रांज़िटिव तौर पर प्रसारित होता है और इसे टारगेट `alpha` पर लागू किया जाता है. मान लें कि `alpha` में `deps = [':beta_output']` है, जहां `beta_output`, टारगेट `beta` का तय किया गया आउटपुट है. मान लें कि `beta` में, अपने एक `deps` के तौर पर टारगेट `charlie` है. अगर आसपेक्ट के लिए `apply_to_generating_rules=True` है, तो आसपेक्ट `alpha`, `beta`, और `charlie` के ज़रिए प्रसारित होगा. अगर यह False है, तो आसपेक्ट सिर्फ़ `alpha` पर प्रसारित होगा.

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

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

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

किसी सिंबल वाले मैक्रो से तय किए गए किसी भी टारगेट या अंदरूनी सिंबल वाले मैक्रो का नाम, name (इसे "मुख्य" टारगेट कहा जाता है) के बराबर होना चाहिए या name से शुरू होना चाहिए. इसके बाद, सेपरेटर वर्ण ("_", "-" या ".") और स्ट्रिंग सफ़िक्स होना चाहिए. (नाम तय करने की इस स्कीम का उल्लंघन करने वाले टारगेट का एलान किया जा सकता है. हालांकि, उन्हें बनाया, कॉन्फ़िगर या उन पर निर्भर नहीं किया जा सकता.)

डिफ़ॉल्ट रूप से, किसी सिंबल मैक्रो से तय किए गए टारगेट (इसमें वह Starlark फ़ंक्शन भी शामिल है जिसे मैक्रो का लागू करने वाला फ़ंक्शन ट्रांज़िटिव तरीके से कॉल करता है) सिर्फ़ उस पैकेज में दिखते हैं जिसमें मैक्रो की जानकारी देने वाली .bzl फ़ाइल होती है. सिंबल वाले मैक्रो को कॉल करने वाले व्यक्ति के साथ-साथ बाहरी लोगों को भी टारगेट दिखाने के लिए, लागू करने वाले फ़ंक्शन को visibility को सही तरीके से सेट करना होगा. आम तौर पर, visibility = visibility को उस नियम या मैक्रो सिंबल को पास करके ऐसा किया जाता है जिसे कॉल किया जा रहा है.

नीचे दिए गए एपीआई, मैक्रो लागू करने वाले फ़ंक्शन और उस Starlark फ़ंक्शन में उपलब्ध नहीं हैं जिसे यह ट्रांज़िटिव तरीके से कॉल करता है:

• package(), licenses()
• environment_group()
• native.glob() – इसके बजाय, लेबल की सूची वाले एट्रिब्यूट की मदद से, मैक्रो में ग्लोब पास किया जा सकता है
• native.subpackages()
• (सिर्फ़ नियम फ़ाइनलाइज़र में इस्तेमाल किया जा सकता है. नीचे finalizer देखें) native.existing_rules(), native.existing_rule()
• (WORKSPACE थ्रेड के लिए) workspace(), register_toolchains(), register_execution_platforms(), bind(), डेटाबेस नियम का इंस्टैंशिएशन

खास name एट्रिब्यूट को पहले से तय किया जाता है और इसे डिक्शनरी में शामिल नहीं किया जाना चाहिए. visibility एट्रिब्यूट का नाम रिज़र्व है और इसे डिक्शनरी में शामिल नहीं किया जाना चाहिए.

जिन एट्रिब्यूट के नाम _ से शुरू होते हैं वे निजी होते हैं -- उन्हें नियम की कॉल साइट पर पास नहीं किया जा सकता. किसी लेबल पर लागू होने वाली डिफ़ॉल्ट वैल्यू तय करने के लिए, ऐसे एट्रिब्यूट को डिफ़ॉल्ट वैल्यू असाइन की जा सकती है, जैसे कि attr.label(default="//pkg:foo").

मेमोरी के इस्तेमाल को सीमित करने के लिए, तय किए जा सकने वाले एट्रिब्यूट की संख्या की सीमा तय है.

अगर inherit_attrs को स्ट्रिंग "common" पर सेट किया जाता है, तो मैक्रो में सामान्य नियम एट्रिब्यूट की परिभाषाएं इनहेरिट हो जाएंगी. इनका इस्तेमाल, Starlark के सभी नियमों में किया जाता है.

ध्यान दें कि अगर rule() या macro() की रिटर्न वैल्यू को .bzl फ़ाइल में किसी ग्लोबल वैरिएबल को असाइन नहीं किया गया था, तो ऐसी वैल्यू को नियम या मैक्रो सिंबल के तौर पर रजिस्टर नहीं किया गया है. इसलिए, इसका इस्तेमाल inherit_attrs के लिए नहीं किया जा सकता.

इनहेरिटेंस का तरीका इस तरह काम करता है:

1. खास name और visibility एट्रिब्यूट को कभी इनहेरिट नहीं किया जाता;
2. छिपी हुई विशेषताओं (जिनका नाम "_" से शुरू होता है) को कभी इनहेरिट नहीं किया जाता;
3. जिन एट्रिब्यूट के नाम पहले से ही attrs डिक्शनरी में तय किए गए हैं उन्हें कभी भी इनहेरिट नहीं किया जाता. attrs में मौजूद एंट्री को प्राथमिकता दी जाती है. ध्यान दें कि किसी एंट्री को None पर सेट किया जा सकता है, ताकि यह पक्का किया जा सके कि उस नाम से कोई एट्रिब्यूट मैक्रो पर तय न हो;
4. अन्य सभी एट्रिब्यूट, नियम या मैक्रो से इनहेरिट किए जाते हैं और इन्हें attrs डिक्शनरी में मर्ज कर दिया जाता है.

जब किसी ऐसे एट्रिब्यूट को इनहेरिट किया जाता है जो ज़रूरी नहीं है, तो एट्रिब्यूट की डिफ़ॉल्ट वैल्यू को None पर बदल दिया जाता है. भले ही, ओरिजनल नियम या मैक्रो में इसके लिए कोई वैल्यू तय की गई हो. इससे यह पक्का होता है कि जब मैक्रो, एट्रिब्यूट की वैल्यू को रैप किए गए नियम या मैक्रो के किसी इंस्टेंस पर फ़ॉरवर्ड करता है, तो बाहरी मैक्रो के कॉल में मौजूद वैल्यू, अंदरूनी नियम या मैक्रो के कॉल में भी मौजूद नहीं होगी. ऐसा इसलिए होता है, क्योंकि किसी एट्रिब्यूट में None को पास करने का मतलब, एट्रिब्यूट को छोड़ने जैसा ही होता है.**kwargs यह ज़रूरी है, क्योंकि किसी एट्रिब्यूट को छोड़ने से, उसकी डिफ़ॉल्ट वैल्यू को पास करने से अलग सेमेटिक मिलते हैं. खास तौर पर, हटाए गए एट्रिब्यूट कुछ bazel query आउटपुट फ़ॉर्मैट में नहीं दिखाए जाते. साथ ही, कैलकुलेट की गई डिफ़ॉल्ट वैल्यू सिर्फ़ तब लागू होती हैं, जब वैल्यू को हटाया गया हो. अगर मैक्रो को इनहेरिट किए गए एट्रिब्यूट की जांच करनी है या उसमें बदलाव करना है, तो आपको मैक्रो के लागू करने वाले फ़ंक्शन में None केस को मैनेज करना होगा. उदाहरण के लिए, इनहेरिट किए गए tags एट्रिब्यूट में वैल्यू जोड़ना.

उदाहरण के लिए, नीचे दिया गया मैक्रो, native.cc_library से सभी एट्रिब्यूट को इनहेरिट करता है. हालांकि, इसमें cxxopts (जिसे एट्रिब्यूट की सूची से हटा दिया गया है) और copts (जिसे नई परिभाषा दी गई है) शामिल नहीं हैं. यह अतिरिक्त टैग जोड़ने से पहले, इनहेरिट किए गए tags एट्रिब्यूट की डिफ़ॉल्ट None वैल्यू की जांच भी करता है.

def _my_cc_library_impl(name, visibility, tags, **kwargs):
    # Append a tag; tags attr was inherited from native.cc_library, and
    # therefore is None unless explicitly set by the caller of my_cc_library()
    my_tags = (tags or []) + ["my_custom_tag"]
    native.cc_library(
        name = name,
        visibility = visibility,
        tags = my_tags,
        **kwargs
    )

my_cc_library = macro(
    implementation = _my_cc_library_impl,
    inherit_attrs = native.cc_library,
    attrs = {
        "cxxopts": None,
        "copts": attr.string_list(default = ["-D_FOO"]),
    },
)

अगर inherit_attrs सेट है, तो मैक्रो के लागू करने वाले फ़ंक्शन में ज़रूर एक **kwargs अवशेष कीवर्ड पैरामीटर होना चाहिए.

आम तौर पर, मैक्रो को इनहेरिट किए गए और बदले नहीं गए एट्रिब्यूट को "मुख्य" नियम या मैक्रो सिंबल में पास करना चाहिए. आम तौर पर, इनहेरिट किए गए ज़्यादातर एट्रिब्यूट के लिए, लागू करने वाले फ़ंक्शन की पैरामीटर सूची में कोई पैरामीटर नहीं होगा. साथ ही, उन्हें **kwargs के ज़रिए पास किया जाएगा. अगर मैक्रो को "मुख्य" और "मुख्य" से बाहर के दोनों टारगेट को वे एट्रिब्यूट पास करने हैं, तो लागू करने वाले फ़ंक्शन के लिए, इनहेरिट किए गए कुछ एट्रिब्यूट (ज़्यादातर, tags और testonly) के लिए साफ़ तौर पर पैरामीटर होना सुविधाजनक हो सकता है – लेकिन अगर मैक्रो को उन एट्रिब्यूट की जांच करनी है या उनमें बदलाव करना है, तो आपको ज़रूरी नहीं है कि इनहेरिट किए गए एट्रिब्यूट की None डिफ़ॉल्ट वैल्यू को मैनेज किया जाए.

सामान्य सिंबॉलिक मैक्रो के उलट, नियम फ़ाइनलाइज़र, मौजूदा पैकेज में तय किए गए नॉन-फ़ाइनलाइज़र नियम टारगेट के सेट की क्वेरी करने के लिए, native.existing_rule() और native.existing_rules() को कॉल कर सकते हैं. ध्यान दें कि native.existing_rule() और native.existing_rules(), इस नियम फ़ाइनलाइज़र के साथ-साथ किसी भी नियम फ़ाइनलाइज़र से तय किए गए टारगेट को ऐक्सेस नहीं कर सकते.

• फ़ील्ड की सूची:
  

  provider(fields = ['a', 'b'])

• डिक्शनरी फ़ील्ड का नाम -> दस्तावेज़:
  

  provider(
         fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })

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

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

• अगर args में कोई वैल्यू मौजूद है, तो गड़बड़ी का मैसेज दिखता है.
• अगर provider() को कॉल करते समय fields पैरामीटर तय किया गया था और kwargs में कोई ऐसा बटन है जो fields में मौजूद नहीं था, तो गड़बड़ी होती है.
• ऐसा न होने पर, c एक नया इंस्टेंस दिखाता है. इसमें kwargs में मौजूद हर k: v एंट्री के लिए, k नाम का एक फ़ील्ड होता है, जिसकी वैल्यू v होती है.

MyInfo = provider()
m = MyInfo(foo = 1)

हालांकि, अगर 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 = ...)

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

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

पहले से तय किए गए आउटपुट तय करने के लिए स्कीमा. output और output_list एट्रिब्यूट के उलट, उपयोगकर्ता इन फ़ाइलों के लिए लेबल तय नहीं करता. पहले से तय किए गए आउटपुट के बारे में ज़्यादा जानने के लिए, नियम वाला पेज देखें.

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

डिक्शनरी में हर एंट्री से, पहले से तय किया गया आउटपुट बनता है. इसमें, की एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है. इससे आउटपुट का लेबल तय होता है. नियम लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर फ़ील्ड का नाम बन जाता है. इसका इस्तेमाल, ctx.outputs में आउटपुट के File को ऐक्सेस करने के लिए किया जाता है. आउटपुट के लेबल में वही पैकेज होता है जो नियम में होता है. पैकेज के बाद का हिस्सा, "%{ATTR}" फ़ॉर्म के हर प्लेसहोल्डर को एट्रिब्यूट ATTR की वैल्यू से बनाई गई स्ट्रिंग से बदलकर बनाया जाता है:

• स्ट्रिंग टाइप वाले एट्रिब्यूट की वैल्यू को हूबहू बदल दिया जाता है.
• लेबल टाइप वाले एट्रिब्यूट, पैकेज के बाद लेबल का हिस्सा बन जाते हैं. हालांकि, इनमें फ़ाइल एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, लेबल "//pkg:a/b.c", "a/b" हो जाता है.
• पैकेज के बाद, आउटपुट टाइप वाले एट्रिब्यूट, फ़ाइल एक्सटेंशन (ऊपर दिए गए उदाहरण के लिए, "a/b.c") के साथ लेबल का हिस्सा बन जाते हैं.
• प्लेसहोल्डर में इस्तेमाल किए जाने वाले, सूची वाले सभी एट्रिब्यूट (उदाहरण के लिए, attr.label_list) में एक ही एलिमेंट होना चाहिए. उनका कन्वर्ज़न, उनके नॉन-लिस्ट वर्शन (attr.label) जैसा ही है.
• ऐसा हो सकता है कि अन्य तरह के एट्रिब्यूट, प्लेसहोल्डर में न दिखें.
• बिना एट्रिब्यूट वाले खास प्लेसहोल्डर %{dirname} और %{basename}, नियम के लेबल के उन हिस्सों में बड़े हो जाते हैं जिनमें पैकेज शामिल नहीं होता. उदाहरण के लिए, "//pkg:a/b.c" में dirname, a है और basename, b.c है.

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

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

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

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

अगर किसी नियम को विश्लेषण टेस्ट नियम के तौर पर तय किया जाता है, तो उसके एट्रिब्यूट पर analysis_test_transition का इस्तेमाल करके तय किए गए कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल किया जा सकता है. हालांकि, यह कुछ पाबंदियों के साथ काम करता है:

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

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

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

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

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

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

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

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

• executable=True वाले लेबल एट्रिब्यूट के लिए FilesToRunProvider
• allow_single_file=True वाले लेबल एट्रिब्यूट के लिए File
• अन्य सभी लेबल एट्रिब्यूट के लिए Target
• सभी लेबल-लिस्ट एट्रिब्यूट के लिए [Target]

ध्यान दें कि rule(), aspect(), और repository_rule() के उलट, एट्रिब्यूट की वैल्यू के तौर पर तय किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में नहीं बदलेंगे. डिफ़ॉल्ट वैल्यू का इस्तेमाल करने के लिए, कॉल करने वाले को एट्रिब्यूट की वैल्यू सबमिट नहीं करनी होगी.

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

• "//foo": the package //foo
• "//foo/...": पैकेज //foo और उसके सभी सब-पैकेज.
• "public" या "private": सभी पैकेज या कोई पैकेज नहीं

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

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

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