सदस्य
- analysis_test_transition
 - aspect
 - configuration_field
 - depset
 - exec_group
 - exec_transition
 - macro
 - module_extension
 - provider
 - repository_rule
 - rule
 - select
 - सब्रूल
 - tag_class
 - visibility
 
analysis_test_transition
transition analysis_test_transition(settings)
 यह विश्लेषण-टेस्ट नियम की डिपेंडेंसी पर लागू करने के लिए, कॉन्फ़िगरेशन ट्रांज़िशन बनाता है. यह ट्रांज़िशन सिर्फ़ उन नियमों के एट्रिब्यूट पर लागू किया जा सकता है जिनमें analysis_test = True है. इस तरह के नियमों की सुविधाएं सीमित होती हैं. उदाहरण के लिए, उनके डिपेंडेंसी ट्री का साइज़ सीमित होता है. इसलिए, transition() का इस्तेमाल करके बनाए गए ट्रांज़िशन की तुलना में, इस फ़ंक्शन का इस्तेमाल करके बनाए गए ट्रांज़िशन के दायरे की संभावना सीमित होती है. 
इस फ़ंक्शन को मुख्य रूप से, Analysis Test Framework की मुख्य लाइब्रेरी को बेहतर बनाने के लिए डिज़ाइन किया गया है. सबसे सही तरीके जानने के लिए, इसका दस्तावेज़ (या इसे लागू करने का तरीका) देखें.
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              settings
             | 
            
                          dict;
                                    ज़रूरी है एक डिक्शनरी, जिसमें ऐसे कॉन्फ़िगरेशन सेटिंग की जानकारी होती है जिन्हें इस कॉन्फ़िगरेशन ट्रांज़िशन की मदद से सेट किया जाना चाहिए. इसमें मौजूद बटन, बिल्ड सेटिंग के लेबल (बिल्ड प्रोसेस के दौरान इस्तेमाल होने वाले विशिष्ट कॉन्फ़िगरेशन विकल्पों से जुड़े, पूरी जानकारी देने वाले नाम या आइडेंटिफ़ायर) हैं और इसकी वैल्यू, ट्रांज़िशन के बाद की नई वैल्यू हैं. किसी भी अन्य सेटिंग में कोई बदलाव नहीं हुआ है. इसका इस्तेमाल करके, उन खास कॉन्फ़िगरेशन सेटिंग के बारे में बताएं जिन्हें विश्लेषण टेस्ट पास करने के लिए सेट करना ज़रूरी है.  | 
          
