.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" नाम के टारगेट के लिए, आउटपुट डायक्शनरी {"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": पैकेज //foo
• "//foo/...": पैकेज //foo और उसके सभी सब-पैकेज.
• "public" या "private": सभी पैकेज या कोई पैकेज नहीं

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

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

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