पैसे चुकाकर बने सदस्य
- analysis_test_transition
- आसपेक्ट
- configuration_field
- डिप्सेट
- exec_group
- module_extension
- provider
- repository_rule
- नियम
- चुनें
- सबनियम
- tag_class
- किसको दिखे
analysis_test_transition
transition analysis_test_transition(settings)
विश्लेषण-टेस्ट नियम की डिपेंडेंसी पर लागू करने के लिए, कॉन्फ़िगरेशन ट्रांज़िशन बनाता है. यह ट्रांज़िशन सिर्फ़ analysis_test = True
वाले नियमों के एट्रिब्यूट पर लागू किया जा सकता है. इस तरह के नियम, फ़ंक्शन के हिसाब से सीमित होते हैं. उदाहरण के लिए, उनके डिपेंडेंसी ट्री का साइज़ सीमित होता है. इसलिए, transition()
का इस्तेमाल करके बनाए गए ट्रांज़िशन की तुलना में, इस फ़ंक्शन का इस्तेमाल करके बनाए गए ट्रांज़िशन की संख्या सीमित होती है.
इस फ़ंक्शन को मुख्य तौर पर, विश्लेषण की जांच करने वाले फ़्रेमवर्क की मुख्य लाइब्रेरी को आसान बनाने के लिए डिज़ाइन किया गया है. सबसे सही तरीकों के लिए, इसके दस्तावेज़ या इसे लागू करने के तरीके देखें.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
settings
|
ज़रूरी है एक डिक्शनरी, जिसमें कॉन्फ़िगरेशन सेटिंग के बारे में जानकारी होती है. इस जानकारी को इस कॉन्फ़िगरेशन ट्रांज़िशन के हिसाब से सेट किया जाना चाहिए. कुंजियां, बिल्ड सेटिंग लेबल होती हैं और वैल्यू, ट्रांज़िशन के बाद की नई वैल्यू होती हैं. अन्य सभी सेटिंग में कोई बदलाव नहीं हुआ है. इसका इस्तेमाल करके, कॉन्फ़िगरेशन की उन खास सेटिंग का एलान करें जिन्हें पास करने के लिए, विश्लेषण की जांच को सेट करना ज़रूरी है. |
आसपेक्ट
Aspect aspect(implementation, attr_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])नया पहलू बनाता है. इस फ़ंक्शन का नतीजा ग्लोबल वैल्यू में सेव किया जाना चाहिए. ज़्यादा जानकारी के लिए, कृपया अलग-अलग पहलुओं के बारे में जानकारी देखें.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
ज़रूरी है Starlark फ़ंक्शन, जो इस आसपेक्ट को लागू करने वाले दो पैरामीटर के साथ काम करता है: टारगेट (वह टारगेट जिस पर आसपेक्ट रेशियो लागू किया गया है) और ctx (वह नियम कॉन्टेक्स्ट जिससे टारगेट बनाया गया है). टारगेट के एट्रिब्यूट, ctx.rule फ़ील्ड के ज़रिए उपलब्ध होते हैं. इस फ़ंक्शन का आकलन, विश्लेषण के दौरान किया जाता है. ऐसा, टारगेट पर लागू होने वाले हर पहलू के ऐप्लिकेशन के लिए किया जाता है.
|
attr_aspects
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से यह [] एट्रिब्यूट के नामों की सूची है. यह आसपेक्ट, इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के साथ लागू होती है. यहां सामान्य वैल्यू में deps और exports शामिल हैं. किसी टारगेट की सभी डिपेंडेंसी के साथ लागू करने के लिए, इस सूची में "*" स्ट्रिंग भी शामिल हो सकती है.
|
attrs
|
dict;
डिफ़ॉल्ट तौर पर {} होता हैएक डिक्शनरी, जो आसपेक्ट की सभी विशेषताओं के बारे में बताती है. यह, एट्रिब्यूट के नाम से `attr.label` या `attr.string` जैसे किसी एट्रिब्यूट ऑब्जेक्ट के बारे में मैप करता है (attr मॉड्यूल देखें). आसपेक्ट एट्रिब्यूट, ctx पैरामीटर के फ़ील्ड के तौर पर लागू करने के लिए उपलब्ध हैं.
अश्लील एट्रिब्यूट का टाइप |
required_providers
|
डिफ़ॉल्ट तौर पर यह [] पर सेट हैइस एट्रिब्यूट की मदद से, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) सिर्फ़ उन टारगेट तक पहुंच सकते हैं जिनके नियम, सेवा देने वाली ज़रूरी कंपनियों के विज्ञापन दिखाते हैं. मान एक ऐसी सूची होनी चाहिए जिसमें अलग-अलग या सेवा देने वाली कंपनियों की सूची हो, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] एक मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.बिना नेस्ट की गई सूची, सेवा देने वाली कंपनियों की एक सूची में अपने-आप बदल जाएगी. इसका मतलब है कि कुछ नियम (जैसे, |
required_aspect_providers
|
डिफ़ॉल्ट तौर पर यह [] पर सेट होता हैइस एट्रिब्यूट की मदद से, इस पहलू की दूसरे पहलुओं की जांच की जा सकती है. मान एक ऐसी सूची होनी चाहिए जिसमें अलग-अलग या सेवा देने वाली कंपनियों की सूची हो, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] एक मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.बिना नेस्ट की गई सूची, सेवा देने वाली कंपनियों की एक सूची में अपने-आप बदल जाएगी. इसका मतलब है कि इस पहलू को कोई दूसरा पहलू (जैसे कि |
provides
|
डिफ़ॉल्ट तौर पर यह [] पर सेट होता हैसेवा देने वाली कंपनियों की ऐसी सूची होती है जिन्हें लागू करने वाले फ़ंक्शन को दिखाना ज़रूरी होता है. अगर लागू करने वाला फ़ंक्शन, यहां सूची में दी गई किसी भी सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह एक गड़बड़ी है. हालांकि, लागू करने का फ़ंक्शन, सेवा देने वाली ऐसी कंपनियां दिखा सकता है जो यहां दी गई सूची में शामिल नहीं हैं. सूची का हर एलिमेंट, |
requires
|
आसपेक्ट का क्रम;
डिफ़ॉल्ट तौर पर [] हैइस पहलू से पहले लागू किए जाने वाले पहलुओं की सूची. |
fragments
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची होती है जो टारगेट कॉन्फ़िगरेशन में पहलू के लिए ज़रूरी होते हैं. |
host_fragments
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची होती है जिनकी ज़रूरत, होस्ट कॉन्फ़िगरेशन में होती है. |
toolchains
|
क्रम;
डिफ़ॉल्ट रूप से [] सेट होता हैअगर यह सेट किया जाता है, तो इस नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. इन्हें किसी भी कॉम्बिनेशन में शामिल किया जा सकता है. टूल चेन मौजूदा प्लैटफ़ॉर्म की जांच करने पर मिलेगी और नियम लागू करने के लिए ctx.toolchain की मदद से उन्हें उपलब्ध कराया जाएगा.
|
incompatible_use_toolchain_transition
|
डिफ़ॉल्ट तौर पर यह False पर सेट हैअब सेवा में नहीं है. इसका इस्तेमाल नहीं किया जा सकता. इसलिए, इसे हटा देना चाहिए. |
doc
|
string; या None ;
डिफ़ॉल्ट तौर पर None होता हैपहलू की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है. |
apply_to_generating_rules
|
डिफ़ॉल्ट तौर पर यह False पर सेट होता हैअगर विकल्प सही है, तो आउटपुट फ़ाइल पर लागू किए जाने पर, यह आउटपुट फ़ाइल को जनरेट करने के नियम पर लागू होगा. उदाहरण के लिए, मान लें कि कोई आसपेक्ट, `deps` विशेषता के ज़रिए ट्रांज़िट रूप से लागू होता है और `ऐल्फ़ा` को टारगेट करने पर इसे लागू किया जाता है. मान लीजिए कि `ऐल्फ़ा` में `deps = [':beta_return']`, जहां `बीटा_आउटपुट` टारगेट `बीटा` का एलान किया गया आउटपुट है. मान लीजिए कि `बीटा` में कोई टारगेट `चार्ली` है, तो यह आसपेक्ट के ज़रिए लागू होगा. डिफ़ॉल्ट रूप से 'गलत'. |
exec_compatible_with
|
स्ट्रिंग का क्रम. डिफ़ॉल्ट रूप से यह [] एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद पाबंदियों की एक सूची होती है, जो इस आसपेक्ट के सभी इंस्टेंस पर लागू होती है. |
exec_groups
|
dict; या None ;
डिफ़ॉल्ट रूप से, None एक्ज़ीक्यूट करने वाले ग्रुप के नाम (स्ट्रिंग) का लिखवाने की सुविधा, exec_group s पर सेट होती है. सेट किए जाने पर, पहलुओं को एक ही इंस्टेंस में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति देता है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप के दस्तावेज़ देखें.
|
subrules
|
उप-नियम का क्रम;
डिफ़ॉल्ट रूप से [] प्रयोग के तौर पर इस्तेमाल किया जाता है: इस पहलू के लिए इस्तेमाल किए गए उप-नियमों की सूची. |
configuration_field
LateBoundDefault configuration_field(fragment, name)label टाइप के एट्रिब्यूट के लिए, देरी से चलने वाली डिफ़ॉल्ट वैल्यू का रेफ़रंस देता है. अगर वैल्यू को तय करने से पहले, कॉन्फ़िगरेशन बनाना ज़रूरी है, तो वैल्यू 'लेट-बाउंड' होती है. इसे वैल्यू के रूप में इस्तेमाल करने वाला कोई भी एट्रिब्यूट निजी होना चाहिए.
इस्तेमाल के उदाहरण:
नियम एट्रिब्यूट तय करना:
'_foo': attr.label(default=configuration_field(fragment='java', name='toolchain'))
लागू किए गए नियम को ऐक्सेस करने के लिए:
def _rule_impl(ctx): foo_info = ctx.attr._foo ...
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
fragment
|
ज़रूरी है कॉन्फ़िगरेशन फ़्रैगमेंट का नाम, जिसमें लेट-बाउंड वैल्यू है. |
name
|
ज़रूरी है कॉन्फ़िगरेशन फ़्रैगमेंट से वैल्यू पाना ज़रूरी है. |
Depset
depset depset(direct=None, order="default", *, transitive=None)डिप्सेट बनाता है.
direct
पैरामीटर, डिपसेट के डायरेक्ट एलिमेंट की सूची है. साथ ही, transitive
पैरामीटर, डिपसेट की सूची है. इसके एलिमेंट, बनाए गए डेपसेट के इनडायरेक्ट एलिमेंट बन जाते हैं. डिपसेट को सूची में बदलने पर एलिमेंट को दिखाने का क्रम order
पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, जानकारी देने वाले दस्तावेज़ की खास जानकारी देखें.
किसी डिपसेट के सभी एलिमेंट (डायरेक्ट और इनडायरेक्ट) एक ही तरह के होने चाहिए, जैसा कि type(x)
एक्सप्रेशन से मिलता है.
इटरेशन के दौरान डुप्लीकेट हटाने के लिए, हैश-आधारित सेट का इस्तेमाल किया जाता है. इसलिए, डिपसेट के सभी एलिमेंट हैश किए जा सकने वाले होने चाहिए. हालांकि, फ़िलहाल इस वैरिएंट की जांच सभी कंस्ट्रक्टर पर लगातार नहीं की जाती है. लगातार जांच करने की सुविधा चालू करने के लिए, --insupported_always_check_depset_elements फ़्लैग का इस्तेमाल करें; आने वाले समय की रिलीज़ में यह डिफ़ॉल्ट व्यवहार होगा; समस्या 10313 देखें.
इसके अलावा, यह ज़रूरी है कि एलिमेंट ऐसे हों जिन्हें बदला न जा सके. हालांकि, आने वाले समय में इस पाबंदी में छूट दी जाएगी.
बनाए गए डिप्सेट का क्रम, उसके transitive
डिपेसेट के क्रम के साथ काम करना चाहिए. "default"
का ऑर्डर किसी दूसरे ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर सिर्फ़ उन ऑर्डर के लिए हैं जो किसी और ऑर्डर के लिए इस्तेमाल किए जा सकते हैं.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
direct
|
क्रम; या None ;
डिफ़ॉल्ट रूप से None होता हैडिपसेट के डायरेक्ट एलिमेंट की सूची. |
order
|
डिफ़ॉल्ट तौर पर यह "default" पर सेट होती हैनए डेटा सेट के लिए ट्रैवर्सल रणनीति. संभावित वैल्यू देखने के लिए यहां जाएं. |
transitive
|
depset का क्रम; या None ;
डिफ़ॉल्ट हैNone डिपसेट की सूची जिसके एलिमेंट, डिपसेट के इनडायरेक्ट एलिमेंट बन जाएंगे. |
exec_group
exec_group exec_group(toolchains=[], exec_compatible_with=[])एक एक्ज़ीक्यूशन ग्रुप बनाता है, जिसका इस्तेमाल नियम लागू करने के दौरान, किसी खास एक्ज़ीक्यूशन प्लैटफ़ॉर्म के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
toolchains
|
क्रम; डिफ़ॉल्ट तौर पर [] होता हैइस निष्पादन ग्रुप के लिए ज़रूरी टूलचेन का सेट. सूची में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. इन्हें किसी भी कॉम्बिनेशन में शामिल किया जा सकता है. |
exec_compatible_with
|
स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से यह [] एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर पाबंदियों की सूची होता है. |
module_extension
unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)एक नया मॉड्यूल एक्सटेंशन बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे एक्सपोर्ट किया जा सके और MODULE.bazel फ़ाइल में इस्तेमाल किया जा सके.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
ज़रूरी है वह फ़ंक्शन जो इस मॉड्यूल एक्सटेंशन को लागू करता है. सिर्फ़ एक पैरामीटर होना चाहिए, module_ctx . इस सुविधा को बिल्ड की शुरुआत में एक बार कॉल किया जाता है, ताकि उपलब्ध डेटा स्टोर करने की जगहों का सेट तय किया जा सके.
|
tag_classes
|
डिफ़ॉल्ट तौर पर यह {} पर सेट होता हैएक डिक्शनरी, जो एक्सटेंशन में इस्तेमाल की गई सभी टैग क्लास के बारे में बताती है. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट को मैप करता है.
|
doc
|
string; या None ;
डिफ़ॉल्ट रूप से None पर सेट होता हैमॉड्यूल एक्सटेंशन का ब्यौरा, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है. |
environ
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] हैएनवायरमेंट वैरिएबल की सूची देता है, जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा. |
os_dependent
|
डिफ़ॉल्ट पर सेट है False इससे पता चलता है कि यह एक्सटेंशन, ओएस पर निर्भर करता है या नहीं |
arch_dependent
|
डिफ़ॉल्ट पर सेट है False इससे पता चलता है कि यह एक्सटेंशन, आर्किटेक्चर पर निर्भर है या नहीं |
कंपनी
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
|
स्ट्रिंग या 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)डेटा स्टोर करने की जगह का नया नियम बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे लोड किया जा सके और WORKSPACE फ़ाइल से कॉल किया जा सके.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
ज़रूरी है वह फ़ंक्शन जो इस नियम को लागू करता है. इसमें सिर्फ़ एक पैरामीटर होना चाहिए, repository_ctx . फ़ंक्शन को लोड होने के दौरान, नियम के हर इंस्टेंस के लिए कॉल किया जाता है.
|
attrs
|
dict या None ;
नियम के सभी एट्रिब्यूट के बारे में बताने के लिए, None डिक्शनरी डिफ़ॉल्ट रूप से सेट होती है. यह एट्रिब्यूट के नाम से एट्रिब्यूट ऑब्जेक्ट में मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल किसी फ़ाइल में किसी लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटा स्टोर करने की जगह का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं हो सकता. name एट्रिब्यूट में साफ़ तौर पर जानकारी जोड़ी गई है और इसे तय नहीं किया जाना चाहिए.
|
local
|
डिफ़ॉल्ट तौर पर यह False पर सेट होता हैइससे पता चलता है कि इस नियम के तहत, लोकल सिस्टम से मिलने वाले सभी नतीजे फ़ेच किए जाते हैं. साथ ही, हर बार फ़ेच करने पर इसका फिर से आकलन किया जाना चाहिए. |
environ
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] हैएनवायरमेंट वैरिएबल की ऐसी सूची देता है जिस पर यह रिपॉज़िटरी का नियम निर्भर करता है. अगर उस सूची में मौजूद किसी एनवायरमेंट वैरिएबल में बदलाव होता है, तो रिपॉज़िटरी को फिर से फ़ेच किया जाएगा. |
configure
|
डिफ़ॉल्ट तौर पर False पर सेट हैइससे पता चलता है कि रिपॉज़िटरी, कॉन्फ़िगरेशन के मकसद से सिस्टम की जांच करती है |
remotable
|
डिफ़ॉल्ट तौर पर, यह सेटिंग False एक्सपेरिमेंटल पर सेट होती है. इस पैरामीटर पर एक्सपेरिमेंट जारी है और यह किसी भी समय बदल सकता है. कृपया इस पर निर्भर न रहें. इसे ---experimental_repo_remote_exec रिमोट एक्ज़ीक्यूट करने की सुविधा के साथ काम करता है" को सेट करके, एक्सपेरिमेंट के तौर पर चालू किया जा सकता है |
doc
|
string; या None ;
डिफ़ॉल्ट रूप से None पर सेट होता हैडेटा स्टोर करने की जगह के नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है. |
नियम
callable rule(implementation, *, test=unbound, attrs={}, outputs=None, executable=unbound, output_to_genfiles=False, fragments=[], host_fragments=[], _skylark_testable=False, toolchains=[], incompatible_use_toolchain_transition=False, doc=None, provides=[], exec_compatible_with=[], analysis_test=False, build_setting=None, cfg=None, exec_groups=None, initializer=None, parent=None, extendable=None, subrules=[])एक नया नियम बनाता है, जिसे BUILD फ़ाइल या मैक्रो से कॉल करके टारगेट बनाया जा सकता है.
.bzl फ़ाइल में ग्लोबल वैरिएबल के लिए नियम असाइन किए जाने चाहिए; ग्लोबल वैरिएबल का नाम नियम का नाम होता है.
जांच के नियमों के लिए, नाम के आखिर में _test
होना ज़रूरी है. हालांकि, दूसरे सभी नियमों के लिए यह सफ़िक्स नहीं होना चाहिए. (यह पाबंदी सिर्फ़ नियमों पर लागू होती है, उनके टारगेट पर नहीं.)
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
ज़रूरी है इस नियम को लागू करने वाले Starlark फ़ंक्शन में सिर्फ़ एक पैरामीटर होना चाहिए: ctx. विश्लेषण के दौरान, नियम के हर इंस्टेंस के लिए फ़ंक्शन को कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट ऐक्सेस कर सकता है. बताए गए सभी आउटपुट जनरेट करने के लिए, इसे कार्रवाइयां करनी होंगी. |
test
|
bool;
डिफ़ॉल्ट है unbound क्या यह नियम जांच का नियम है, यानी कि यह blaze test निर्देश के तहत आता है या नहीं. जांच के सभी नियम अपने-आप लागू करने लायक माने जाते हैं. जांच के नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है. हालांकि, हम ऐसा करने की सलाह नहीं देते. यह वैल्यू डिफ़ॉल्ट रूप से False होती है. ज़्यादा जानकारी के लिए, नियमों वाला पेज देखें.
|
attrs
|
dict;
नियम की सभी विशेषताओं के बारे में बताने के लिए {} डिक्शनरी डिफ़ॉल्ट रूप से सेट होती है. यह एट्रिब्यूट के नाम से एट्रिब्यूट ऑब्जेक्ट में मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल किसी लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट में साफ़ तौर पर जानकारी जोड़ी गई है और इसे तय नहीं किया जाना चाहिए. visibility , deprecation , tags , testonly , और features एट्रिब्यूट को साफ़ तौर पर जोड़ा गया है और उसे बदला नहीं जा सकता. ज़्यादातर नियमों में कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन attrs के साइज़ पर कैप लागू करता है.
|
outputs
|
dict; या None ; या फ़ंक्शन;
डिफ़ॉल्ट रूप से None अब काम नहीं करता है. यह पैरामीटर अब काम नहीं करता है. इसे जल्द ही हटा दिया जाएगा. कृपया इस पर निर्भर न रहें. यह ---incompatible_no_rule_outputs_param के साथ बंद है. इस फ़्लैग का इस्तेमाल करके, पुष्टि करें कि आपका कोड जल्द ही हटाए जाने के लिए तैयार है. यह पैरामीटर अब काम नहीं करता. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए, नियमों को माइग्रेट करें. पहले से तय किए गए आउटपुट तय करने के लिए स्कीमा. इस आर्ग्युमेंट की वैल्यू या तो डिक्शनरी या कॉलबैक फ़ंक्शन है, जो डिक्शनरी बनाता है. कॉलबैक, कंप्यूट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नामों का मिलान, नियम के एट्रिब्यूट से किया जाता है. उदाहरण के लिए, अगर आपने डिक्शनरी में हर एंट्री, पहले से तय किया गया एक आउटपुट बनाता है. इसमें कुंजी एक आइडेंटिफ़ायर होता है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है, जो आउटपुट का लेबल तय करती है. नियम लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर,
व्यावहारिक रूप से, सबसे सामान्य प्रतिस्थापन प्लेसहोल्डर |
executable
|
bool;
डिफ़ॉल्ट है unbound क्या इस नियम को एक्ज़ीक्यूटेबल माना जाता है. इसका मतलब है कि क्या यह blaze run निर्देश के तहत आता है. यह डिफ़ॉल्ट रूप से False को सेट करता है. ज़्यादा जानकारी के लिए, नियमों वाला पेज देखें.
|
output_to_genfiles
|
यह वैल्यू डिफ़ॉल्ट तौर पर False पर सेट होती हैसही होने पर, फ़ाइलें बिन डायरेक्ट्री के बजाय, genfiles डायरेक्ट्री में जनरेट की जाएंगी. जब तक मौजूदा नियमों (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय) के साथ काम करने के लिए इसकी ज़रूरत न हो, तब तक यह फ़्लैग सेट न करें. |
fragments
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची होती है जिनकी टारगेट कॉन्फ़िगरेशन में नियम की ज़रूरत होती है. |
host_fragments
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची होती है जिनकी होस्ट कॉन्फ़िगरेशन में नियम के लिए ज़रूरत होती है. |
_skylark_testable
|
डिफ़ॉल्ट तौर पर यह False (प्रयोग के तौर पर उपलब्ध) सही होने पर, इस नियम के तहत, अपनी कार्रवाइयों की जांच Actions की मदद से किए जाने वाले नियमों के तहत की जाएगी. सेवा देने वाली कंपनी, ctx.created_actions() को कॉल करके नियम के लिए भी उपलब्ध है.इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में इस फ़्लैग को हटाया जा सकता है. |
toolchains
|
क्रम;
डिफ़ॉल्ट रूप से [] सेट होता हैअगर यह सेट किया जाता है, तो इस नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. इन्हें किसी भी कॉम्बिनेशन में शामिल किया जा सकता है. टूल चेन मौजूदा प्लैटफ़ॉर्म की जांच करने पर मिलेगी और नियम लागू करने के लिए ctx.toolchain की मदद से उन्हें उपलब्ध कराया जाएगा.
|
incompatible_use_toolchain_transition
|
डिफ़ॉल्ट तौर पर यह False पर सेट हैअब सेवा में नहीं है. इसका इस्तेमाल नहीं किया जा सकता. इसलिए, इसे हटा देना चाहिए. |
doc
|
string; या None ;
डिफ़ॉल्ट रूप से None पर सेट होता हैनियम का ब्यौरा, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. |
provides
|
डिफ़ॉल्ट तौर पर यह [] पर सेट होता हैसेवा देने वाली कंपनियों की ऐसी सूची होती है जिन्हें लागू करने वाले फ़ंक्शन को दिखाना ज़रूरी होता है. अगर लागू करने वाला फ़ंक्शन, यहां सूची में दी गई किसी भी सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह एक गड़बड़ी है. हालांकि, लागू करने का फ़ंक्शन, सेवा देने वाली ऐसी कंपनियां दिखा सकता है जो यहां दी गई सूची में शामिल नहीं हैं. सूची का हर एलिमेंट, |
exec_compatible_with
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर मौजूद उन पाबंदियों की सूची होती है जो इस नियम के सभी टारगेट पर लागू होती हैं. |
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 s पर सेट होती है. अगर नियम सेट किए जाते हैं, तो एक ही टारगेट में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्ज़ीक्यूशन ग्रुप के दस्तावेज़ देखें.
|
initializer
|
डिफ़ॉल्ट वैल्यू None हैएक्सपेरिमेंटल: नियम के एट्रिब्यूट को शुरू करने वाला Stalark फ़ंक्शन. लोड होने के समय, नियम के हर इंस्टेंस के लिए फ़ंक्शन को कॉल किया जाता है. इसे नियम के तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है (सामान्य एट्रिब्यूट के साथ नहीं, जैसे कि इसे एट्रिब्यूट के नामों से मनचाही वैल्यू के लिए एक डिक्शनरी रिटर्न करना होता है. जो एट्रिब्यूट नहीं दिखाए जाते उन पर कोई असर नहीं पड़ता. किसी एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू से पहले, इनिशलाइज़र का आकलन किया जाता है. ऐसे में, अगर इनिशलाइज़र के सिग्नेचर में किसी पैरामीटर में डिफ़ॉल्ट वैल्यू मौजूद है, तो यह एट्रिब्यूट की परिभाषा से डिफ़ॉल्ट वैल्यू को ओवरराइट कर देता है. हालांकि, इसी तरह, अगर इनिशलाइज़र के सिग्नेचर में किसी पैरामीटर का डिफ़ॉल्ट सेट नहीं है, तो पैरामीटर ज़रूरी हो जाएगा. ऐसे मामलों में किसी एट्रिब्यूट डेफ़िनिशन में डिफ़ॉल्ट/ज़रूरी सेटिंग को छोड़ देना बेहतर होता है. जो एट्रिब्यूट हैंडल नहीं किए जाते उनके लिए, नियमों के बढ़ाए जाने पर, सभी शुरू करने वाले को बच्चे से लेकर पूर्वजों तक की कार्रवाई को कहा जाता है. हर इनिशलाइज़र को सिर्फ़ उन सार्वजनिक एट्रिब्यूट को पास किया जाता है जिनके बारे में उसे पता है. |
parent
|
डिफ़ॉल्ट तौर पर यह None पर सेट होता है एक्सपेरिमेंटल: ऐसा स्टैलार्क नियम, जिसे बढ़ाया गया है. सेट किए जाने पर सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट फ़ोल्डर के executable और test से मेल खाता है. fragments , toolchains , exec_compatible_with , और exec_groups की वैल्यू मर्ज कर दी गई हैं. लेगसी या अब काम नहीं करने वाले पैरामीटर सेट नहीं किए जा सकते. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद पैरंट का इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg लागू किया गया है.
|
extendable
|
bool; या लेबल; या स्ट्रिंग; या None ;
डिफ़ॉल्ट है None प्रयोग के तौर पर उपलब्ध: अनुमति वाली सूची का लेबल, जो तय करता है कि कौनसे नियम इस नियम का दायरा बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अस्वीकार करने के लिए, इसे सही/गलत पर भी सेट किया जा सकता है. Bazel डिफ़ॉल्ट रूप से, एक्सटेंशन को हमेशा अनुमति देता है. |
subrules
|
उप-नियम का क्रम;
डिफ़ॉल्ट तौर पर [] एक्सपेरिमेंटल: इस नियम के लिए इस्तेमाल किए गए सब-नियम की सूची. |
चुनें
unknown select(x, no_match_error='')
select()
एक हेल्पर फ़ंक्शन है, जो नियम एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. ज़्यादा जानकारी के लिए एन्साइक्लोपीडिया बनाएं देखें.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
x
|
ज़रूरी है ऐसा लिखवाने की सुविधा जो कॉन्फ़िगरेशन की शर्तों को वैल्यू के साथ मैप करता है. हर कुंजी एक लेबल या एक लेबल स्ट्रिंग होती है, जो config_setting या कंस्ट्रेंट_वैल्यू इंस्टेंस की पहचान करती है. स्ट्रिंग के बजाय लेबल का इस्तेमाल कब करना है, यह जानने के लिए मैक्रो से जुड़ा दस्तावेज़ देखें. |
no_match_error
|
डिफ़ॉल्ट वैल्यू '' हैकोई भी कंडिशन मैच न होने पर, कस्टम गड़बड़ी की जानकारी दें. हालांकि, यह ज़रूरी नहीं है. |
सबरूल
Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])सबनियम का नया इंस्टेंस बनाता है. इस फ़ंक्शन के नतीजे को ग्लोबल वैरिएबल में सेव करने के बाद ही इस्तेमाल किया जा सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
फ़ंक्शन;
ज़रूरी है इस उप-नियम को लागू करने वाला Starlark फ़ंक्शन |
attrs
|
dict;
डिफ़ॉल्ट रूप से {} होता हैएक डिक्शनरी, जो उप-नियम की सभी (निजी) विशेषताओं का एलान करती है. उप-नियमों में सिर्फ़ ऐसे निजी एट्रिब्यूट हो सकते हैं जो लेबल के लिए टाइप किए गए हैं (जैसे, लेबल या लेबल-सूची). इन लेबल से जुड़े समाधान किए गए मान, Bazel से अपने-आप, नाम वाले आर्ग्युमेंट के रूप में, सब-रूल के लागू करने वाले फ़ंक्शन को पास कर देते हैं. इसलिए, एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करने के लिए, लागू करने के फ़ंक्शन की ज़रूरत होती है. ये वैल्यू इस तरह की होंगी:
|
toolchains
|
क्रम; डिफ़ॉल्ट रूप से [] सेट होता हैअगर यह सेट किया जाता है, तो इस उपनियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. इन्हें किसी भी कॉम्बिनेशन में शामिल किया जा सकता है. टूलचेन की खोज करने के लिए, मौजूदा प्लैटफ़ॉर्म की जांच करें और ctx.toolchains के ज़रिए सबनियम लागू करने की प्रक्रिया को उपलब्ध कराएं.
|
fragments
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची होती है जिनकी टारगेट कॉन्फ़िगरेशन में सबरूल की ज़रूरत होती है. |
subrules
|
उपनियम का क्रम;
डिफ़ॉल्ट तौर पर [] इस उप-नियम के लिए ज़रूरी अन्य उप-नियमों की सूची होता है. |
tag_class
tag_class tag_class(attrs={}, *, doc=None)एक नया tag_class ऑब्जेक्ट बनाता है, जो टैग के एक क्लास के लिए एट्रिब्यूट स्कीमा को परिभाषित करता है. ये ऐसे डेटा ऑब्जेक्ट होते हैं जिनका इस्तेमाल किसी मॉड्यूल एक्सटेंशन में किया जा सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
attrs
|
डिफ़ॉल्ट तौर पर यह {} पर सेट होता हैएक डिक्शनरी, जो इस टैग क्लास के सभी एट्रिब्यूट के बारे में जानकारी देती है. यह एट्रिब्यूट के नाम से एट्रिब्यूट ऑब्जेक्ट में मैप करता है (attr मॉड्यूल देखें). |
doc
|
string; या None ;
डिफ़ॉल्ट रूप से None पर सेट होता हैटैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. |
किसे दिखे
None
visibility(value)
यह नीति, फ़िलहाल शुरू किए जा रहे .bzl मॉड्यूल के लोड दिखने की सेटिंग को सेट करती है.
किसी मॉड्यूल की लोड विज़िबिलिटी यह तय करती है कि अन्य BUILD और .bzl फ़ाइलें लोड हो सकती हैं या नहीं. यह मौजूदा .bzl सोर्स फ़ाइल के टारगेट विज़िबिलिटी से अलग है. इससे यह तय होता है कि फ़ाइल, अन्य टारगेट के डिपेंडेंसी के तौर पर दिख सकती है या नहीं. लोड दिखने की सेटिंग, पैकेज के लेवल पर काम करती है: मॉड्यूल लोड करने के लिए, फ़ाइल को लोड करते समय किसी ऐसे पैकेज में मौजूद होना ज़रूरी है जिसे मॉड्यूल को देखने की अनुमति दी गई है. मॉड्यूल को हमेशा अपने पैकेज में लोड किया जा सकता है, भले ही वह किसे दिखे.
visibility()
को हर .bzl फ़ाइल में सिर्फ़ एक बार कॉल किया जा सकता है. साथ ही, इसे सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, किसी फ़ंक्शन में नहीं. हमारा सुझाव है कि इस कॉल को load()
स्टेटमेंट के ठीक नीचे रखें. साथ ही, तर्क तय करने के लिए, कम से कम लॉजिक का इस्तेमाल करें.
अगर फ़्लैग --check_bzl_visibility
को 'गलत' पर सेट किया गया है, तो लोड दिखने से जुड़े उल्लंघन के लिए चेतावनियां भेजी जाएंगी, लेकिन बिल्ड फ़ेल नहीं होगा.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
value
|
ज़रूरी है पैकेज स्पेसिफ़िकेशन वाली स्ट्रिंग की सूची या एक पैकेज स्पेसिफ़िकेशन स्ट्रिंग. पैकेज की जानकारी,
"@" सिंटैक्स की अनुमति नहीं है; सभी स्पेसिफ़िकेशन की व्याख्या, मौजूदा मॉड्यूल के रिपॉज़िटरी के हिसाब से की जाती है. अगर ध्यान दें कि |