सदस्य
- analysis_test_transition
- aspect
- configuration_field
- depset
- exec_group
- 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 | ज़रूरी है एक डिक्शनरी, जिसमें ऐसे कॉन्फ़िगरेशन सेटिंग की जानकारी होती है जिन्हें इस कॉन्फ़िगरेशन ट्रांज़िशन की मदद से सेट किया जाना चाहिए. इसमें मौजूद बटन, बिल्ड सेटिंग के लेबल (बिल्ड प्रोसेस के दौरान इस्तेमाल होने वाले विशिष्ट कॉन्फ़िगरेशन विकल्पों से जुड़े, पूरी जानकारी देने वाले नाम या आइडेंटिफ़ायर) हैं और इसकी वैल्यू, ट्रांज़िशन के बाद की नई वैल्यू हैं. किसी भी अन्य सेटिंग में कोई बदलाव नहीं हुआ है. इसका इस्तेमाल करके, उन खास कॉन्फ़िगरेशन सेटिंग के बारे में बताएं जिन्हें विश्लेषण टेस्ट पास करने के लिए सेट करना ज़रूरी है. | 
aspect
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 फ़ंक्शन है, जो इस आसपेक्ट को लागू करता है. इसमें दो पैरामीटर होते हैं: Target (वह टारगेट जिस पर आसपेक्ट लागू किया जाता है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया जाता है). टारगेट के एट्रिब्यूट, ctx.ruleफ़ील्ड के ज़रिए उपलब्ध होते हैं. विश्लेषण के दौरान, इस फ़ंक्शन का आकलन किया जाता है. ऐसा, किसी टारगेट के लिए किसी आसपेक्ट को हर बार लागू करने के लिए किया जाता है. | 
| attr_aspects | स्ट्रिंग का क्रम;
                                     डिफ़ॉल्ट रूप से []होता है एट्रिब्यूट के नामों की सूची. यह आसपेक्ट इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के साथ लागू होता है. आम तौर पर, depsऔरexportsवैल्यू का इस्तेमाल किया जाता है. सूची में एक स्ट्रिंग"*"भी शामिल हो सकती है, ताकि इसे टारगेट की सभी डिपेंडेंसी के साथ लागू किया जा सके. | 
| attrs | dict;
                                     डिफ़ॉल्ट तौर पर {}होता है यह एक डिक्शनरी है, जिसमें आसपेक्ट के सभी एट्रिब्यूट की जानकारी होती है. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. जैसे, `attr.label` या `attr.string` (attr मॉड्यूल देखें). एसपेक्ट एट्रिब्यूट, लागू करने वाले फ़ंक्शन के लिए ctxपैरामीटर के फ़ील्ड के तौर पर उपलब्ध होते हैं.
 ऐसे एट्रिब्यूट जिनकी वैल्यू का पता साफ़ तौर पर चलता है, उनका टाइप  | 
