सभी .bzl फ़ाइलों में ग्लोबल तरीके उपलब्ध हैं.
सदस्य
- analysis_test_transition
- आसपेक्ट
- configuration_field
- depset
- exec_group
- exec_transition
- module_extension
- सेवा देने वाली कंपनी
- repository_rule
- नियम
- चुनें
- subrule
- tag_class
- विज़िबिलिटी
analysis_test_transition
transition analysis_test_transition(settings)
विश्लेषण-टेस्ट नियम की डिपेंडेंसी पर लागू होने वाले कॉन्फ़िगरेशन ट्रांज़िशन को बनाता है. यह ट्रांज़िशन, सिर्फ़ analysis_test = True
वाले नियमों के एट्रिब्यूट पर लागू हो सकता है. इस तरह के नियमों की सुविधाएं सीमित होती हैं. उदाहरण के लिए, उनके डिपेंडेंसी ट्री का साइज़ सीमित होता है. इसलिए, transition()
का इस्तेमाल करके बनाए गए ट्रांज़िशन की तुलना में, इस फ़ंक्शन का इस्तेमाल करके बनाए गए ट्रांज़िशन के संभावित दायरे सीमित होते हैं.
इस फ़ंक्शन को मुख्य रूप से विश्लेषण टेस्ट फ़्रेमवर्क बनाने के लिए डिज़ाइन किया गया है. सबसे सही तरीकों के बारे में जानने के लिए, इससे जुड़े दस्तावेज़ या इसे लागू करने का तरीका देखें.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
settings
|
dict;
ज़रूरी है एक डिक्शनरी जिसमें कॉन्फ़िगरेशन सेटिंग के बारे में जानकारी है, जिसे इस कॉन्फ़िगरेशन ट्रांज़िशन के ज़रिए सेट किया जाना चाहिए. बटन, बिल्ड सेटिंग के लेबल होते हैं और वैल्यू, ट्रांज़िशन के बाद की नई वैल्यू होती हैं. अन्य सभी सेटिंग में कोई बदलाव नहीं होगा. इसका इस्तेमाल उन खास कॉन्फ़िगरेशन सेटिंग को बताने के लिए करें जिन्हें विश्लेषण टेस्ट पास करने के लिए सेट करना ज़रूरी है. |
आसपेक्ट
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
|
ऐस्पेक्ट का क्रम;
डिफ़ॉल्ट रूप से [] होता है इस ऐस्पेक्ट से पहले, प्रॉपगेट किए जाने वाले ऐस्पेक्ट की सूची. |
fragments
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिन्हें टारगेट कॉन्फ़िगरेशन के लिए पहलू के लिए ज़रूरी है. |
host_fragments
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिनकी होस्ट कॉन्फ़िगरेशन में उस पहलू के लिए ज़रूरत होती है. |
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
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस पहलू के सभी इंस्टेंस पर लागू होती है. |
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
|
string;
ज़रूरी है कॉन्फ़िगरेशन फ़्रैगमेंट का नाम, जिसमें लेट-बाउंड वैल्यू शामिल है. |
name
|
string;
ज़रूरी है कॉन्फ़िगरेशन फ़्रैगमेंट से पाने के लिए वैल्यू का नाम. |
Depset
depset depset(direct=None, order="default", *, transitive=None)डिप्सेट बनाता है.
direct
पैरामीटर, डेप्सेट के डायरेक्ट एलिमेंट की सूची है. वहीं, transitive
पैरामीटर उन डिपसेट की सूची है जिनके एलिमेंट, बनाए गए डिप्सेट के इनडायरेक्ट एलिमेंट बन जाते हैं. डिप्सेट को सूची में बदलने पर, एलिमेंट किस क्रम में दिखाए जाते हैं, यह order
पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, डेपसेट से जुड़ी खास जानकारी देखें.
किसी डेपसेट के सभी एलिमेंट (डायरेक्ट और इनडायरेक्ट) एक ही तरह के होने चाहिए, जैसा कि एक्सप्रेशन type(x)
से मिलता है.
हैश-आधारित सेट का इस्तेमाल, बार-बार होने वाली गड़बड़ियों को हटाने के लिए किया जाता है. इसलिए, किसी डिपेंडेंसी सेट के सभी एलिमेंट को हैश किया जा सकता है. हालांकि, फ़िलहाल सभी कन्स्ट्रक्टर में इस इनवैरिएंट की जांच लगातार नहीं की जाती. लगातार जांच करने की सुविधा चालू करने के लिए, --incompatible_always_check_depset_elements फ़्लैग का इस्तेमाल करें. आने वाले समय में रिलीज़ होने वाले वर्शन में, यह सुविधा डिफ़ॉल्ट रूप से चालू रहेगी. समस्या 10313 देखें.
साथ ही, यह ज़रूरी है कि मौजूदा समय में एलिमेंट में बदलाव न किया जा सके. हालांकि, आने वाले समय में यह पाबंदी हट जाएगी.
बनाए गए डिप्सेट का क्रम इसके transitive
डिप्सेट के क्रम के साथ काम करने वाला होना चाहिए. "default"
ऑर्डर किसी भी दूसरे ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर सिर्फ़ अपने ऑर्डर के साथ काम करते हैं.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
direct
|
sequence; या None ;
डिफ़ॉल्ट रूप से None है डिपसेट के डायरेक्ट एलिमेंट की सूची. |
order
|
string;
डिफ़ॉल्ट रूप से "default" है नए डिपसेट के लिए ट्रैवर्सल रणनीति. संभावित वैल्यू के लिए, यहां देखें. |
transitive
|
depset का sequence या None ;
डिफ़ॉल्ट तौर पर None उन depset की सूची जिनके एलिमेंट, depset के इनडायरेक्ट एलिमेंट बन जाएंगे. |
exec_group
exec_group exec_group(toolchains=[], exec_compatible_with=[])एक एक्सीक्यूशन ग्रुप बनाता है. इसका इस्तेमाल, नियम लागू करने के दौरान किसी खास एक्सीक्यूशन प्लैटफ़ॉर्म के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
toolchains
|
sequence;
डिफ़ॉल्ट तौर पर, यह [] होता है यह टूलचेन का वह सेट है जो इस एक्सीक्यूशन ग्रुप के लिए ज़रूरी है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. |
exec_compatible_with
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट तौर पर [] होता है यह, लागू करने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है. |
exec_transition
transition exec_transition(implementation, inputs, outputs)
transition()
का एक खास वर्शन, जिसका इस्तेमाल एक्सेक्यूशन ट्रांज़िशन तय करने के लिए किया जाता है. सबसे सही तरीकों के बारे में जानने के लिए, इससे जुड़े दस्तावेज़ या इसे लागू करने का तरीका देखें. इसका इस्तेमाल सिर्फ़ Bazel के पहले से मौजूद फ़ंक्शन से किया जा सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
callable;
required |
inputs
|
स्ट्रिंग का सीक्वेंस;
ज़रूरी है |
outputs
|
स्ट्रिंग का क्रम;
ज़रूरी है |
module_extension
unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)एक नया मॉड्यूल एक्सटेंशन बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे
use_extension
के साथ MODULE.baकोई फ़ाइल में एक्सपोर्ट और इस्तेमाल किया जा सके.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
implementation
|
callable;
required यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर, module_ctx होना चाहिए. बिल्ड की शुरुआत में इस फ़ंक्शन को एक बार कॉल किया जाता है, ताकि उपलब्ध डेटा स्टोर करने की जगहों का सेट तय किया जा सके.
|
tag_classes
|
dict;
डिफ़ॉल्ट रूप से {} होता है यह एक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास का एलान करने वाली डिक्शनरी है. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट पर मैप करता है.
|
doc
|
string; या None ;
डिफ़ॉल्ट रूप से None है मॉड्यूल एक्सटेंशन की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है. |
environ
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट तौर पर [] होता है इस एनवायरमेंट वैरिएबल की सूची उपलब्ध कराता है जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में किसी एनवायरमेंट वैरिएबल में बदलाव होता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा. |
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
|
स्ट्रिंग या None ;
डिफ़ॉल्ट तौर पर None सेवा देने वाली कंपनी की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. |
fields
|
स्ट्रिंग का सीक्वेंस; या dict; या None ;
डिफ़ॉल्ट None है अगर तय किया गया है, तो अनुमति वाले फ़ील्ड के सेट को सीमित करता है. इन वैल्यू का इस्तेमाल किया जा सकता है:
|
init
|
callable; या 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
|
callable;
ज़रूरी है यह वह फ़ंक्शन है जो इस नियम को लागू करता है. एक ही पैरामीटर होना चाहिए, repository_ctx . नियम के हर इंस्टेंस के लिए, फ़ंक्शन को लोड होने के दौरान कॉल किया जाता है.
|
attrs
|
dict; या None ;
डिफ़ॉल्ट रूप से None है डेटा स्टोर करने के नियम की सभी विशेषताओं के बारे में जानकारी देने वाला डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है ( attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी फ़ाइल के लेबल पर इंप्लिसिट डिपेंडेंसी जोड़ने के लिए किया जा सकता है. डेटा स्टोर करने का नियम, जनरेट किए गए आर्टफ़ैक्ट पर निर्भर नहीं कर सकता. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसे अलग से जोड़ने की ज़रूरत नहीं होती.
एलान किए गए एट्रिब्यूट, |
local
|
bool;
डिफ़ॉल्ट False है यह बताएं कि यह नियम, स्थानीय सिस्टम से सभी चीज़ें फ़ेच करता है और हर फ़ेच के बाद, इसका फिर से आकलन किया जाना चाहिए. |
environ
|
स्ट्रिंग का क्रम;
डिफ़ॉल्ट [] है अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसके बजाय, 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 है अगर सही है, तो फ़ाइलें बिन डायरेक्ट्री के बजाय genfile की डायरेक्ट्री में जनरेट की जाएंगी. जब तक आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत न हो (जैसे, C++ के लिए हेडर फ़ाइलें बनाते समय), तब तक इस फ़्लैग को सेट न करें. |
fragments
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिन्हें टारगेट कॉन्फ़िगरेशन में नियम के लिए ज़रूरी है. |
host_fragments
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची जिनके लिए नियम को होस्ट कॉन्फ़िगरेशन में रखना ज़रूरी है. |
_skylark_testable
|
bool;
डिफ़ॉल्ट रूप से False है (प्रयोग के तौर पर उपलब्ध) अगर यह नियम सही है, तो इस नियम के तहत, Actions की सेवा देने वाली कंपनी के नियमों के हिसाब से, जांच के लिए कार्रवाइयां की जाएंगी. ctx.created_actions() को कॉल करके, नियम के लिए भी प्रोवाइडर उपलब्ध है.इसका इस्तेमाल सिर्फ़ Starlark नियमों के विश्लेषण के समय के व्यवहार की जांच करने के लिए किया जाना चाहिए. आने वाले समय में, इस फ़्लैग को हटाया जा सकता है. |
toolchains
|
sequence;
डिफ़ॉल्ट तौर पर [] सेट होता है अगर सेट किया जाता है, तो इस नियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराए जाएंगे.
|
incompatible_use_toolchain_transition
|
bool;
डिफ़ॉल्ट रूप से False है अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए. अब यह काम नहीं कर रहा है. |
doc
|
string या None ;
डिफ़ॉल्ट तौर पर None नियम की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. |
provides
|
sequence;
डिफ़ॉल्ट रूप से [] है उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को लौटाना ज़रूरी है. अगर लागू करने वाला फ़ंक्शन, यहां दी गई सूची में शामिल किसी भी तरह की सेवा देने वाली कंपनी को उसकी रिटर्न वैल्यू से हटा देता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने का फ़ंक्शन ऐसी अतिरिक्त कंपनियां दिखा सकता है जो यहां नहीं दी गई हैं. सूची का हर एलिमेंट, |
dependency_resolution_rule
|
bool;
डिफ़ॉल्ट तौर पर False होता है अगर सेट किया जाता है, तो नियम, एट्रिब्यूट के ज़रिए डिपेंडेंसी हो सकता है. साथ ही, इसे मटीरियलाइज़र में उपलब्ध के तौर पर भी मार्क किया जाता है. इस फ़्लैग सेट के साथ नियमों की हर विशेषता को मटेरियलाइज़र में भी उपलब्ध के रूप में मार्क किया जाना चाहिए. ऐसा इसलिए है, ताकि मार्क किए गए नियम, मार्क नहीं किए गए नियमों पर निर्भर न हों. |
exec_compatible_with
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर लागू होने वाली पाबंदियों की सूची, जो इस नियम के टाइप के सभी टारगेट पर लागू होती है. |
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 s तक चलने वाले ग्रुप के नाम (स्ट्रिंग) को बोलकर लिखवाएं. अगर यह नीति सेट की जाती है, तो इससे नियमों को किसी एक टारगेट में कई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्सीक्यूशन ग्रुप का दस्तावेज़ देखें.
|
initializer
|
डिफ़ॉल्ट रूप से None है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर किसी एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू से पहले, इनिशिएलाइज़र का आकलन किया जाता है. ऐसे में, अगर शुरू करने वाले के हस्ताक्षर में मौजूद किसी पैरामीटर में डिफ़ॉल्ट वैल्यू है, तो वह एट्रिब्यूट की परिभाषा (अगर इसी तरह, अगर किसी पैरामीटर के लिए डिफ़ॉल्ट वैल्यू नहीं दी गई है, तो उसे पैरामीटर के तौर पर इस्तेमाल करना ज़रूरी हो जाएगा. ऐसे मामलों में, किसी एट्रिब्यूट की डेफ़िनिशन में मौजूद डिफ़ॉल्ट/ज़रूरी सेटिंग को हटा देना बेहतर रहता है. जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए एक्सटेंड किए गए नियमों के मामले में, सभी इनिशलाइज़र को चाइल्ड से लेकर पैरंट तक के क्रम में कॉल किया जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है. |
parent
|
डिफ़ॉल्ट तौर पर, यह None पर सेट होता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments , toolchains , exec_compatible_with , और exec_groups की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद, पैरंट का इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg लागू होता है.
|
extendable
|
bool; या लेबल; या स्ट्रिंग; या None ;
डिफ़ॉल्ट None है प्रयोग के तौर पर: अनुमति वाली सूची का लेबल, जो बताता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. इसे True/False पर भी सेट किया जा सकता है, ताकि समयसीमा बढ़ाने की अनुमति हमेशा दी जा सके या हमेशा से रोकी जा सके. Bazel, डिफ़ॉल्ट रूप से एक्सटेंशन को हमेशा अनुमति देता है. |
subrules
|
सबरूल का क्रम;
डिफ़ॉल्ट [] है प्रयोगात्मक: इस नियम द्वारा उपयोग किए जाने वाले उप-नियमों की सूची. |
चुनें
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 के ज़रिए सबनियम लागू करने के लिए उपलब्ध कराए जाएंगे.
|
fragments
|
स्ट्रिंग का सीक्वेंस;
डिफ़ॉल्ट [] है उन कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची जिनकी टारगेट कॉन्फ़िगरेशन के लिए सब-रूल की ज़रूरत होती है. |
subrules
|
सबरूल का क्रम;
डिफ़ॉल्ट [] है इस सबनियम के लिए ज़रूरी अन्य सबनियमों की सूची. |
tag_class
tag_class tag_class(attrs={}, *, doc=None)यह एक नया tag_class ऑब्जेक्ट बनाता है, जो टैग की क्लास के लिए एट्रिब्यूट स्कीमा तय करता है. ये ऐसे डेटा ऑब्जेक्ट होते हैं जिनका इस्तेमाल मॉड्यूल एक्सटेंशन कर सकता है.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
attrs
|
dict;
डिफ़ॉल्ट रूप से {} है इस टैग क्लास के सभी एट्रिब्यूट के बारे में जानकारी देने के लिए डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है ( attr मॉड्यूल देखें). ध्यान दें कि |
doc
|
स्ट्रिंग या None ;
डिफ़ॉल्ट तौर पर None टैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है. |
कैसा दिखाई दे
None
visibility(value)
फ़िलहाल, जिस .bzl मॉड्यूल को शुरू किया जा रहा है उसकी लोड विज़िबिलिटी सेट करता है.
मॉड्यूल के लोड होने की सेटिंग से यह तय होता है कि अन्य BUILD और .bzl फ़ाइलें उसे लोड कर सकती हैं या नहीं. (यह मौजूदा .bzl सोर्स फ़ाइल के टारगेट के हिसाब से दिखने की सेटिंग से अलग है. इससे यह कंट्रोल किया जाता है कि फ़ाइल, अन्य टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड करने की सेटिंग, पैकेज के लेवल पर काम करती है: किसी मॉड्यूल को लोड करने के लिए, फ़ाइल उस पैकेज में लाइव होनी चाहिए जिसे मॉड्यूल को ऐक्सेस करने की अनुमति दी गई है. किसी मॉड्यूल को हमेशा उसके पैकेज में लोड किया जा सकता है. भले ही, वह दिख रहा हो या नहीं.
visibility()
को हर .bzl फ़ाइल में सिर्फ़ एक बार और सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, न कि किसी फ़ंक्शन में. इस कॉल को load()
स्टेटमेंट और आर्ग्युमेंट तय करने के लिए ज़रूरी छोटे लॉजिक के ठीक नीचे रखना सबसे सही है.
अगर फ़्लैग --check_bzl_visibility
को 'गलत है' पर सेट किया जाता है, तो लोड दिखने से जुड़े उल्लंघनों की चेतावनियां मिलेंगी. हालांकि, इससे बिल्ड पूरा नहीं होगा.
पैरामीटर
पैरामीटर | ब्यौरा |
---|---|
value
|
ज़रूरी है पैकेज की जानकारी देने वाली स्ट्रिंग की सूची या पैकेज की जानकारी देने वाली एक स्ट्रिंग. पैकेज की जानकारी,
"@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के रिपॉज़िटरी के हिसाब से समझा जाता है. अगर ध्यान दें कि फ़्लैग |