aspect
Aspect aspect(implementation, attr_aspects=[], toolchains_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          function;
                                    ज़रूरी है यह एक Starlark फ़ंक्शन है, जो इस आसपेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: Target (वह टारगेट जिस पर आसपेक्ट लागू किया जाता है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया जाता है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. विश्लेषण के दौरान, इस फ़ंक्शन का आकलन किया जाता है. ऐसा, किसी टारगेट के लिए किसी आसपेक्ट को हर बार लागू करने के लिए किया जाता है.
             | 
          
              attr_aspects
             | 
            
                          स्ट्रिंग का क्रम;
                                     डिफ़ॉल्ट रूप से []होता है एट्रिब्यूट के नामों की सूची. यह आसपेक्ट इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के साथ लागू होता है. आम तौर पर, deps और exports वैल्यू का इस्तेमाल किया जाता है. सूची में एक स्ट्रिंग "*" भी शामिल हो सकती है, ताकि इसे टारगेट की सभी डिपेंडेंसी के साथ लागू किया जा सके.
             | 
          
              toolchains_aspects
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर []होता है टूल चेन के टाइप की सूची. यह आसपेक्ट, उन टारगेट टूल चेन पर लागू होता है जो इन टूल चेन टाइप से मेल खाते हैं.  | 
          
              attrs
             | 
            
                          dict;
                                     डिफ़ॉल्ट तौर पर {}होता है यह एक डिक्शनरी है, जिसमें आसपेक्ट के सभी एट्रिब्यूट की जानकारी होती है. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. जैसे, attr.label या attr.string (attr मॉड्यूल देखें). एसपेक्ट एट्रिब्यूट, लागू करने वाले फ़ंक्शन के लिए ctx पैरामीटर के फ़ील्ड के तौर पर उपलब्ध होते हैं. 
 ऐसे एट्रिब्यूट जिनकी वैल्यू का पता साफ़ तौर पर चलता है, उनका टाइप  एट्रिब्यूट की वैल्यू के तौर पर तय किए गए एट्रिब्यूट,   | 
          
              required_providers
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर यह []होता है इस एट्रिब्यूट की मदद से, आसपेक्ट को सिर्फ़ उन टारगेट तक सीमित किया जा सकता है जिनके नियमों में, ज़रूरी सेवा देने वाली कंपनियों का विज्ञापन होता है. यह वैल्यू, सेवा देने वाली कंपनियों की एक सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि  किसी नियम (उदाहरण के लिए,   | 
          
              required_aspect_providers
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर इसकी वैल्यू []होती है इस एट्रिब्यूट की मदद से, इस आसपेक्ट को दूसरे आसपेक्ट की जांच करने की अनुमति मिलती है. यह वैल्यू, सेवा देने वाली कंपनियों की एक सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि  किसी दूसरे आसपेक्ट (जैसे,   | 
          
              provides
             | 
            
                          sequence;
                                     डिफ़ॉल्ट रूप से []होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन की रिटर्न वैल्यू में ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट,   | 
          
              requires
             | 
            
                          sequence of Aspects;
                                     डिफ़ॉल्ट रूप से []होता है इस आसपेक्ट से पहले, लागू किए जाने वाले आसपेक्ट की सूची.  | 
          
              fragments
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है.  | 
          
              host_fragments
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट तौर पर यह []होता है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी होस्ट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है.  | 
          
              toolchains
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर, यह []होता है अगर यह सेट है, तो इस आसपेक्ट के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन मिलेंगे. साथ ही, ctx.toolchain के ज़रिए, इन टूल चेन को आसपेक्ट लागू करने के लिए उपलब्ध कराया जाएगा.
             | 
          
              incompatible_use_toolchain_transition
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहोता है अब इस्तेमाल नहीं किया जाता. इसे हटा दिया जाना चाहिए.  | 
          
              doc
             | 
            
                          स्ट्रिंग या None;
                                     डिफ़ॉल्ट तौर पर Noneहोता है दस्तावेज़ जनरेट करने वाले टूल से निकाले जा सकने वाले आसपेक्ट की जानकारी.  | 
          
              apply_to_generating_rules
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहै अगर यह 'सही' है, तो आउटपुट फ़ाइल पर लागू किए जाने पर, आसपेक्ट उसकी बजाय आउटपुट फ़ाइल को जनरेट करने वाले नियम पर लागू होगा. उदाहरण के लिए, मान लें कि कोई आसपेक्ट, एट्रिब्यूट `deps` के ज़रिए ट्रांज़िटिव तौर पर प्रसारित होता है और इसे टारगेट `alpha` पर लागू किया जाता है. मान लें कि `alpha` में `deps = [':beta_output']` है, जहां `beta_output`, टारगेट `beta` का तय किया गया आउटपुट है. मान लें कि `beta` में, अपने एक `deps` के तौर पर टारगेट `charlie` है. अगर आसपेक्ट के लिए `apply_to_generating_rules=True` है, तो आसपेक्ट `alpha`, `beta`, और `charlie` के ज़रिए प्रसारित होगा. अगर यह False है, तो आसपेक्ट सिर्फ़ `alpha` पर प्रसारित होगा. डिफ़ॉल्ट रूप से, यह 'गलत' पर सेट होता है.  | 
          
              exec_compatible_with
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची है जो इस आसपेक्ट के सभी इंस्टेंस पर लागू होती हैं  | 
          
              exec_groups
             | 
            
                          dict या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है एक डिक्शनरी, जिसमें एक्ज़ीक्यूशन ग्रुप का नाम (स्ट्रिंग) exec_group में बदला जाता है. अगर यह सेट है, तो आसपेक्ट, एक ही इंस्टेंस में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर ऐक्शन चला सकता है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप का दस्तावेज़ देखें.
             | 
          
              subrules
             | 
            
                          sequence of Subrules;
                                     डिफ़ॉल्ट रूप से []होता है एक्सपेरिमेंटल: इस आसपेक्ट में इस्तेमाल किए गए सबनियमों की सूची.  | 
          
configuration_field
LateBoundDefault configuration_field(fragment, name)
इस्तेमाल का उदाहरण:
नियम एट्रिब्यूट तय करना: 
'_foo': attr.label(default=configuration_field(fragment='java', name='toolchain'))
नियम लागू करने के दौरान ऐक्सेस करना: 
  def _rule_impl(ctx):
    foo_info = ctx.attr._foo
    ...पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              fragment
             | 
            
                          string;
                                     ज़रूरी है उस कॉन्फ़िगरेशन फ़्रैगमेंट का नाम जिसमें लेट-बाउंड वैल्यू शामिल है.  | 
          
              name
             | 
            
                          string;
                                    ज़रूरी है उस वैल्यू का नाम जो कॉन्फ़िगरेशन फ़्रैगमेंट से मिलने वाला है.  | 
          
depset
depset depset(direct=None, order="default", *, transitive=None)
direct पैरामीटर, depset के डायरेक्ट एलिमेंट की सूची है. वहीं, transitive पैरामीटर, उन depset की सूची है जिनके एलिमेंट, बनाए गए depset के इनडायरेक्ट एलिमेंट बन जाते हैं. depset को सूची में बदलने पर, एलिमेंट किस क्रम में दिखाए जाते हैं, यह order पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, Depsets की खास जानकारी देखें.
किसी depset के सभी एलिमेंट (डायरेक्ट और इनडायरेक्ट) एक ही तरह के होने चाहिए, जैसा कि एक्सप्रेशन type(x) से मिलता है.
क्योंकि हैश पर आधारित सेट का इस्तेमाल, दोहराव के दौरान डुप्लीकेट हटाने के लिए किया जाता है. इसलिए, डेपसेट के सभी एलिमेंट हैश किए जा सकने चाहिए. हालांकि, फ़िलहाल सभी कंस्ट्रक्टर में इस इनवेरिएंट की लगातार जांच नहीं की जाती है. हमेशा एक जैसी जांच करने की सुविधा चालू करने के लिए, --incompatible_always_check_depset_elements फ़्लैग का इस्तेमाल करें. आने वाले समय में रिलीज़ होने वाले वर्शन में, यह डिफ़ॉल्ट रूप से चालू रहेगी. समस्या 10313 देखें.
इसके अलावा, फ़िलहाल एलिमेंट में बदलाव करने की गुंजाइश नहीं होनी चाहिए. हालांकि, आने वाले समय में इस पाबंदी को हटा दिया जाएगा.
 बनाए गए depset का क्रम, उसके transitive depsets के क्रम के साथ काम करना चाहिए. "default" ऑर्डर, किसी भी अन्य ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर, सिर्फ़ अपने साथ काम करते हैं.
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              direct
             | 
            
                          sequence या None;
                                     डिफ़ॉल्ट तौर पर Noneहोता है किसी depset के डायरेक्ट एलिमेंट की सूची.  | 
          
              order
             | 
            
                          string;
                                     डिफ़ॉल्ट तौर पर "default"होता है नए depset के लिए ट्रैवर्सल की रणनीति. संभावित वैल्यू के लिए, यहां देखें.  | 
          
              transitive
             | 
            
                          sequence of depsets; या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है उन depset की सूची जिनके एलिमेंट, depset के इनडायरेक्ट एलिमेंट बन जाएंगे.  | 
          
exec_group
exec_group exec_group(toolchains=[], exec_compatible_with=[])
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              toolchains
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर []होता है यह टूल चेन का वह सेट होता है जो इस एक्ज़ीक्यूशन ग्रुप के लिए ज़रूरी होता है. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं.  | 
          
              exec_compatible_with
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट तौर पर []होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है.  | 
          
exec_transition
transition exec_transition(implementation, inputs, outputs)
transition() का एक खास वर्शन, जिसका इस्तेमाल एक्ज़ीक्यूशन ट्रांज़िशन तय करने के लिए किया जाता है. सबसे सही तरीके जानने के लिए, इसका दस्तावेज़ (या इसे लागू करने का तरीका) देखें. इसका इस्तेमाल सिर्फ़ Bazel के इन-बिल्ट फ़ंक्शन से किया जा सकता है.
          
      पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          कॉलेबल;
                                     ज़रूरी है | 
          
              inputs
             | 
            
                          sequence of strings;
                                     ज़रूरी है | 
          
              outputs
             | 
            
                          sequence of strings;
                                     ज़रूरी है | 
          
macro
macro macro(implementation, attrs={}, inherit_attrs=None, finalizer=False, doc=None)
BUILD फ़ाइलों या मैक्रो (लेगसी या सिंबॉलिक) में कॉल किया जा सकता है, ताकि टारगेट तय किए जा सकें. ऐसा हो सकता है कि एक से ज़्यादा टारगेट तय किए जाएं.
macro(...) से मिली वैल्यू को .bzl फ़ाइल में मौजूद किसी ग्लोबल वैरिएबल को असाइन करना ज़रूरी है. ग्लोबल वैरिएबल का जो नाम होगा, वही मैक्रो सिंबल का नाम होगा.
सिंबॉलिक मैक्रो इस्तेमाल करने के बारे में पूरी जानकारी के लिए, मैक्रो देखें.
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          function;
                                     ज़रूरी है यह मैक्रो लागू करने वाला Starlark फ़ंक्शन है. मैक्रो के एट्रिब्यूट की वैल्यू, कीवर्ड आर्ग्युमेंट के तौर पर लागू करने वाले फ़ंक्शन को पास की जाती हैं. इंपलीमेंटेशन फ़ंक्शन में कम से कम दो पैरामीटर होने चाहिए, जिनके नाम name और visibility होने चाहिए. अगर मैक्रो एट्रिब्यूट इनहेरिट करता है (नीचे inherit_attrs देखें), तो इसमें **kwargs रीज़िडुअल कीवर्ड पैरामीटर होना चाहिए.
परंपरा के मुताबिक, लागू करने वाले फ़ंक्शन में ऐसे किसी भी एट्रिब्यूट के लिए नाम वाला पैरामीटर होना चाहिए जिसकी मैक्रो को जांच करनी है, जिसे बदलना है या जिसे "मुख्य" टारगेट के अलावा किसी अन्य टारगेट को पास करना है. वहीं, "बल्क" में इनहेरिट किए गए ऐसे एट्रिब्यूट जिन्हें "मुख्य" टारगेट को बिना किसी बदलाव के पास किया जाएगा उन्हें  लागू करने वाले फ़ंक्शन से कोई वैल्यू नहीं मिलनी चाहिए. इसके बजाय, लागू करने वाला फ़ंक्शन, नियम या मैक्रो सिंबल को कॉल करके टारगेट की जानकारी देता है. सिंबॉलिक मैक्रो से तय किए गए किसी भी टारगेट या इनर सिंबॉलिक मैक्रो का नाम,  डिफ़ॉल्ट रूप से, सिंबॉलिक मैक्रो से तय किए गए टारगेट सिर्फ़ उस पैकेज में दिखते हैं जिसमें मैक्रो को तय करने वाली .bzl फ़ाइल मौजूद होती है. इसमें, मैक्रो को लागू करने वाले फ़ंक्शन के ज़रिए ट्रांज़िटिव तरीके से कॉल किए जाने वाले किसी भी Starlark फ़ंक्शन से तय किए गए टारगेट भी शामिल हैं. बाहरी तौर पर दिखने वाले टारगेट की जानकारी देने के लिए, लागू करने वाले फ़ंक्शन को  मैक्रो लागू करने वाले फ़ंक्शन और ट्रांज़िटिव तौर पर कॉल करने वाले किसी भी Starlark फ़ंक्शन में, ये एपीआई उपलब्ध नहीं हैं: 
  | 
          
              attrs
             | 
            
                          dict;
                                     डिफ़ॉल्ट रूप से {}होता है इस मैक्रो के साथ काम करने वाले एट्रिब्यूट की डिक्शनरी, जो rule.attrs से मिलती-जुलती है. कुंजियां, एट्रिब्यूट के नाम होती हैं और वैल्यू, attr.label_list(...) (attr मॉड्यूल देखें) या None जैसे एट्रिब्यूट ऑब्जेक्ट होती हैं. None एंट्री का मतलब है कि मैक्रो में उस नाम का कोई एट्रिब्यूट नहीं है. भले ही, उसे inherit_attrs के ज़रिए इनहेरिट किया गया हो (नीचे देखें).
खास  
 मेमोरी के इस्तेमाल को सीमित करने के लिए, तय किए जा सकने वाले एट्रिब्यूट की संख्या की सीमा तय है.  | 
          
              inherit_attrs
             | 
            
                          rule; या macro; या string; या None;
                                     डिफ़ॉल्ट रूप से 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"]),
    },
)
अगर  परंपरा के मुताबिक, मैक्रो को इनहेरिट किए गए, बिना बदले गए एट्रिब्यूट को "main" नियम या मैक्रो सिंबल में पास करना चाहिए. मैक्रो इसी सिंबल को रैप कर रहा होता है. आम तौर पर, इनहेरिट किए गए ज़्यादातर एट्रिब्यूट के लिए, लागू करने वाले फ़ंक्शन की पैरामीटर सूची में कोई पैरामीटर नहीं होता है. इन्हें सिर्फ़   | 
          
              finalizer
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है यह मैक्रो, नियम फ़ाइनलाइज़र है या नहीं. यह एक ऐसा मैक्रो होता है जिसका आकलन, पैकेज लोड होने के आखिर में किया जाता है. भले ही, वह BUILD फ़ाइल में कहीं भी हो. ऐसा तब किया जाता है, जब सभी नॉन-फ़ाइनलाइज़र टारगेट तय कर लिए जाते हैं.
सामान्य सिंबॉलिक मैक्रो के उलट, नियम फ़ाइनलाइज़र   | 
          
              doc
             | 
            
                          string; or None;
                                     डिफ़ॉल्ट रूप से Noneहोता है मैक्रो की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
module_extension
unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)use_extension के साथ MODULE.bazel फ़ाइल में इस्तेमाल किया जा सके.
          
      पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          कॉलेबल;
                                     ज़रूरी है यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर होना चाहिए, module_ctx. उपलब्ध रिपॉज़िटरी का सेट तय करने के लिए, फ़ंक्शन को बिल्ड की शुरुआत में एक बार कॉल किया जाता है.
             | 
          
              tag_classes
             | 
            
                          dict;
                                     डिफ़ॉल्ट रूप से {}होता है यह एक डिक्शनरी है, जिसमें एक्सटेंशन के इस्तेमाल किए गए सभी टैग क्लास की जानकारी होती है. यह टैग क्लास के नाम को tag_class ऑब्जेक्ट से मैप करता है.
             | 
          
              doc
             | 
            
                          string; या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है मॉड्यूल एक्सटेंशन की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
              environ
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट तौर पर []होता है एनवायरमेंट वैरिएबल की वह सूची उपलब्ध कराता है जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा.  | 
          
              os_dependent
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है इससे पता चलता है कि यह एक्सटेंशन ओएस पर निर्भर करता है या नहीं  | 
          
              arch_dependent
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है यह बताता है कि यह एक्सटेंशन, आर्किटेक्चर पर निर्भर करता है या नहीं  | 
          
provider
unknown provider(doc=None, *, fields=None, init=None)
MyInfo = provider()
...
def _my_library_impl(ctx):
    ...
    my_info = MyInfo(x = 2, y = 3)
    # my_info.x == 2
    # my_info.y == 3
    ...प्रोवाइडर इस्तेमाल करने के बारे में पूरी जानकारी के लिए, नियम (प्रोवाइडर) देखें.
अगर init नहीं दिया गया है, तो यह Provider की कॉल की जा सकने वाली वैल्यू दिखाता है.
अगर init दिया गया है, तो यह दो एलिमेंट का ट्यूपल दिखाता है: Provider की कॉल की जा सकने वाली वैल्यू और रॉ कंस्ट्रक्टर की कॉल की जा सकने वाली वैल्यू. ज़्यादा जानकारी के लिए,  नियम (कस्टम प्रोवाइडर का कस्टम तरीके से शुरू होना) और नीचे init पैरामीटर के बारे में चर्चा देखें.
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              doc
             | 
            
                          string; या None;
                                     डिफ़ॉल्ट तौर पर Noneहै सेवा देने वाली कंपनी की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
              fields
             | 
            
                          sequence of strings; या dict; या None;
                                     डिफ़ॉल्ट तौर पर Noneहोता है अगर यह तय होता है, तो अनुमति वाले फ़ील्ड के सेट पर पाबंदी लगा दी जाती है. इन वैल्यू का इस्तेमाल किया जा सकता है: 
  | 
          
              init
             | 
            
                          कॉलेबल; या None;
                                     डिफ़ॉल्ट तौर पर Noneहोता है प्रोवाइडर के फ़ील्ड की वैल्यू को पहले से प्रोसेस करने और इंस्टैंशिएशन के दौरान उनकी पुष्टि करने के लिए, एक वैकल्पिक कॉलबैक. अगर init दिया गया है, तो provider() दो एलिमेंट का ट्यूपल दिखाता है: सामान्य प्रोवाइडर सिंबल और रॉ कन्स्ट्रक्टर.इसकी सटीक जानकारी यहां दी गई है. आसान शब्दों में जानकारी और इस्तेमाल के उदाहरणों के लिए, नियम (कस्टम प्रोवाइडर का कस्टम तरीके से शुरू होना) देखें. मान लें कि  
 init को कॉलबैक न किया गया हो, तो सिंबल P को कॉल करने पर, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c को कॉल किया जाता है. दूसरे शब्दों में, P(*args, **kwargs) c(*args, **kwargs) दिखाता है. उदाहरण के लिए,MyInfo = provider() m = MyInfo(foo = 1) m को m.foo == 1 वाला MyInfo इंस्टेंस बनाया जा सके.हालांकि, अगर  
 ध्यान दें: ऊपर दिए गए चरणों का मतलब है कि अगर  इस तरह,  
 MyInfo, _new_myinfo = provider(init = ...)  | 
          
repository_rule
callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)
module_extension() लागू करने वाले फ़ंक्शन से लोड और कॉल किया जा सके या use_repo_rule() का इस्तेमाल किया जा सके.
          
      पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          कॉलेबल;
                                    ज़रूरी है यह वह फ़ंक्शन है जो इस नियम को लागू करता है. इसमें एक पैरामीटर, repository_ctx होना चाहिए. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोडिंग फ़ेज़ के दौरान कॉल किया जाता है.
             | 
          
              attrs
             | 
            
                          dict या None;
                                     डिफ़ॉल्ट तौर पर Noneयह एक डिक्शनरी है, जिसमें डेटाबेस नियम के सभी एट्रिब्यूट की जानकारी होती है. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है ( attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल में लेबल पर लागू होने वाली डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटाबेस का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं हो सकता. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती.
एट्रिब्यूट की वैल्यू के तौर पर तय किए गए एट्रिब्यूट,   | 
          
              local
             | 
            
                          bool;
                                     डिफ़ॉल्ट Falseहोता है यह बताते हैं यह नियम, सबकुछ स्थानीय सिस्टम से फ़ेच करता है और हर फ़ेच के बाद, इसका फिर से आकलन किया जाना चाहिए.  | 
          
              environ
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट []होता है अब इस्तेमाल नहीं किया जा सकता. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, repository_ctx.getenv पर माइग्रेट करें.इससे, एनवायरमेंट वैरिएबल की सूची मिलती है, जिस पर यह डेटाबेस नियम निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो डेटाबेस को फिर से फ़ेच किया जाएगा.  | 
          
              configure
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है यह बताते हैं कि डेटाबेस, कॉन्फ़िगरेशन के मकसद से सिस्टम की जांच करता है  | 
          
              remotable
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है एक्सपेरिमेंट के तौर पर उपलब्ध है. यह पैरामीटर एक्सपेरिमेंट के तौर पर उपलब्ध है. इसमें कभी भी बदलाव किया जा सकता है. कृपया इसके भरोसे न रहें. इसे एक्सपेरिमेंट के तौर पर चालू किया जा सकता है. इसके लिए, --experimental_repo_remote_exec को सेट करना होगा. यह रिमोट एक्ज़ीक्यूशन के साथ काम करता है  | 
          
              doc
             | 
            
                          string या None;
                                     डिफ़ॉल्ट रूप से Noneहै डेटाबेस के नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
नियम
callable rule(implementation, *, test=unbound, attrs={}, outputs=None, executable=unbound, output_to_genfiles=False, fragments=[], host_fragments=[], _skylark_testable=False, toolchains=[], incompatible_use_toolchain_transition=False, doc=None, provides=[], dependency_resolution_rule=False, exec_compatible_with=[], analysis_test=False, build_setting=None, cfg=None, exec_groups=None, initializer=None, parent=None, extendable=None, subrules=[])नियमों को .bzl फ़ाइल में ग्लोबल वैरिएबल को असाइन किया जाना चाहिए. जो ग्लोबल वैरिएबल का नाम होता है, वही नियम का नाम होता है.
जांच के नियमों के नाम के आखिर में _test होना चाहिए. वहीं, अन्य सभी नियमों के नाम के आखिर में यह सफ़िक्स नहीं होना चाहिए. (यह पाबंदी सिर्फ़ नियमों पर लागू होती है, उनके टारगेट पर नहीं.)
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          function;
                                    ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह ऐक्शन बनाकर, तय किए गए सभी आउटपुट जनरेट करेगा.  | 
          
              test
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर unboundहोता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test निर्देश का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप एक्ज़ीक्यूटेबल माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. डिफ़ॉल्ट रूप से, इसकी वैल्यू False होती है. ज़्यादा जानकारी के लिए,  नियमों का पेज देखें.
             | 
          
              attrs
             | 
            
                          dict;
                                     डिफ़ॉल्ट तौर पर {}होता है नियम के सभी एट्रिब्यूट की जानकारी देने वाली डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है ( attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, एट्रिब्यूट की संख्या तय की गई है.
एट्रिब्यूट की वैल्यू के तौर पर तय किए गए एट्रिब्यूट,   | 
          
              outputs
             | 
            
                          dict; या None; या function;
                                     डिफ़ॉल्ट रूप से Noneहोता है अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इसके भरोसे न रहें. --incompatible_no_rule_outputs_param के साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपके कोड, इस जल्द ही हटाए जाने वाले फ़ैसले से कोई दिक्कत नहीं होगी. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए, नियमों को माइग्रेट करें. पहले से तय किए गए आउटपुट को तय करने के लिए स्कीमा.  इस आर्ग्युमेंट की वैल्यू, कोई डिक्शनरी या डिक्शनरी बनाने वाली कोई कॉलबैक फ़ंक्शन होती है. कॉलबैक, कैलकुलेट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच किए जाते हैं. उदाहरण के लिए, अगर आपने परिभाषा  डिक्शनरी में मौजूद हर एंट्री, पहले से तय किया गया आउटपुट बनाती है. इसमें कुंजी एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होता है, जो आउटपुट के लेबल को तय करता है. नियम को लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर, फ़ील्ड का वह नाम बन जाता है जिसका इस्तेमाल  
 आम तौर पर, बदले जाने वाले वैल्यू के लिए सबसे ज़्यादा इस्तेमाल किया जाने वाला प्लेसहोल्डर   | 
          
              executable
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से unboundहोता है यह तय करता है कि इस नियम को लागू किया जा सकता है या नहीं. इसका मतलब है कि क्या यह blaze run निर्देश का विषय हो सकता है. यह डिफ़ॉल्ट रूप से False पर सेट होता है. ज़्यादा जानकारी के लिए,  नियमों का पेज देखें.
             | 
          
              output_to_genfiles
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहै अगर यह 'सही' है, तो फ़ाइलें bin डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय), तो इस फ़्लैग को सेट न करें.  | 
          
              fragments
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट रूप से []है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है.  | 
          
              host_fragments
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन में नियम के लिए होती है.  | 
          
              _skylark_testable
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहोता है (एक्सपेरिमेंट के तौर पर उपलब्ध है) अगर यह वैल्यू सही है, तो यह नियम अपने ऐक्शन को उन नियमों के लिए उपलब्ध कराएगा जो Actions प्रोवाइडर के ज़रिए इस पर निर्भर करते हैं. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध कराया जाता है.इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. ऐसा हो सकता है कि आने वाले समय में इस फ़्लैग को हटा दिया जाए.  | 
          
              toolchains
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर []सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
             | 
          
              incompatible_use_toolchain_transition
             | 
            
                          bool;
                                     डिफ़ॉल्ट रूप से Falseहोता है इस्तेमाल नहीं किया जाता. इसे हटा दिया जाना चाहिए.  | 
          
              doc
             | 
            
                          स्ट्रिंग या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
              provides
             | 
            
                          sequence;
                                     डिफ़ॉल्ट रूप से []होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन की रिटर्न वैल्यू में ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट,   | 
          
              dependency_resolution_rule
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहोता है अगर सेट किया जाता है, तो नियम, एट्रिब्यूट के ज़रिए डिपेंडेंसी हो सकता है. साथ ही, इसे मटीरियलाइज़र में उपलब्ध के तौर पर भी मार्क किया जाता है. इस फ़्लैग सेट वाले नियमों के हर एट्रिब्यूट को, मेटालिज़र में भी उपलब्ध के तौर पर मार्क किया जाना चाहिए. ऐसा इसलिए है, ताकि मार्क किए गए नियम, मार्क नहीं किए गए नियमों पर निर्भर न हों.  | 
          
              exec_compatible_with
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची है जो इस नियम टाइप के सभी टारगेट पर लागू होती हैं.  | 
          
              analysis_test
             | 
            
                          bool;
                                     डिफ़ॉल्ट तौर पर Falseहोता है अगर यह 'सही है' पर सेट है, तो इस नियम को विश्लेषण की जांच के तौर पर माना जाता है. ध्यान दें: विश्लेषण के टेस्ट के नियमों को मुख्य तौर पर, Starlark की कोर लाइब्रेरी में दिए गए इन्फ़्रास्ट्रक्चर का इस्तेमाल करके तय किया जाता है. दिशा-निर्देशों के लिए, टेस्टिंग देखें. अगर किसी नियम को विश्लेषण टेस्ट नियम के तौर पर तय किया जाता है, तो उसे अपने एट्रिब्यूट पर analysis_test_transition का इस्तेमाल करके तय किए गए कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल करने की अनुमति मिल जाती है. हालांकि, इस पर कुछ पाबंदियां लागू होती हैं: 
  | 
          
              build_setting
             | 
            
                          BuildSetting या None;
                                     डिफ़ॉल्ट तौर पर Noneहै अगर यह सेट है, तो यह बताता है कि यह नियम किस तरह का build setting है. config मॉड्यूल देखें. अगर यह सेट है, तो इस नियम में "build_setting_default" नाम का ज़रूरी एट्रिब्यूट अपने-आप जुड़ जाता है. यह एट्रिब्यूट, यहां दी गई वैल्यू के हिसाब से टाइप के साथ जुड़ता है.
             | 
          
              cfg
             | 
            
                                     डिफ़ॉल्ट रूप से Noneहोता है अगर यह सेट है, तो यह उस कॉन्फ़िगरेशन ट्रांज़िशन को दिखाता है जिसपर विश्लेषण से पहले, नियम अपने कॉन्फ़िगरेशन पर लागू होगा.  | 
          
              exec_groups
             | 
            
                          dict या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है एक डिक्शनरी, जिसमें एक्ज़ीक्यूशन ग्रुप का नाम (स्ट्रिंग) exec_group में बदला जाता है. अगर यह सेट होता है, तो नियमों को एक ही टारगेट में, कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप का दस्तावेज़ देखें.
             | 
          
              initializer
             | 
            
                                     डिफ़ॉल्ट रूप से Noneहोता है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे  इसे एट्रिब्यूट के नामों से लेकर मनचाही वैल्यू तक की डिक्शनरी दिखानी होती है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती है उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर  इनिशियलाइज़र का आकलन, एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू से पहले किया जाता है. इसलिए, अगर इनिशियलाइज़र के सिग्नेचर में किसी पैरामीटर में डिफ़ॉल्ट वैल्यू शामिल होती है, तो यह एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू को बदल देता है. हालांकि, ऐसा तब नहीं होता, जब  इसी तरह, अगर इनिशियलाइज़र के सिग्नेचर में मौजूद किसी पैरामीटर की कोई डिफ़ॉल्ट वैल्यू नहीं है, तो पैरामीटर को ज़रूरी बना दिया जाएगा. ऐसे मामलों में, किसी एट्रिब्यूट की परिभाषा में डिफ़ॉल्ट/अनिवार्य सेटिंग शामिल न करना बेहतर होता है. ऐसे एट्रिब्यूट के लिए  एक्सटेंड किए गए नियमों के मामले में, सभी इनिशियलाइज़र को चाइल्ड से लेकर एंसेस्टर तक कॉल किया जाता है. हर इनिशियलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता है.  | 
          
              parent
             | 
            
                                     डिफ़ॉल्ट रूप से Noneहोता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. इस विकल्प को सेट करने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज की जाती हैं. लेगसी या बंद किए गए पैरामीटर सेट नहीं किए जा सकते. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद, पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg को लागू किया जाता है.
             | 
          
              extendable
             | 
            
                          bool; या Label; या string; या None;
                                     डिफ़ॉल्ट रूप से Noneहोता है एक्सपेरिमेंटल: अनुमति वाली सूची का लेबल, जो यह तय करता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि समयसीमा बढ़ाने की अनुमति हमेशा दी जा सके या हमेशा से रोकी जा सके. Bazel, डिफ़ॉल्ट रूप से एक्सटेंशन को हमेशा अनुमति देता है.  | 
          
              subrules
             | 
            
                          sequence of Subrules;
                                     डिफ़ॉल्ट रूप से []होता है एक्सपेरिमेंटल: इस नियम में इस्तेमाल किए गए सबनियमों की सूची.  | 
          
select
unknown select(x, no_match_error='')
select() एक हेल्पर फ़ंक्शन है, जो नियम के एट्रिब्यूट को कॉन्फ़िगर किया जा सकने वाला बनाता है. ज़्यादा जानकारी के लिए, एनसाइक्लोपीडिया बनाना लेख पढ़ें.
          
      पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              x
             | 
            
                          dict;
                                    ज़रूरी है एक डिक्शनरी, जो कॉन्फ़िगरेशन की शर्तों को वैल्यू पर मैप करती है. हर कुंजी एक लेबल या लेबल स्ट्रिंग होती है, जो config_setting या constraint_value इंस्टेंस की पहचान करती है. स्ट्रिंग के बजाय लेबल का इस्तेमाल कब करना है, यह जानने के लिए मैक्रो के बारे में दस्तावेज़ देखें.  | 
          
              no_match_error
             | 
            
                          string;
                                     डिफ़ॉल्ट रूप से ''होता है अगर कोई शर्त पूरी नहीं होती है, तो रिपोर्ट करने के लिए कस्टम गड़बड़ी का वैकल्पिक मैसेज.  | 
          
सबनियम
Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              implementation
             | 
            
                          function;
                                     ज़रूरी है यह सबनियम लागू करने वाला Starlark फ़ंक्शन  | 
          
              attrs
             | 
            
                          dict;
                                     डिफ़ॉल्ट तौर पर {}होता है यह एक डिक्शनरी है, जिसमें सब-नियम के सभी (निजी) एट्रिब्यूट की जानकारी होती है. उप-नियमों में सिर्फ़ ऐसे निजी एट्रिब्यूट हो सकते हैं जिन्हें लेबल टाइप किया गया हो. जैसे, लेबल या लेबल-लिस्ट. इन लेबल से जुड़ी हल की गई वैल्यू, Bazel अपने-आप ही सबनियम के लागू करने वाले फ़ंक्शन को नाम वाले आर्ग्युमेंट के तौर पर पास करता है. इसलिए, लागू करने वाले फ़ंक्शन को एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करने होते हैं. इन वैल्यू के टाइप ये होंगे: 
  | 
          
              toolchains
             | 
            
                          sequence;
                                     डिफ़ॉल्ट तौर पर []सेट होता है अगर सेट किया जाता है, तो इस सबनियम के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन ढूंढे जाएंगे और ctx.toolchains के ज़रिए सबनियम लागू करने के लिए उपलब्ध कराए जाएंगे. ध्यान दें कि अगर यह पैरामीटर सेट है, तो डेटा का इस्तेमाल करने वाले नियमों पर एईजी चालू होने चाहिए. अगर आपने अब तक एईजी पर माइग्रेट नहीं किया है, तो https://bazel.build/extending/auto-exec-groups#migration-aegs देखें.
             | 
          
              fragments
             | 
            
                          sequence of strings;
                                     डिफ़ॉल्ट []होता है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में सबनियम को ज़रूरत होती है  | 
          
              subrules
             | 
            
                          sequence of Subrules;
                                     डिफ़ॉल्ट []होता है इस सबनियम के लिए ज़रूरी अन्य सबनियमों की सूची.  | 
          
tag_class
tag_class tag_class(attrs={}, *, doc=None)
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              attrs
             | 
            
                          dict;
                                     डिफ़ॉल्ट रूप से {}होता है इस टैग क्लास के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. ध्यान दें कि   | 
          
              doc
             | 
            
                          string; या None;
                                     डिफ़ॉल्ट रूप से Noneहोते हैं टैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.  | 
          
visibility
None visibility(value)इससे, फ़िलहाल शुरू किए जा रहे .bzl मॉड्यूल की लोड विज़िबिलिटी सेट की जाती है.
किसी मॉड्यूल के लोड होने की स्थिति से यह तय होता है कि अन्य BUILD और .bzl फ़ाइलें इसे लोड कर सकती हैं या नहीं. (यह .bzl सोर्स फ़ाइल की टारगेट विज़िबिलिटी से अलग है. इससे यह तय होता है कि फ़ाइल, दूसरे टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड करने की सुविधा, पैकेज के लेवल पर काम करती है: किसी मॉड्यूल को लोड करने के लिए, लोड करने वाली फ़ाइल को ऐसे पैकेज में होना चाहिए जिसे मॉड्यूल को दिखाने की अनुमति मिली हो. मॉड्यूल को हमेशा उसके पैकेज में लोड किया जा सकता है. भले ही, वह दिखे या न दिखे.
visibility() को हर .bzl फ़ाइल में सिर्फ़ एक बार कॉल किया जा सकता है. साथ ही, इसे सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, न कि किसी फ़ंक्शन के अंदर. इस कॉल को load() स्टेटमेंट के ठीक नीचे और आर्ग्युमेंट तय करने के लिए ज़रूरी किसी भी लॉजिक के नीचे रखना बेहतर होता है.
अगर फ़्लैग --check_bzl_visibility को 'गलत है' पर सेट किया जाता है, तो लोड विज़िबिलिटी से जुड़े उल्लंघनों के लिए चेतावनियां दिखेंगी. हालांकि, इससे बिल्ड फ़ेल नहीं होगा.
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
              value
             | 
            
                                     ज़रूरी है पैकेज स्पेसिफ़िकेशन स्ट्रिंग की सूची या एक पैकेज स्पेसिफ़िकेशन स्ट्रिंग. पैकेज के ब्यौरे का फ़ॉर्मैट,  
 "@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के डेटाबेस के हिसाब से समझा जाता है. अगर  ध्यान दें कि   |