पैसे चुकाकर बने सदस्यों के लिए
- analysis_test_transition
- आसपेक्ट
- configuration_field
- डिप्सेट
- exec_group
- module_extension
- सेवा देने वाली कंपनी
- 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
|
string की क्रम;
डिफ़ॉल्ट [] एट्रिब्यूट के नामों की सूची है. यह पहलू इन नामों वाले टारगेट के एट्रिब्यूट में बताई गई डिपेंडेंसी के हिसाब से लागू होता है. यहां सामान्य वैल्यू में 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
|
string का क्रम;
यह डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के उन नामों की सूची है जिनकी ज़रूरत टारगेट कॉन्फ़िगरेशन के लिए होती है. |
host_fragments
|
string का क्रम;
यह डिफ़ॉल्ट रूप से [] कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची है, जो होस्ट कॉन्फ़िगरेशन के लिए पहलू के मुताबिक ज़रूरी है. |
toolchains
|
क्रम;
डिफ़ॉल्ट तौर पर [] सेट होता है. अगर यह सेट है, तो इस नियम के लिए ज़रूरी टूलचेन के सेट का इस्तेमाल किया जाता है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, इसे ctx.toolchain के ज़रिए नियम लागू करने के लिए उपलब्ध कराया जाएगा.
|
incompatible_use_toolchain_transition
|
यह डिफ़ॉल्ट रूप से False पर सेट हैयह काम नहीं करता है. अब यह इस्तेमाल में नहीं है और इसे हटा दिया जाना चाहिए. |
doc
|
string; या None ;
डिफ़ॉल्ट तौर पर यह None होती हैउस पहलू के बारे में जानकारी जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से हासिल किया जा सकता है. |
apply_to_generating_rules
|
यह डिफ़ॉल्ट तौर पर False पर सेट होती हैअगर सही है, तो आसपेक्ट रेशियो को आउटपुट फ़ाइल पर लागू करने के बजाय, आउटपुट फ़ाइल के जनरेट करने के नियम पर लागू होगा. उदाहरण के लिए, मान लें कि कोई पहलू `deps` विशेषता के माध्यम से ट्रांज़िटिव रूप से फैलता है और इसे `अल्फ़ा` को लक्षित करने पर लागू किया जाता है. मान लीजिए `अल्फ़ा` में `deps = [':beta_OUT']`, जहां `beta_Output` एक लक्ष्य `बीटा` का घोषित आउटपुट है. मान लीजिए कि `बीटा` में लक्ष्य `charly` के रूप में एक `type_to_generrating` है. फिर इस पक्ष को अल्फ़ा के तरीके को लागू करेगा, और `alpha_generting` के लिए यदि यह `सही है`. डिफ़ॉल्ट रूप से 'गलत'. |
exec_compatible_with
|
string की क्रम;
डिफ़ॉल्ट रूप से [] लागू होने वाले प्लैटफ़ॉर्म पर पाबंदियों की ऐसी सूची होती है जो इस पहलू के सभी इंस्टेंस पर लागू होती है. |
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)
एक्सप्रेशन से मिला है.
हैश पर आधारित सेट का इस्तेमाल, इटरेशन के दौरान डुप्लीकेट को हटाने के लिए किया जाता है. इसलिए, डिप्सेट के सभी एलिमेंट हैश होने चाहिए. हालांकि, फ़िलहाल सभी कंस्ट्रक्टर में, इस इन्वैरिएंट की लगातार जांच नहीं की जाती. लगातार जांच करने की सुविधा चालू करने के लिए, --inसक्रिय_always_check_depset_elements फ़्लैग इस्तेमाल करें; आगे की रिलीज़ में, यह डिफ़ॉल्ट तरीका होगा. समस्या 10313 देखें.
साथ ही, यह ज़रूरी है कि मौजूदा समय में एलिमेंट में बदलाव न किया जा सके. हालांकि, आने वाले समय में यह पाबंदी हट जाएगी.
बनाए गए डिप्सेट का क्रम इसके transitive
डिप्सेट के क्रम के साथ काम करने वाला होना चाहिए. "default"
ऑर्डर किसी भी दूसरे ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर सिर्फ़ अपने ऑर्डर के साथ काम करते हैं.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
direct
|
क्रम या None , डिफ़ॉल्ट रूप से यह None डिप्सेट के डायरेक्ट एलिमेंट की सूची होती है. |
order
|
यह डिफ़ॉल्ट रूप से "default" नए डिपसेट के लिए ट्रैवर्सल रणनीति है. संभावित वैल्यू के लिए यहां देखें. |
transitive
|
डिप्सेट या None का क्रम;
यह डिफ़ॉल्ट रूप से None हैडिपसेट की सूची है जिसके एलिमेंट, डिपसेट के इनडायरेक्ट एलिमेंट बन जाएंगे. |
exec_group
exec_group exec_group(toolchains=[], exec_compatible_with=[])एक एक्ज़िक्यूशन ग्रुप बनाता है. इसका इस्तेमाल नियम लागू करने के दौरान, किसी खास एक्ज़ीक्यूशन प्लैटफ़ॉर्म से जुड़ी कार्रवाइयां बनाने के लिए किया जा सकता है.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
toolchains
|
क्रम;
डिफ़ॉल्ट तौर पर [] टूलचेन का वह सेट है जिसके लिए इस एक्ज़ीक्यूशन ग्रुप की ज़रूरत होती है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. |
exec_compatible_with
|
string की क्रम;
डिफ़ॉल्ट [] हैएक्ज़ीक्यूशन प्लैटफ़ॉर्म पर कंस्ट्रेंट की सूची. |
module_extension
unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)एक नया मॉड्यूल एक्सटेंशन बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे MODULE.baकोई फ़ाइल में एक्सपोर्ट और इस्तेमाल किया जा सके.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
implementation
|
ज़रूरी है इस मॉड्यूल एक्सटेंशन को लागू करने वाला फ़ंक्शन. एक पैरामीटर होना ज़रूरी है, module_ctx . बिल्ड की शुरुआत में इस फ़ंक्शन को एक बार कॉल किया जाता है, ताकि उपलब्ध डेटा स्टोर करने की जगहों का सेट तय किया जा सके.
|
tag_classes
|
{} डिफ़ॉल्ट हैएक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास के बारे में जानकारी देने के लिए एक डिक्शनरी. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट पर मैप होता है.
|
doc
|
string या None ; डिफ़ॉल्ट तौर पर None मॉड्यूल एक्सटेंशन की जानकारी होती है. इसे दस्तावेज़ जनरेट करने वाले टूल की मदद से निकाला जा सकता है. |
environ
|
string की क्रम;
डिफ़ॉल्ट तौर पर [] एनवायरमेंट वैरिएबल की सूची होती है, जिस पर यह मॉड्यूल एक्सटेंशन निर्भर करता है. अगर उस सूची में किसी एनवायरमेंट वैरिएबल में बदलाव होता है, तो एक्सटेंशन का फिर से आकलन किया जाएगा. |
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
|
string या 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
|
string का क्रम;
डिफ़ॉल्ट तौर पर [] एनवायरमेंट वैरिएबल की सूची मिलती है, जिस पर डेटा स्टोर करने की जगह का यह नियम निर्भर करता है. अगर उस सूची में कोई एनवायरमेंट वैरिएबल बदलता है, तो रिपॉज़िटरी को फिर से लाया जाएगा. |
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 एट्रिब्यूट को किसी और तरीके से जोड़ा गया है और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, सिर्फ़ कुछ एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, नियम फ़ंक्शन attr की सीमा तय करता है.
|
outputs
|
dict; या None ; या Function;
डिफ़ॉल्ट रूप से None अब काम नहीं करता है. इस पैरामीटर के इस्तेमाल पर रोक लगा दी गई है और इसे जल्द ही हटा दिया जाएगा. कृपया इस पर निर्भर न रहें. यह ---incompatible_no_rule_outputs_param के साथ बंद है. इस फ़्लैग का इस्तेमाल करके, पुष्टि करें कि आपका कोड जल्द ही हटाए जाने के साथ काम करता है. यह पैरामीटर अब काम नहीं करता. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए, नियमों को माइग्रेट करें. पहले से तय किए गए आउटपुट के बारे में बताने के लिए स्कीमा. उपयोगकर्ता इन फ़ाइलों के लिए लेबल नहीं बताता है, जबकि इस आर्ग्युमेंट की वैल्यू, डिक्शनरी या कॉलबैक फ़ंक्शन है, जो डिक्शनरी तैयार करता है. कॉलबैक, कंप्यूट किए गए डिपेंडेंसी एट्रिब्यूट की तरह काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच करते हैं. उदाहरण के लिए, अगर शब्दकोश में मौजूद हर एंट्री, पहले से तय किया गया एक आउटपुट बनाती है, जिसमें कुंजी एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है, जो आउटपुट का लेबल तय करती है. नियम के लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर उस फ़ील्ड का नाम बन जाता है जिसका इस्तेमाल
व्यावहारिक रूप से, सबसे आम प्रतिस्थापन प्लेसहोल्डर |
executable
|
bool;
डिफ़ॉल्ट वैल्यू unbound हैक्या इस नियम को एक्ज़ीक्यूट किया जा सकता है यानी इसे एक्ज़ीक्यूट किया जा सकता है. ऐसा हो सकता है कि इस पर blaze run निर्देश लागू हो. यह डिफ़ॉल्ट रूप से False पर सेट होती है. ज़्यादा जानकारी के लिए, नियमों वाला पेज देखें.
|
output_to_genfiles
|
False डिफ़ॉल्ट हैअगर सही है, तो फ़ाइलें बिन डायरेक्ट्री के बजाय genfile की डायरेक्ट्री में जनरेट की जाएंगी. जब तक आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत न हो (जैसे, C++ के लिए हेडर फ़ाइलें जनरेट करते समय), तब तक इस फ़्लैग को सेट न करें. |
fragments
|
string की क्रम;
डिफ़ॉल्ट रूप से [] उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनकी नियम के लिए टारगेट कॉन्फ़िगरेशन में ज़रूरत होती है. |
host_fragments
|
string का क्रम;
यह डिफ़ॉल्ट रूप से [] उन कॉन्फ़िगरेशन फ़्रैगमेंट के नामों की सूची है जिनके लिए नियम को होस्ट कॉन्फ़िगरेशन में रखना ज़रूरी है. |
_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
|
string की क्रम;
डिफ़ॉल्ट रूप से [] लागू होने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची होती है, जो इस नियम के टाइप के सभी टारगेट पर लागू होती है. |
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 एक्सपेरिमेंटल: नियम के एट्रिब्यूट को शुरू करने वाला Stlark फ़ंक्शन. नियम की हर आवृत्ति के लिए फ़ंक्शन को लोड समय पर कॉल किया जाता है. इसे नियम में तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है (सामान्य एट्रिब्यूट के साथ नहीं, जैसे कि इसे एट्रिब्यूट के नाम से, पसंद की वैल्यू के लिए डिक्शनरी देनी होगी. जिन एट्रिब्यूट को दिखाया नहीं जाता उन पर कोई असर नहीं पड़ता. किसी एट्रिब्यूट की परिभाषा में दी गई डिफ़ॉल्ट वैल्यू से पहले, शुरू करने वालों का आकलन किया जाता है. ऐसे में, अगर शुरू करने वाले के हस्ताक्षर में मौजूद किसी पैरामीटर में डिफ़ॉल्ट वैल्यू है, तो वह एट्रिब्यूट की परिभाषा (अगर इसी तरह, अगर शुरू करने वाले के हस्ताक्षर में कोई पैरामीटर डिफ़ॉल्ट नहीं है, तो पैरामीटर ज़रूरी हो जाएगा. ऐसे मामलों में, किसी एट्रिब्यूट की डेफ़िनिशन में मौजूद डिफ़ॉल्ट/ज़रूरी सेटिंग को हटा देना बेहतर रहता है. जो एट्रिब्यूट मैनेज नहीं किए जाते उनके लिए लागू किए गए नियमों के मामले में, सभी शुरू करने वाले को चाइल्ड से लेकर ऐन्सेस्टर पर जाना कहा जाता है. हर शुरू करने वाला टूल सिर्फ़ उन सार्वजनिक एट्रिब्यूट को पास करता है जिनके बारे में उसे पता है. |
parent
|
डिफ़ॉल्ट तौर पर यह None हैएक्सपेरिमेंटल: स्टैलार्क नियम बढ़ाया गया है. सेट किए जाने पर सार्वजनिक एट्रिब्यूट को विज्ञापन देने वाली कंपनियों के साथ मर्ज कर दिया जाता है. यह नियम, पैरंट की ओर से दी गई executable और test से मेल खाता है. fragments , toolchains , exec_compatible_with , और exec_groups की वैल्यू मर्ज कर दी गई हैं. ऐसा हो सकता है कि लेगसी या काम न करने वाले पैरामीटर सेट न किए जाएं. इस नियम के इनकमिंग कॉन्फ़िगरेशन के बाद पैरंट कॉन्फ़िगरेशन cfg का ट्रांज़िशन लागू होगा.
|
extendable
|
bool; या Label; या string; या None ; डिफ़ॉल्ट None हैप्रयोग के लिए: अनुमति वाली सूची का लेबल, जो बताता है कि कौनसे नियम इस नियम को बढ़ा सकते हैं. एक्सटेंशन को हमेशा अनुमति देने/अनुमति न देने के लिए, इसे 'सही/गलत' पर भी सेट किया जा सकता है. Basel को डिफ़ॉल्ट रूप से, एक्सटेंशन को अनुमति देने की सुविधा मिलती है. |
subrules
|
सबरूल का सीक्वेंस;
डिफ़ॉल्ट रूप से [] एक्सपेरिमेंटल: इस नियम के लिए इस्तेमाल किए गए सबनियमों की सूची है. |
चुनें
unknown select(x, no_match_error='')
select()
एक हेल्पर फ़ंक्शन है, जो नियम एट्रिब्यूट को कॉन्फ़िगर करने लायक बनाता है. ज़्यादा जानकारी के लिए, बिल्ड एनसाइक्लोपीडिया देखें.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
x
|
ज़रूरी है ऐसा लिखवाने की सुविधा जो कॉन्फ़िगरेशन की स्थितियों को वैल्यू पर मैप करती है. हर कुंजी एक लेबल या लेबल स्ट्रिंग होती है, जो config_setting या programt_value इंस्टेंस की पहचान करती है. किसी स्ट्रिंग के बजाय लेबल का उपयोग कब करना है, इसके लिए मैक्रो से संबंधित दस्तावेज़ देखें. |
no_match_error
|
'' डिफ़ॉल्ट हैअगर कोई शर्त मेल नहीं खाती है, तो रिपोर्ट करने के लिए कस्टम गड़बड़ी ज़रूरी नहीं है. |
सबरुल
Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])सबरुल का नया इंस्टेंस बनाता है. इस फ़ंक्शन के नतीजे का इस्तेमाल करने से पहले, इसे ग्लोबल वैरिएबल में सेव किया जाना चाहिए.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
implementation
|
फ़ंक्शन;
ज़रूरी इस सबरूल को लागू करने वाला Starlark फ़ंक्शन |
attrs
|
dict;
डिफ़ॉल्ट रूप से {} सब रूल के सभी (निजी) एट्रिब्यूट का एलान करने के लिए डिक्शनरी है. उप-नियम में केवल लेबल-टाइप की गई निजी विशेषताएं (जैसे लेबल या लेबल-सूची) हो सकती हैं. इन लेबल से जुड़ी समाधान की गई वैल्यू, सबरुल के लागू करने वाले फ़ंक्शन में, नाम वाले आर्ग्युमेंट के तौर पर अपने-आप पास हो जाती हैं. इसलिए, लागू करने के फ़ंक्शन के लिए, एट्रिब्यूट के नामों से मेल खाने वाले नाम वाले पैरामीटर स्वीकार करना ज़रूरी है. ये वैल्यू इस तरह की होंगी:
|
toolchains
|
क्रम;
डिफ़ॉल्ट तौर पर [] सेट होता है. अगर इसे सेट किया जाता है, तो इस सब-नियम के लिए टूलचेन के सेट की ज़रूरत होती है. सूची में किसी भी कॉम्बिनेशन में स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट शामिल हो सकते हैं. टूलचेन की पहचान, मौजूदा प्लैटफ़ॉर्म की जांच करके की जाएगी. साथ ही, ctx.toolchains के ज़रिए सब-नियम को लागू करने के लिए दी जाएगी.
|
fragments
|
string की क्रम;
डिफ़ॉल्ट तौर पर यह [] कॉन्फ़िगरेशन फ़्रैगमेंट के नाम की सूची होती है, जिसके लिए टारगेट कॉन्फ़िगरेशन में सब-रुल की ज़रूरत होती है. |
subrules
|
सब रूल का क्रम;
डिफ़ॉल्ट रूप से [] इस सब-नियम के लिए ज़रूरी अन्य उपनियमों की सूची है. |
tag_class
tag_class tag_class(attrs={}, *, doc=None)एक नया Tag_class ऑब्जेक्ट बनाता है, जो टैग की क्लास के लिए एट्रिब्यूट स्कीमा को तय करता है. ये ऐसे डेटा ऑब्जेक्ट होते हैं जिनका इस्तेमाल मॉड्यूल एक्सटेंशन के ज़रिए किया जा सकता है.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
attrs
|
{} डिफ़ॉल्ट है, जो इस टैग क्लास के सभी एट्रिब्यूट के बारे में जानकारी देने के लिए डिक्शनरी है. यह एक एट्रिब्यूट के नाम से किसी एट्रिब्यूट ऑब्जेक्ट पर मैप होता है (attr मॉड्यूल देखें). |
doc
|
string; या None ;
डिफ़ॉल्ट रूप से यह None होता हैटैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल की मदद से लिया जा सकता है. |
किसे दिखे
None
visibility(value)
यह नीति, फ़िलहाल शुरू किए जा रहे .bzl मॉड्यूल के लोड होने की जानकारी को सेट करती है.
मॉड्यूल के लोड होने की सेटिंग से यह तय होता है कि अन्य बिल्ड और .bzl फ़ाइलों को लोड किया जा सकता है या नहीं. (यह मौजूदा .bzl सोर्स फ़ाइल के टारगेट के हिसाब से दिखने की सेटिंग से अलग है. इससे यह कंट्रोल किया जाता है कि फ़ाइल, अन्य टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड करने की सेटिंग, पैकेज के लेवल पर काम करती है: लोड हो रही फ़ाइल के लिए, किसी मॉड्यूल को लोड करने के लिए उस पैकेज में लाइव होना ज़रूरी है जिसे मॉड्यूल को दिखाने की अनुमति दी गई हो. मॉड्यूल को हमेशा उसके अपने पैकेज में लोड किया जा सकता है, भले ही वह किसको दिखे.
visibility()
को हर .bzl फ़ाइल के लिए सिर्फ़ एक बार कॉल किया जा सकता है. यह सिर्फ़ ऊपर के लेवल पर कॉल किया जा सकता है, किसी फ़ंक्शन के अंदर नहीं. हमारा सुझाव है कि इस कॉल को load()
स्टेटमेंट के ठीक नीचे रखें और तर्क तय करने के लिए कोई छोटा सा लॉजिक हो.
अगर --check_bzl_visibility
फ़्लैग को 'गलत है' पर सेट किया जाता है, तो कॉन्टेंट लोड होने के दौरान आने वाली सूचनाओं का उल्लंघन करने से चेतावनियां मिलेंगी, लेकिन बिल्ड पूरा नहीं होगा.
पैरामीटर
पैरामीटर | कंपनी का ब्यौरा |
---|---|
value
|
ज़रूरी है पैकेज स्पेसिफ़िकेशन वाली स्ट्रिंग या किसी पैकेज के लिए स्पेसिफ़िकेशन वाली स्ट्रिंग की सूची. पैकेज की जानकारी,
"@" सिंटैक्स की अनुमति नहीं है; सभी स्पेसिफ़िकेशन को, मौजूदा मॉड्यूल के डेटा स्टोर करने की जगह के हिसाब से समझा जाता है. अगर ध्यान दें कि |