| required_providers | डिफ़ॉल्ट तौर पर यह []होता है इस एट्रिब्यूट की मदद से, आसपेक्ट को सिर्फ़ उन टारगेट तक सीमित किया जा सकता है जिनके नियमों में, ज़रूरी सेवा देने वाली कंपनियों का विज्ञापन होता है. यह वैल्यू, सेवा देने वाली कंपनियों की एक सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]]मान्य वैल्यू है, जबकि[FooInfo, BarInfo, [BazInfo, QuxInfo]]मान्य नहीं है.सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि  किसी नियम (उदाहरण के लिए,  | 
| required_aspect_providers | डिफ़ॉल्ट तौर पर इसकी वैल्यू []होती है इस एट्रिब्यूट की मदद से, इस आसपेक्ट को दूसरे आसपेक्ट की जांच करने की अनुमति मिलती है. यह वैल्यू, सेवा देने वाली कंपनियों की एक सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]]मान्य वैल्यू है, जबकि[FooInfo, BarInfo, [BazInfo, QuxInfo]]मान्य नहीं है.सेवा देने वाली कंपनियों की नेस्ट नहीं की गई सूची, अपने-आप एक ऐसी सूची में बदल जाएगी जिसमें सेवा देने वाली कंपनियों की एक सूची हो. इसका मतलब है कि  किसी दूसरे आसपेक्ट (जैसे,  | 
| provides | डिफ़ॉल्ट रूप से []होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन की रिटर्न वैल्यू में ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट,  | 
| requires | sequence of Aspects;
                                     डिफ़ॉल्ट रूप से []होता है इस आसपेक्ट से पहले, लागू किए जाने वाले आसपेक्ट की सूची. | 
| fragments | sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है. | 
| host_fragments | sequence of strings;
                                     डिफ़ॉल्ट तौर पर यह []होता है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी होस्ट कॉन्फ़िगरेशन में, आसपेक्ट को ज़रूरत होती है. | 
| toolchains | sequence;
                                     डिफ़ॉल्ट तौर पर []सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन ढूंढे जाएंगे और ctx.toolchainके ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे. | 
| incompatible_use_toolchain_transition | डिफ़ॉल्ट रूप से Falseहोता है इस्तेमाल नहीं किया जाता. इसे हटा दिया जाना चाहिए. | 
| doc | स्ट्रिंग या None;
                                     डिफ़ॉल्ट तौर परNoneहोता है दस्तावेज़ जनरेट करने वाले टूल से निकाले जा सकने वाले आसपेक्ट की जानकारी. | 
| apply_to_generating_rules | डिफ़ॉल्ट तौर पर 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 | ज़रूरी है कॉन्फ़िगरेशन फ़्रैगमेंट का नाम, जिसमें लेट-बाउंड वैल्यू शामिल है. | 
| name | ज़रूरी है उस वैल्यू का नाम जो कॉन्फ़िगरेशन फ़्रैगमेंट से मिलने वाला है. | 
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 | डिफ़ॉल्ट तौर पर "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;
                                     डिफ़ॉल्ट तौर पर []होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है. | 
module_extension
unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| implementation | ज़रूरी है यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर होना चाहिए, module_ctx. उपलब्ध रिपॉज़िटरी का सेट तय करने के लिए, फ़ंक्शन को बिल्ड की शुरुआत में एक बार कॉल किया जाता है. | 
| tag_classes | डिफ़ॉल्ट रूप से {}होता है एक्सटेंशन के ज़रिए इस्तेमाल की जाने वाली सभी टैग क्लास की जानकारी देने के लिए डिक्शनरी. यह टैग क्लास के नाम को tag_classऑब्जेक्ट से मैप करता है. | 
| doc | string; या None;
                                     डिफ़ॉल्ट रूप सेNoneहोता है मॉड्यूल एक्सटेंशन की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. | 
| environ | sequence of strings;
                                     डिफ़ॉल्ट तौर पर []होता है एनवायरमेंट वैरिएबल की वह सूची उपलब्ध कराता है जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा. | 
| 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 | 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)
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| implementation | ज़रूरी है यह वह फ़ंक्शन है जो इस नियम को लागू करता है. इसमें एक पैरामीटर, repository_ctxहोना चाहिए. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोडिंग फ़ेज़ के दौरान कॉल किया जाता है. | 
| attrs | dict या None;
                                     डिफ़ॉल्ट तौर परNoneहोता है यह एक डिक्शनरी है, जिसमें नियम के सभी एट्रिब्यूट की जानकारी होती है. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. _से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल में लेबल पर लागू होने वाली डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटाबेस का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं हो सकता.nameएट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती. | 
| local | डिफ़ॉल्ट Falseहोता है यह बताते हैं यह नियम, सबकुछ स्थानीय सिस्टम से फ़ेच करता है और हर फ़ेच के बाद, इसका फिर से आकलन किया जाना चाहिए. | 
| environ | sequence of strings;
                                     डिफ़ॉल्ट []होता है अब इस्तेमाल नहीं किया जा सकता. इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, 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=[])नियमों को .bzl फ़ाइल में ग्लोबल वैरिएबल को असाइन किया जाना चाहिए. जो ग्लोबल वैरिएबल का नाम होता है, वही नियम का नाम होता है.
जांच के नियमों के नाम के आखिर में _test होना चाहिए. वहीं, अन्य सभी नियमों के नाम के आखिर में यह सफ़िक्स नहीं होना चाहिए. (यह पाबंदी सिर्फ़ नियमों पर लागू होती है, उनके टारगेट पर नहीं.)
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| implementation | ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह ऐक्शन बनाकर, तय किए गए सभी आउटपुट जनरेट करेगा. | 
| test | bool;
                                     डिफ़ॉल्ट तौर पर unboundहोता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze testनिर्देश का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप एक्ज़ीक्यूटेबल माना जाता है. किसी टेस्ट नियम के लिए,executable = Trueको साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. डिफ़ॉल्ट रूप से, इसकी वैल्यूFalseहोती है. ज़्यादा जानकारी के लिए,  नियमों का पेज देखें. | 
| attrs | dict;
                                     डिफ़ॉल्ट तौर पर {}होता है नियम के सभी एट्रिब्यूट की जानकारी देने वाली डिक्शनरी. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. _से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है.nameएट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती.visibility,deprecation,tags,testonly, औरfeaturesएट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन, attrs के साइज़ पर सीमा लगाता है. | 
| outputs | dict; या None; या function;
                                     डिफ़ॉल्ट रूप सेNoneहोता है अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इसके भरोसे न रहें. ---incompatible_no_rule_outputs_paramके साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपके कोड, इस जल्द ही हटाए जाने वाले फ़ैसले से कोई दिक्कत नहीं होगी.इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, OutputGroupInfoयाattr.outputका इस्तेमाल करने के लिए, नियमों को माइग्रेट करें.पहले से तय किए गए आउटपुट को तय करने के लिए स्कीमा.  इस आर्ग्युमेंट की वैल्यू, कोई डिक्शनरी या डिक्शनरी बनाने वाली कोई कॉलबैक फ़ंक्शन होती है. कॉलबैक, कैलकुलेट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच किए जाते हैं. उदाहरण के लिए, अगर आपने परिभाषा  डिक्शनरी में मौजूद हर एंट्री, पहले से तय किया गया आउटपुट बनाती है. इसमें कुंजी एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होता है, जो आउटपुट के लेबल को तय करता है. नियम को लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर, फ़ील्ड का वह नाम बन जाता है जिसका इस्तेमाल  
 आम तौर पर, बदले जाने वाले वैल्यू के लिए सबसे ज़्यादा इस्तेमाल किया जाने वाला प्लेसहोल्डर  | 
| executable | bool;
                                     डिफ़ॉल्ट रूप से unboundहोता है यह तय करता है कि इस नियम को लागू किया जा सकता है या नहीं. इसका मतलब है कि क्या यह blaze runनिर्देश का विषय हो सकता है. यह डिफ़ॉल्ट रूप सेFalseपर सेट होता है. ज़्यादा जानकारी के लिए,  नियमों का पेज देखें. | 
| output_to_genfiles | डिफ़ॉल्ट तौर पर Falseहै अगर यह 'सही' है, तो फ़ाइलें बिन डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय), तो इस फ़्लैग को सेट न करें. | 
| fragments | sequence of strings;
                                     डिफ़ॉल्ट रूप से []है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है. | 
| host_fragments | sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनकी ज़रूरत होस्ट कॉन्फ़िगरेशन में नियम के लिए होती है. | 
| _skylark_testable | डिफ़ॉल्ट तौर पर Falseहोता है (एक्सपेरिमेंट के तौर पर उपलब्ध) अगर यह विकल्प चालू है, तो यह नियम, उन नियमों के लिए अपनी कार्रवाइयां दिखाएगा जो Actionsप्रोवाइडर के ज़रिए इस पर निर्भर हैं. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध कराया जाता है.इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. ऐसा हो सकता है कि आने वाले समय में इस फ़्लैग को हटा दिया जाए. | 
| toolchains | sequence;
                                     डिफ़ॉल्ट तौर पर []सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन ढूंढे जाएंगे और ctx.toolchainके ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे. | 
| incompatible_use_toolchain_transition | डिफ़ॉल्ट रूप से Falseहोता है इस्तेमाल नहीं किया जाता. इसे हटा दिया जाना चाहिए. | 
| doc | स्ट्रिंग या None;
                                     डिफ़ॉल्ट रूप सेNoneहोता है नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. | 
| provides | डिफ़ॉल्ट रूप से []होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए. अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन की रिटर्न वैल्यू में ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां नहीं दिए गए हैं. सूची का हर एलिमेंट,  | 
| exec_compatible_with | sequence of strings;
                                     डिफ़ॉल्ट रूप से []होता है यह, एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची है जो इस नियम टाइप के सभी टारगेट पर लागू होती हैं. | 
| analysis_test | डिफ़ॉल्ट रूप से 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 | ज़रूरी है एक डिक्शनरी, जो कॉन्फ़िगरेशन की शर्तों को वैल्यू पर मैप करती है. हर कुंजी एक लेबल या लेबल स्ट्रिंग होती है, जो config_setting या constraint_value इंस्टेंस की पहचान करती है. स्ट्रिंग के बजाय लेबल का इस्तेमाल कब करना है, यह जानने के लिए मैक्रो के बारे में दस्तावेज़ देखें. | 
| no_match_error | डिफ़ॉल्ट वैल्यू ''है कोई भी शर्त पूरी न होने पर, रिपोर्ट करने के लिए कस्टम गड़बड़ी का मैसेज (ज़रूरी नहीं). | 
सबनियम
Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| implementation | function;
                                     ज़रूरी है यह सबनियम लागू करने वाला Starlark फ़ंक्शन | 
| attrs | dict;
                                     डिफ़ॉल्ट तौर पर {}होता है यह एक डिक्शनरी है, जिसमें सब-नियम के सभी (निजी) एट्रिब्यूट की जानकारी होती है. उप-नियमों में सिर्फ़ ऐसे निजी एट्रिब्यूट हो सकते हैं जिन्हें लेबल टाइप किया गया हो. जैसे, लेबल या लेबल-लिस्ट. इन लेबल से जुड़ी हल की गई वैल्यू, Bazel अपने-आप ही सबनियम के लागू करने वाले फ़ंक्शन को नाम वाले आर्ग्युमेंट के तौर पर पास करता है. इसलिए, लागू करने वाले फ़ंक्शन को एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करने होते हैं. इन वैल्यू के टाइप ये होंगे: 
 | 
| toolchains | sequence;
                                     डिफ़ॉल्ट तौर पर []सेट होता है अगर सेट किया जाता है, तो इस सबनियम के लिए ज़रूरी टूल चेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूल चेन ढूंढे जाएंगे और ctx.toolchainsके ज़रिए सबनियम लागू करने के लिए उपलब्ध कराए जाएंगे. | 
| fragments | sequence of strings;
                                     डिफ़ॉल्ट []होता है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में सबनियम को ज़रूरत होती है | 
| subrules | sequence of Subrules;
                                     डिफ़ॉल्ट []होता है इस सबनियम के लिए ज़रूरी अन्य सबनियमों की सूची. | 
tag_class
tag_class tag_class(attrs={}, *, doc=None)
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| attrs | डिफ़ॉल्ट रूप से {}होता है इस टैग क्लास के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह किसी एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें. | 
| doc | string; या None;
                                     डिफ़ॉल्ट रूप सेNoneहोते हैं टैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. | 
visibility
None visibility(value)इससे, फ़िलहाल शुरू किए जा रहे .bzl मॉड्यूल की लोड विज़िबिलिटी सेट की जाती है.
किसी मॉड्यूल के लोड होने की स्थिति से यह तय होता है कि अन्य BUILD और .bzl फ़ाइलें इसे लोड कर सकती हैं या नहीं. (यह .bzl सोर्स फ़ाइल की टारगेट विज़िबिलिटी से अलग है. इससे यह तय होता है कि फ़ाइल, दूसरे टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड करने की सुविधा, पैकेज के लेवल पर काम करती है: किसी मॉड्यूल को लोड करने के लिए, लोड करने वाली फ़ाइल को ऐसे पैकेज में होना चाहिए जिसे मॉड्यूल को दिखाने की अनुमति मिली हो. मॉड्यूल को हमेशा उसके पैकेज में लोड किया जा सकता है. भले ही, वह दिखे या न दिखे.
visibility() को हर .bzl फ़ाइल में सिर्फ़ एक बार कॉल किया जा सकता है. साथ ही, इसे सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, न कि किसी फ़ंक्शन के अंदर. इस कॉल को load() स्टेटमेंट के ठीक नीचे और आर्ग्युमेंट तय करने के लिए ज़रूरी किसी भी लॉजिक के नीचे रखना बेहतर होता है.
अगर फ़्लैग --check_bzl_visibility को 'गलत है' पर सेट किया जाता है, तो लोड विज़िबिलिटी से जुड़े उल्लंघनों के लिए चेतावनियां दिखेंगी. हालांकि, इससे बिल्ड फ़ेल नहीं होगा.
          
      
पैरामीटर
| पैरामीटर | ब्यौरा | 
|---|---|
| value | ज़रूरी है पैकेज स्पेसिफ़िकेशन स्ट्रिंग की सूची या एक पैकेज स्पेसिफ़िकेशन स्ट्रिंग. पैकेज के ब्यौरे का फ़ॉर्मैट,  
 "@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के डेटाबेस के हिसाब से समझा जाता है. अगर  ध्यान दें कि  |