.bzl फ़ाइलें

किसी समस्या की शिकायत करें Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

सभी .bzl फ़ाइलों में उपलब्ध वैश्विक तरीके.

सदस्य

analysis_test_transition

transition analysis_test_transition(settings)

विश्लेषण-टेस्ट नियम की डिपेंडेंसी पर लागू होने के लिए, कॉन्फ़िगरेशन ट्रांज़िशन बनाता है. यह ट्रांज़िशन सिर्फ़ उन नियमों के एट्रिब्यूट पर लागू किया जा सकता है जिनमें analysis_test = True है. इस तरह के नियमों की सुविधाएं सीमित होती हैं. उदाहरण के लिए, उनके डिपेंडेंसी ट्री का साइज़ सीमित होता है. इसलिए, transition() का इस्तेमाल करके बनाए गए ट्रांज़िशन की तुलना में, इस फ़ंक्शन का इस्तेमाल करके बनाए गए ट्रांज़िशन के संभावित दायरे सीमित होते हैं.

इस फ़ंक्शन को मुख्य रूप से Analysis Test Framework की मुख्य लाइब्रेरी को आसान बनाने के लिए डिज़ाइन किया गया है. सबसे सही तरीके जानने के लिए, इसका दस्तावेज़ या इसे लागू करने का तरीका देखें.

पैरामीटर

पैरामीटर ब्यौरा
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 पैरामीटर के फ़ील्ड के तौर पर उपलब्ध होते हैं.

_ से शुरू होने वाले इनपुट एट्रिब्यूट की डिफ़ॉल्ट वैल्यू होनी चाहिए. साथ ही, इनका टाइप label या label_list होना चाहिए.

साफ़ तौर पर एट्रिब्यूट की जानकारी देने वाले एट्रिब्यूट का टाइप string होना चाहिए. साथ ही, इनमें values पाबंदी का इस्तेमाल किया जाना चाहिए. साफ़ तौर पर बताए गए एट्रिब्यूट, ऐसेपेक्ट को सिर्फ़ उन नियमों के साथ इस्तेमाल करने की पाबंदी लगाते हैं जिनमें पाबंदी के हिसाब से एक ही नाम, टाइप, और मान्य वैल्यू वाले एट्रिब्यूट हों.

एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
required_providers sequence; डिफ़ॉल्ट []
है इस एट्रिब्यूट की मदद से, ऐसेसपेक्ट को सिर्फ़ उन टारगेट तक सीमित किया जा सकता है जिनके नियमों में, ज़रूरी सेवा देने वाली कंपनियों का विज्ञापन किया जाता है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.

नेस्ट नहीं की गई सेवा देने वाली कंपनियों की सूची, अपने-आप एक सूची में बदल जाएगी. इसका मतलब है कि [FooInfo, BarInfo] की सदस्यता, [[FooInfo, BarInfo]] की सदस्यता में अपने-आप बदल जाएगी.

किसी नियम (उदाहरण के लिए, some_rule) के टारगेट को किसी पहलू के लिए दिखाने के लिए, some_rule को सेवा देने वाली कम से कम एक ज़रूरी सूची में शामिल सभी कंपनियों का विज्ञापन दिखाना होगा. उदाहरण के लिए, अगर किसी पहलू का required_providers [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] है, तो यह पहलू some_rule टारगेट तब ही देख सकता है, जब some_rule FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों उपलब्ध कराता हो.

required_aspect_providers sequence; डिफ़ॉल्ट तौर पर इसकी वैल्यू []
होती है इस एट्रिब्यूट की मदद से, इस एस्पेक्ट को दूसरे एस्पेक्ट की जांच करने की अनुमति मिलती है. वैल्यू, सेवा देने वाली कंपनियों की सूची होनी चाहिए. इसमें सेवा देने वाली कंपनियों की सूची या अलग-अलग कंपनियों की जानकारी शामिल हो सकती है, लेकिन दोनों नहीं. उदाहरण के लिए, [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] मान्य वैल्यू है, जबकि [FooInfo, BarInfo, [BazInfo, QuxInfo]] मान्य नहीं है.

नेस्ट नहीं की गई सेवा देने वाली कंपनियों की सूची, अपने-आप एक सूची में बदल जाएगी. इसका मतलब है कि [FooInfo, BarInfo] की सदस्यता, [[FooInfo, BarInfo]] की सदस्यता में अपने-आप बदल जाएगी.

किसी दूसरे पहलू (जैसे, other_aspect) को इस पहलू के लिए दिखाने के लिए, other_aspect को कम से कम एक सूची में मौजूद सभी प्रोवाइडर की जानकारी देनी होगी. [[FooInfo], [BarInfo], [BazInfo, QuxInfo]] के उदाहरण में, यह एस्पेक्ट other_aspect को सिर्फ़ तब देख सकता है, जब other_aspect में FooInfo, या BarInfo, या BazInfo और QuxInfo, दोनों मौजूद हों.

provides sequence; डिफ़ॉल्ट तौर पर []
होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए.

अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां दिए गए नहीं हैं.

सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.

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_groups में बदला जाता है. अगर यह सेट है, तो एक ही इंस्टेंस में कई एक्सीक्यूशन प्लैटफ़ॉर्म पर ऐक्शन चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्सीक्यूशन ग्रुप का दस्तावेज़ देखें.
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)

depset बनाता है. direct पैरामीटर, डिप्सेट के डायरेक्ट एलिमेंट की सूची है. वहीं, transitive पैरामीटर, उन डिप्सेट की सूची है जिनके एलिमेंट, बनाए गए डिप्सेट के इनडायरेक्ट एलिमेंट बन जाते हैं. डिप्सेट को सूची में बदलने पर, एलिमेंट किस क्रम में दिखाए जाते हैं, यह order पैरामीटर से तय होता है. ज़्यादा जानकारी के लिए, डेप्सेट की खास जानकारी देखें.

किसी डेपसेट के सभी एलिमेंट (डायरेक्ट और इनडायरेक्ट) एक ही तरह के होने चाहिए, जैसा कि एक्सप्रेशन type(x) से मिलता है.

हैश-आधारित सेट का इस्तेमाल, बार-बार होने वाली गड़बड़ियों को हटाने के लिए किया जाता है. इसलिए, किसी डिपेंडेंसी सेट के सभी एलिमेंट को हैश किया जा सकता है. हालांकि, फ़िलहाल सभी कन्स्ट्रक्टर में इस इनवैरिएंट की जांच लगातार नहीं की जाती. लगातार जांच करने की सुविधा चालू करने के लिए, --incompatible_always_check_depset_elements फ़्लैग का इस्तेमाल करें. आने वाले समय में रिलीज़ होने वाले वर्शन में, यह सुविधा डिफ़ॉल्ट रूप से चालू रहेगी. समस्या 10313 देखें.

इसके अलावा, फ़िलहाल एलिमेंट में बदलाव नहीं किया जा सकता. हालांकि, आने वाले समय में इस पाबंदी को हटा दिया जाएगा.

बनाए गए डेपसेट का क्रम, उसके transitive डेपसेट के क्रम के साथ काम करना चाहिए. "default" ऑर्डर, किसी भी अन्य ऑर्डर के साथ काम करता है. अन्य सभी ऑर्डर, सिर्फ़ अपने साथ काम करते हैं.

पैरामीटर

पैरामीटर ब्यौरा
direct sequence या None; डिफ़ॉल्ट तौर पर None
किसी डेपसेट के डायरेक्ट एलिमेंट की सूची.
order स्ट्रिंग; डिफ़ॉल्ट तौर पर "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 स्ट्रिंग का क्रम; ज़रूरी है

मैक्रो

macro macro(implementation, attrs={}, inherit_attrs=None, finalizer=False, doc=None)

यह एक सिंबल मैक्रो तय करता है. इसे BUILD फ़ाइलों या मैक्रो (लेगसी या सिंबल) में टारगेट तय करने के लिए बुलाया जा सकता है. ऐसा एक से ज़्यादा टारगेट के लिए किया जा सकता है.

macro(...) से मिली वैल्यू को .bzl फ़ाइल में मौजूद किसी ग्लोबल वैरिएबल को असाइन करना ज़रूरी है. ग्लोबल वैरिएबल का नाम, मैक्रो सिंबल का नाम होगा.

सिंबल मैक्रो इस्तेमाल करने का तरीका जानने के लिए, मैक्रो देखें.

पैरामीटर

पैरामीटर ब्यौरा
implementation function; ज़रूरी है
यह मैक्रो लागू करने वाला Starlark फ़ंक्शन है. मैक्रो के एट्रिब्यूट की वैल्यू, लागू करने वाले फ़ंक्शन को कीवर्ड आर्ग्युमेंट के तौर पर पास की जाती हैं. लागू करने वाले फ़ंक्शन में, कम से कम दो नाम वाले पैरामीटर, name और visibility होने चाहिए. अगर मैक्रो को एट्रिब्यूट इनहेरिट किए जाते हैं (यहां inherit_attrs देखें), तो उसमें **kwargs अवशेष कीवर्ड पैरामीटर होना चाहिए.

आम तौर पर, लागू करने वाले फ़ंक्शन में, ऐसे किसी भी एट्रिब्यूट के लिए नाम वाला पैरामीटर होना चाहिए जिसकी जांच, बदलाव या "मुख्य" टारगेट को पास करने के लिए मैक्रो को ज़रूरत होती है. वहीं, "बल्क" इनहेरिट किए गए एट्रिब्यूट, जिन्हें "मुख्य" टारगेट को बिना बदलाव के पास किया जाएगा उन्हें **kwargs के तौर पर पास किया जाता है.

लागू करने वाले फ़ंक्शन से कोई वैल्यू नहीं मिलनी चाहिए. इसके बजाय, लागू करने वाला फ़ंक्शन, नियम या मैक्रो सिंबल को कॉल करके टारगेट का एलान करता है.

किसी सिंबल वाले मैक्रो से तय किए गए किसी भी टारगेट या अंदरूनी सिंबल वाले मैक्रो का नाम, name (इसे "मुख्य" टारगेट कहा जाता है) के बराबर होना चाहिए या name से शुरू होना चाहिए. इसके बाद, सेपरेटर वर्ण ("_", "-" या ".") और स्ट्रिंग सफ़िक्स होना चाहिए. (नाम देने की इस स्कीम का उल्लंघन करने वाले टारगेट का एलान किया जा सकता है. हालांकि, उन्हें बनाया, कॉन्फ़िगर या उन पर निर्भर नहीं किया जा सकता.)

डिफ़ॉल्ट रूप से, किसी सिंबल मैक्रो से तय किए गए टारगेट (इसमें वह Starlark फ़ंक्शन भी शामिल है जिसे मैक्रो का लागू करने वाला फ़ंक्शन ट्रांज़िटिव तरीके से कॉल करता है) सिर्फ़ उस पैकेज में दिखते हैं जिसमें मैक्रो की जानकारी देने वाली .bzl फ़ाइल होती है. सिंबल वाले मैक्रो को कॉल करने वाले व्यक्ति के साथ-साथ बाहरी लोगों को भी टारगेट दिखाने के लिए, लागू करने वाले फ़ंक्शन को visibility को सही तरीके से सेट करना होगा. आम तौर पर, visibility = visibility को उस नियम या मैक्रो सिंबल को पास करके ऐसा किया जाता है जिसे कॉल किया जा रहा है.

नीचे दिए गए एपीआई, मैक्रो लागू करने वाले फ़ंक्शन और उस Starlark फ़ंक्शन में उपलब्ध नहीं हैं जिसे ट्रांज़िशन के तौर पर कॉल किया जाता है:

attrs dict; डिफ़ॉल्ट {}
इस मैक्रो के साथ काम करने वाले एट्रिब्यूट की डिक्शनरी, जो rule.attrs से मिलती-जुलती है. कुंजियां, एट्रिब्यूट के नाम होती हैं और वैल्यू, attr.label_list(...) (attr मॉड्यूल देखें) या None जैसे एट्रिब्यूट ऑब्जेक्ट होती हैं. None एंट्री का मतलब है कि मैक्रो में उस नाम का कोई एट्रिब्यूट नहीं है. भले ही, उसे inherit_attrs के ज़रिए इनहेरिट किया गया हो (नीचे देखें).

खास name एट्रिब्यूट को पहले से एलान किया जाता है और इसे डिक्शनरी में शामिल नहीं किया जाना चाहिए. visibility एट्रिब्यूट का नाम रिज़र्व है और इसे डिक्शनरी में शामिल नहीं किया जाना चाहिए.

जिन एट्रिब्यूट के नाम _ से शुरू होते हैं वे निजी होते हैं -- उन्हें नियम की कॉल साइट पर पास नहीं किया जा सकता. किसी लेबल पर लागू होने वाली डिफ़ॉल्ट वैल्यू तय करने के लिए, ऐसे एट्रिब्यूट को डिफ़ॉल्ट वैल्यू असाइन की जा सकती है, जैसे कि attr.label(default="//pkg:foo").

मेमोरी के इस्तेमाल को सीमित करने के लिए, एट्रिब्यूट की संख्या तय की गई है.

inherit_attrs rule; या macro; या string; या None; डिफ़ॉल्ट तौर पर None
यह कोई नियम का चिह्न, मैक्रो का चिह्न या पहले से मौजूद सामान्य एट्रिब्यूट की सूची का नाम हो सकता है (यहां देखें). मैक्रो को एट्रिब्यूट, इस सूची से इनहेरिट करने चाहिए.

अगर inherit_attrs को स्ट्रिंग "common" पर सेट किया जाता है, तो मैक्रो को सामान्य नियम एट्रिब्यूट की परिभाषाएं इनहेरिट हो जाएंगी. इनका इस्तेमाल, Starlark के सभी नियमों में किया जाता है.

ध्यान दें कि अगर rule() या macro() की रिटर्न वैल्यू को .bzl फ़ाइल में किसी ग्लोबल वैरिएबल को असाइन नहीं किया गया था, तो ऐसी वैल्यू को नियम या मैक्रो सिंबल के तौर पर रजिस्टर नहीं किया गया है. इसलिए, इसका इस्तेमाल inherit_attrs के लिए नहीं किया जा सकता.

इनहेरिटेंस की सुविधा इस तरह काम करती है:

  1. खास name और visibility एट्रिब्यूट को कभी इनहेरिट नहीं किया जाता;
  2. छिपी हुई विशेषताओं (जिनका नाम "_" से शुरू होता है) को कभी इनहेरिट नहीं किया जाता;
  3. जिन एट्रिब्यूट के नाम पहले से ही attrs डिक्शनरी में तय किए गए हैं उन्हें कभी भी इनहेरिट नहीं किया जाता. attrs में मौजूद एंट्री को प्राथमिकता दी जाती है. ध्यान दें कि किसी एंट्री को None पर सेट किया जा सकता है, ताकि यह पक्का किया जा सके कि उस नाम से कोई एट्रिब्यूट मैक्रो पर तय न हो;
  4. अन्य सभी एट्रिब्यूट, नियम या मैक्रो से इनहेरिट किए जाते हैं और इन्हें attrs डिक्शनरी में मर्ज कर दिया जाता है.

जब किसी ऐसे एट्रिब्यूट को इनहेरिट किया जाता है जो ज़रूरी नहीं है, तो एट्रिब्यूट की डिफ़ॉल्ट वैल्यू को None पर बदल दिया जाता है. भले ही, ओरिजनल नियम या मैक्रो में इसके लिए कोई वैल्यू तय की गई हो. इससे यह पक्का होता है कि जब मैक्रो, एट्रिब्यूट की वैल्यू को रैप किए गए नियम या मैक्रो के किसी इंस्टेंस पर फ़ॉरवर्ड करता है, तो बाहरी मैक्रो के कॉल में मौजूद वैल्यू, अंदरूनी नियम या मैक्रो के कॉल में भी मौजूद नहीं होगी. ऐसा इसलिए होता है, क्योंकि किसी एट्रिब्यूट में None को पास करने का मतलब, एट्रिब्यूट को छोड़ने जैसा ही होता है.**kwargs यह ज़रूरी है, क्योंकि किसी एट्रिब्यूट को छोड़ने से, उसकी डिफ़ॉल्ट वैल्यू को पास करने से अलग सेमेटिक मिलते हैं. खास तौर पर, हटाए गए एट्रिब्यूट कुछ bazel query आउटपुट फ़ॉर्मैट में नहीं दिखाए जाते. साथ ही, कैलकुलेट की गई डिफ़ॉल्ट वैल्यू सिर्फ़ तब लागू होती हैं, जब वैल्यू को हटाया गया हो. अगर मैक्रो को इनहेरिट किए गए किसी एट्रिब्यूट की जांच करनी है या उसमें बदलाव करना है, तो आपको मैक्रो के लागू करने वाले फ़ंक्शन में None केस को मैनेज करना होगा. उदाहरण के लिए, इनहेरिट किए गए tags एट्रिब्यूट में वैल्यू जोड़ना.

उदाहरण के लिए, नीचे दिया गया मैक्रो, native.cc_library से सभी एट्रिब्यूट को इनहेरिट करता है. हालांकि, इसमें cxxopts (जिसे एट्रिब्यूट की सूची से हटा दिया गया है) और copts (जिसे नई परिभाषा दी गई है) शामिल नहीं है. यह अतिरिक्त टैग जोड़ने से पहले, इनहेरिट किए गए tags एट्रिब्यूट की डिफ़ॉल्ट None वैल्यू की जांच भी करता है. 

def _my_cc_library_impl(name, visibility, tags, **kwargs):
    # Append a tag; tags attr was inherited from native.cc_library, and
    # therefore is None unless explicitly set by the caller of my_cc_library()
    my_tags = (tags or []) + ["my_custom_tag"]
    native.cc_library(
        name = name,
        visibility = visibility,
        tags = my_tags,
        **kwargs
    )

my_cc_library = macro(
    implementation = _my_cc_library_impl,
    inherit_attrs = native.cc_library,
    attrs = {
        "cxxopts": None,
        "copts": attr.string_list(default = ["-D_FOO"]),
    },
)

अगर inherit_attrs सेट है, तो मैक्रो के लागू करने वाले फ़ंक्शन में ज़रूर एक **kwargs अवशेष कीवर्ड पैरामीटर होना चाहिए.

आम तौर पर, मैक्रो को इनहेरिट किए गए और बदले नहीं गए एट्रिब्यूट को "मुख्य" नियम या मैक्रो सिंबल में पास करना चाहिए. आम तौर पर, इनहेरिट किए गए ज़्यादातर एट्रिब्यूट के लिए, लागू करने वाले फ़ंक्शन की पैरामीटर सूची में कोई पैरामीटर नहीं होगा. साथ ही, उन्हें **kwargs के ज़रिए पास किया जाएगा. अगर मैक्रो को "मुख्य" और "मुख्य" से बाहर के दोनों टारगेट को एट्रिब्यूट पास करने की ज़रूरत है, तो इनहेरिट किए गए कुछ एट्रिब्यूट (ज़्यादातर, tags और testonly) के लिए, लागू करने वाले फ़ंक्शन में साफ़ तौर पर पैरामीटर होना सुविधाजनक हो सकता है. हालांकि, अगर मैक्रो को उन एट्रिब्यूट की जांच करनी है या उनमें बदलाव करना है, तो आपको ज़रूरी नहीं है कि इनहेरिट किए गए एट्रिब्यूट की None डिफ़ॉल्ट वैल्यू को मैनेज किया जाए.

finalizer bool; डिफ़ॉल्ट तौर पर False
यह मैक्रो, नियम फ़ाइनलाइज़र है या नहीं. यह एक ऐसा मैक्रो है जिसका आकलन, पैकेज लोड होने के आखिर में किया जाता है. भले ही, यह BUILD फ़ाइल में कहीं भी हो. यह आकलन, फ़ाइनलाइज़र के दायरे में न आने वाले सभी टारगेट तय होने के बाद किया जाता है.

सामान्य सिंबॉलिक मैक्रो के उलट, नियम फ़ाइनलाइज़र, मौजूदा पैकेज में तय किए गए नॉन-फ़ाइनलाइज़र नियम टारगेट के सेट की क्वेरी करने के लिए, native.existing_rule() और native.existing_rules() को कॉल कर सकते हैं. ध्यान दें कि native.existing_rule() और native.existing_rules(), इस नियम फ़ाइनलाइज़र के साथ-साथ किसी भी नियम फ़ाइनलाइज़र से तय किए गए टारगेट को ऐक्सेस नहीं कर सकते.

doc स्ट्रिंग या None; डिफ़ॉल्ट None
मैक्रो की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.

module_extension

unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)

नया मॉड्यूल एक्सटेंशन बनाता है. इसे ग्लोबल वैल्यू में सेव करें, ताकि इसे एक्सपोर्ट किया जा सके और use_extension के साथ MODULE.bazel फ़ाइल में इस्तेमाल किया जा सके.

पैरामीटर

पैरामीटर ब्यौरा
implementation callable; required
यह वह फ़ंक्शन है जो इस मॉड्यूल एक्सटेंशन को लागू करता है. इसमें एक पैरामीटर, module_ctx होना चाहिए. उपलब्ध रिपॉज़िटरी का सेट तय करने के लिए, फ़ंक्शन को बिल्ड की शुरुआत में एक बार कॉल किया जाता है.
tag_classes dict; डिफ़ॉल्ट रूप से {}
होता है यह एक्सटेंशन में इस्तेमाल की जाने वाली सभी टैग क्लास की जानकारी देने वाली डिक्शनरी है. यह टैग क्लास के नाम से tag_class ऑब्जेक्ट पर मैप करता है.
doc स्ट्रिंग या 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 स्ट्रिंग; या डिकशनरी या None का क्रम; डिफ़ॉल्ट तौर पर None
होता है अगर यह तय किया जाता है, तो अनुमति वाले फ़ील्ड के सेट पर पाबंदी लगा दी जाती है.
इन वैल्यू का इस्तेमाल किया जा सकता है:
  • फ़ील्ड की सूची:
    provider(fields = ['a', 'b'])

  • डिक्शनरी फ़ील्ड का नाम -> दस्तावेज़:
    provider(
       fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })
सभी फ़ील्ड में जानकारी देना ज़रूरी नहीं है.
init callable; या None; डिफ़ॉल्ट तौर पर None
प्रोवाइडर के फ़ील्ड की वैल्यू को पहले से प्रोसेस करने और इंस्टैंशिएशन के दौरान उनकी पुष्टि करने के लिए, एक वैकल्पिक कॉलबैक. अगर init दिया गया है, तो provider() दो एलिमेंट का ट्यूपल दिखाता है: सामान्य प्रोवाइडर सिंबल और रॉ कन्स्ट्रक्टर.

इसके बारे में पूरी जानकारी यहां दी गई है. इसके बारे में बेहतर तरीके से जानने और इस्तेमाल के उदाहरणों के लिए, नियम (प्रोवाइडर के कस्टम तरीके से शुरू होने की प्रोसेस) देखें.

मान लें कि P, provider() को कॉल करके बनाया गया, सेवा देने वाली कंपनी का सिंबल है. कॉन्सेप्ट के हिसाब से, P का एक इंस्टेंस जनरेट करने के लिए, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c(*args, **kwargs) को कॉल किया जाता है. यह फ़ंक्शन ये काम करता है:

  • अगर args में कोई वैल्यू मौजूद है, तो गड़बड़ी का मैसेज दिखता है.
  • अगर provider() को कॉल करते समय fields पैरामीटर तय किया गया था और kwargs में कोई ऐसी कुंजी है जो fields में मौजूद नहीं थी, तो गड़बड़ी होती है.
  • ऐसा न होने पर, c एक नया इंस्टेंस दिखाता है. इसमें kwargs में मौजूद हर k: v एंट्री के लिए, k नाम का एक फ़ील्ड होता है, जिसकी वैल्यू v होती है.
अगर init कॉलबैक नहीं दिया गया है, तो सिंबल P को कॉल करने पर, डिफ़ॉल्ट कंस्ट्रक्टर फ़ंक्शन c को कॉल किया जाता है. दूसरे शब्दों में, P(*args, **kwargs) c(*args, **kwargs) दिखाता है. उदाहरण के लिए,
MyInfo = provider()
m = MyInfo(foo = 1)
, m को m.foo == 1 के साथ MyInfo इंस्टेंस बना देगा.

हालांकि, अगर init तय किया गया है, तो कॉल P(*args, **kwargs) इन चरणों को पूरा करेगा:

  1. कॉलबैक को init(*args, **kwargs) के तौर पर शुरू किया जाता है. इसका मतलब है कि P में पास किए गए पोज़िशनल और कीवर्ड आर्ग्युमेंट के साथ ही कॉलबैक शुरू किया जाता है.
  2. init की रिटर्न वैल्यू, एक डिक्शनरी d होनी चाहिए. इसकी कुंजियां, फ़ील्ड के नाम की स्ट्रिंग होती हैं. अगर ऐसा नहीं होता है, तो गड़बड़ी का मैसेज दिखता है.
  3. P का नया इंस्टेंस, c(**d) की तरह ही, d की एंट्री को कीवर्ड आर्ग्युमेंट के तौर पर इस्तेमाल करके, डिफ़ॉल्ट कंस्ट्रक्टर को कॉल करके जनरेट किया जाता है.

अहम जानकारी: ऊपर दिए गए चरणों से पता चलता है कि अगर *args या **kwargs, init के हस्ताक्षर से मेल नहीं खाता है या init के मुख्य हिस्से का आकलन नहीं हो पाता है (शायद fail() को कॉल करके जान-बूझकर ऐसा किया गया हो), तो गड़बड़ी होती है. इसके अलावा, अगर init की रिटर्न वैल्यू, उम्मीद के मुताबिक स्कीमा वाली डिक्शनरी नहीं है, तो भी गड़बड़ी होती है.

इस तरह, init कॉलबैक, प्रीप्रोसेसिंग और पुष्टि करने के लिए, पोज़िशनल आर्ग्युमेंट और मनमुताबिक लॉजिक की अनुमति देकर, सामान्य प्रोवाइडर कंस्ट्रक्शन को सामान्य बनाता है. इससे, अनुमति वाले fields की सूची को बायपास करने की सुविधा नहीं मिलती.

init तय करने पर, provider() की रिटर्न वैल्यू ट्यूपल (P, r) बन जाती है. यहां r, रॉ कंस्ट्रक्टर है. असल में, r का काम ठीक वैसा ही होता है जैसा ऊपर बताए गए डिफ़ॉल्ट कन्स्ट्रक्टर फ़ंक्शन c का होता है. आम तौर पर, r को ऐसे वैरिएबल से बंधा होता है जिसका नाम अंडरस्कोर से शुरू होता है, ताकि सिर्फ़ मौजूदा .bzl फ़ाइल का ही सीधे तौर पर ऐक्सेस हो:

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 एट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती.

एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
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=[])

एक नया नियम बनाता है, जिसे टारगेट बनाने के लिए, BUILD फ़ाइल या मैक्रो से कॉल किया जा सकता है.

नियमों को .bzl फ़ाइल में ग्लोबल वैरिएबल को असाइन किया जाना चाहिए. ग्लोबल वैरिएबल का नाम, नियम का नाम होता है.

जांच के नियमों का नाम _test पर खत्म होना चाहिए. हालांकि, अन्य सभी नियमों का नाम ऐसा नहीं होना चाहिए. (यह पाबंदी सिर्फ़ नियमों पर लागू होती है, उनके टारगेट पर नहीं.)

पैरामीटर

पैरामीटर ब्यौरा
implementation function; ज़रूरी है
इस नियम को लागू करने वाले Starlark फ़ंक्शन में, सिर्फ़ एक पैरामीटर होना चाहिए: ctx. फ़ंक्शन को नियम के हर इंस्टेंस के लिए, विश्लेषण के फ़ेज़ के दौरान कॉल किया जाता है. यह उपयोगकर्ता के दिए गए एट्रिब्यूट को ऐक्सेस कर सकता है. यह एक्शन बनाकर, एलान किए गए सभी आउटपुट जनरेट करेगा.
test bool; डिफ़ॉल्ट तौर पर unbound
होता है यह नियम, जांच के लिए बनाया गया है या नहीं. इसका मतलब है कि क्या यह blaze test कमांड का विषय हो सकता है. सभी टेस्ट नियमों को अपने-आप executable माना जाता है. किसी टेस्ट नियम के लिए, executable = True को साफ़ तौर पर सेट करना ज़रूरी नहीं है और ऐसा करने का सुझाव भी नहीं दिया जाता. वैल्यू डिफ़ॉल्ट रूप से False पर सेट होती है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
attrs dict; डिफ़ॉल्ट तौर पर {}
नियम के सभी एट्रिब्यूट की जानकारी देने वाली डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है (attr मॉड्यूल देखें). _ से शुरू होने वाले एट्रिब्यूट निजी होते हैं. इनका इस्तेमाल, किसी लेबल पर लागू होने वाली डिपेंडेंसी को जोड़ने के लिए किया जा सकता है. name एट्रिब्यूट अपने-आप जुड़ जाता है और इसकी वैल्यू सबमिट करने की ज़रूरत नहीं होती. visibility, deprecation, tags, testonly, और features एट्रिब्यूट अपने-आप जुड़ जाते हैं और इन्हें बदला नहीं जा सकता. ज़्यादातर नियमों के लिए, कुछ ही एट्रिब्यूट की ज़रूरत होती है. मेमोरी के इस्तेमाल को सीमित करने के लिए, एट्रिब्यूट की संख्या तय की गई है.

एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में बदल देंगे.
outputs dict; या None; या function; डिफ़ॉल्ट None
अब इस्तेमाल नहीं किया जा सकता. यह पैरामीटर अब काम नहीं करता. इसे जल्द ही हटा दिया जाएगा. कृपया इस पर भरोसा न करें. --incompatible_no_rule_outputs_param के साथ, यह बंद है. इस फ़्लैग का इस्तेमाल करके पुष्टि करें कि आपका कोड, जल्द ही हटाए जाने वाले वर्शन के साथ काम करता है.
इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इसके बजाय, OutputGroupInfo या attr.output का इस्तेमाल करने के लिए नियमों को माइग्रेट करें.

पहले से तय किए गए आउटपुट तय करने के लिए स्कीमा. output और output_list एट्रिब्यूट के उलट, उपयोगकर्ता इन फ़ाइलों के लिए लेबल तय नहीं करता. पहले से तय किए गए आउटपुट के बारे में ज़्यादा जानने के लिए, नियम वाला पेज देखें.

इस आर्ग्युमेंट की वैल्यू, कोई डिक्शनरी या कॉलबैक फ़ंक्शन होती है, जो डिक्शनरी बनाता है. कॉलबैक, कैलकुलेट किए गए डिपेंडेंसी एट्रिब्यूट की तरह ही काम करता है: फ़ंक्शन के पैरामीटर के नाम, नियम के एट्रिब्यूट से मैच किए जाते हैं. उदाहरण के लिए, अगर आपने परिभाषा def _my_func(srcs, deps): ... के साथ outputs = _my_func पास किया है, तो फ़ंक्शन के पास srcs और deps एट्रिब्यूट का ऐक्सेस होता है. डायक्शनरी को सीधे तौर पर या किसी फ़ंक्शन के ज़रिए तय करने पर, इसका मतलब इस तरह से निकाला जाता है.

डिक्शनरी में हर एंट्री से, पहले से तय किया गया आउटपुट बनता है. इसमें, की एक आइडेंटिफ़ायर होती है और वैल्यू एक स्ट्रिंग टेंप्लेट होती है. इससे आउटपुट का लेबल तय होता है. नियम लागू करने वाले फ़ंक्शन में, आइडेंटिफ़ायर फ़ील्ड का नाम बन जाता है. इसका इस्तेमाल, ctx.outputs में आउटपुट के File को ऐक्सेस करने के लिए किया जाता है. आउटपुट के लेबल में वही पैकेज होता है जो नियम में होता है. पैकेज के बाद का हिस्सा, "%{ATTR}" फ़ॉर्म के हर प्लेसहोल्डर को एट्रिब्यूट ATTR की वैल्यू से बनाई गई स्ट्रिंग से बदलकर बनाया जाता है:

  • स्ट्रिंग टाइप वाले एट्रिब्यूट की वैल्यू को हूबहू बदल दिया जाता है.
  • लेबल टाइप वाले एट्रिब्यूट, पैकेज के बाद लेबल का हिस्सा बन जाते हैं. हालांकि, इनमें फ़ाइल एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, लेबल "//pkg:a/b.c", "a/b" हो जाता है.
  • पैकेज के बाद, आउटपुट टाइप वाले एट्रिब्यूट, लेबल का हिस्सा बन जाते हैं. इनमें फ़ाइल एक्सटेंशन (ऊपर दिए गए उदाहरण के लिए, "a/b.c") भी शामिल है.
  • प्लेसहोल्डर में इस्तेमाल किए जाने वाले, सूची वाले सभी एट्रिब्यूट (उदाहरण के लिए, attr.label_list) में एक ही एलिमेंट होना चाहिए. उनका कन्वर्ज़न, उनके नॉन-लिस्ट वर्शन (attr.label) जैसा ही है.
  • ऐसा हो सकता है कि अन्य तरह के एट्रिब्यूट, प्लेसहोल्डर में न दिखें.
  • एट्रिब्यूट के अलावा, खास प्लेसहोल्डर %{dirname} और %{basename}, नियम के लेबल के उन हिस्सों में बड़े हो जाते हैं जिनमें पैकेज शामिल नहीं होता. उदाहरण के लिए, "//pkg:a/b.c" में dirname, a है और basename, b.c है.

आम तौर पर, बदले जाने वाले वैल्यू के लिए सबसे ज़्यादा इस्तेमाल किया जाने वाला प्लेसहोल्डर "%{name}" होता है. उदाहरण के लिए, "foo" नाम के टारगेट के लिए, आउटपुट डायक्शनरी {"bin": "%{name}.exe"}, foo.exe नाम के एक आउटपुट को पहले से एलान कर देता है. इसे लागू करने वाले फ़ंक्शन में ctx.outputs.bin के तौर पर ऐक्सेस किया जा सकता है.

executable bool; डिफ़ॉल्ट रूप से unbound
यह तय करता है कि इस नियम को लागू किया जा सकता है या नहीं. इसका मतलब है कि क्या यह blaze run कमांड का विषय हो सकता है. यह डिफ़ॉल्ट रूप से False पर सेट होता है. ज़्यादा जानकारी के लिए, नियमों का पेज देखें.
output_to_genfiles bool; डिफ़ॉल्ट तौर पर, इसकी वैल्यू False
होती है अगर इसकी वैल्यू 'सही' है, तो फ़ाइलें bin डायरेक्ट्री के बजाय genfiles डायरेक्ट्री में जनरेट होंगी. अगर आपको मौजूदा नियमों के साथ काम करने के लिए इसकी ज़रूरत नहीं है, तो इस फ़्लैग को सेट न करें. उदाहरण के लिए, 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; डिफ़ॉल्ट तौर पर []
होता है सेवा देने वाली उन कंपनियों की सूची जिन्हें लागू करने वाले फ़ंक्शन को दिखाना चाहिए.

अगर लागू करने वाले फ़ंक्शन में, यहां दी गई सूची में शामिल किसी भी तरह के प्रोवाइडर को रिटर्न वैल्यू से हटा दिया जाता है, तो यह गड़बड़ी होती है. हालांकि, लागू करने वाले फ़ंक्शन से ऐसे अन्य प्रोवाइडर भी मिल सकते हैं जो यहां दिए गए नहीं हैं.

सूची का हर एलिमेंट, provider() से मिला *Info ऑब्जेक्ट होता है. हालांकि, लेगसी प्रोवाइडर को उसके स्ट्रिंग नाम से दिखाया जाता है. जब नियम के किसी टारगेट का इस्तेमाल, ज़रूरी प्रोवाइडर का एलान करने वाले टारगेट के लिए डिपेंडेंसी के तौर पर किया जाता है, तो उस प्रोवाइडर को यहां बताना ज़रूरी नहीं है. यह ज़रूरी है कि लागू करने वाला फ़ंक्शन इसे दिखाए. हालांकि, इसकी जानकारी देना सबसे सही तरीका माना जाता है, भले ही ऐसा करना ज़रूरी न हो. हालांकि, ऐस्पेक्ट के required_providers फ़ील्ड में, सेवा देने वाली कंपनियों की जानकारी देना ज़रूरी है.

dependency_resolution_rule bool; डिफ़ॉल्ट तौर पर False
होता है अगर सेट किया जाता है, तो नियम, एट्रिब्यूट के ज़रिए डिपेंडेंसी हो सकता है. साथ ही, इसे मटीरियलाइज़र में उपलब्ध के तौर पर भी मार्क किया जा सकता है. इस फ़्लैग के साथ सेट किए गए नियमों के हर एट्रिब्यूट को, 'मटीरियलाइज़र में उपलब्ध' के तौर पर भी मार्क किया जाना चाहिए. ऐसा इसलिए है, ताकि मार्क किए गए नियम, मार्क नहीं किए गए नियमों पर निर्भर न हों.
exec_compatible_with स्ट्रिंग का क्रम; डिफ़ॉल्ट रूप से []
होता है लागू करने वाले प्लैटफ़ॉर्म पर पाबंदियों की सूची, जो इस तरह के नियम के सभी टारगेट पर लागू होती हैं.
analysis_test bool; डिफ़ॉल्ट रूप से False
होता है अगर यह 'सही' है, तो इस नियम को विश्लेषण टेस्ट के तौर पर माना जाता है.

ध्यान दें: विश्लेषण की जांच के नियमों को मुख्य तौर पर, Starlark की मुख्य लाइब्रेरी में दिए गए इन्फ़्रास्ट्रक्चर का इस्तेमाल करके तय किया जाता है. दिशा-निर्देश पाने के लिए, जांच करना लेख पढ़ें.

अगर किसी नियम को विश्लेषण टेस्ट नियम के तौर पर तय किया जाता है, तो उसके एट्रिब्यूट पर analysis_test_transition का इस्तेमाल करके तय किए गए कॉन्फ़िगरेशन ट्रांज़िशन का इस्तेमाल किया जा सकता है. हालांकि, ऐसा करने पर कुछ पाबंदियां लागू हो जाती हैं:

  • इस नियम के टारगेट में, ट्रांज़िशन डिपेंडेंसी की संख्या सीमित होती है.
  • इस नियम को टेस्ट नियम माना जाता है (जैसे कि test=True सेट किया गया हो). यह test की वैल्यू को बदल देता है
  • हो सकता है कि नियम लागू करने वाला फ़ंक्शन कार्रवाइयों को रजिस्टर न कर पाए. इसके बजाय, AnalysisTestResultInfo की मदद से, पास/फ़ेल का नतीजा रजिस्टर करना होगा.
build_setting BuildSetting या None; डिफ़ॉल्ट तौर पर None
अगर यह सेट है, तो यह बताता है कि यह नियम किस तरह का build setting है. config मॉड्यूल देखें. अगर यह सेट है, तो इस नियम में "build_setting_default" नाम का ज़रूरी एट्रिब्यूट अपने-आप जुड़ जाता है. इस एट्रिब्यूट का टाइप, यहां दी गई वैल्यू के हिसाब से होता है.
cfg डिफ़ॉल्ट रूप से None
अगर सेट किया जाता है, तो कॉन्फ़िगरेशन ट्रांज़िशन को इंगित करता है. विश्लेषण से पहले, नियम अपने कॉन्फ़िगरेशन पर लागू होगा.
exec_groups dict या None; डिफ़ॉल्ट तौर पर None
एक डिक्शनरी, जिसमें एक्सीक्यूशन ग्रुप का नाम (स्ट्रिंग) exec_groups में बदला जाता है. अगर यह सेट है, तो नियमों को एक ही टारगेट में कई एक्सीक्यूशन प्लैटफ़ॉर्म पर कार्रवाइयां चलाने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, एक्सीक्यूशन ग्रुप का दस्तावेज़ देखें.
initializer डिफ़ॉल्ट रूप से None
है एक्सपेरिमेंटल: Stalark फ़ंक्शन, नियम के एट्रिब्यूट को शुरू करता है.

फ़ंक्शन को नियम के हर इंस्टेंस के लिए, लोड होने के समय कॉल किया जाता है. इसे name और नियम के मुताबिक तय किए गए सार्वजनिक एट्रिब्यूट की वैल्यू के साथ कॉल किया जाता है, न कि जेनरिक एट्रिब्यूट (उदाहरण के लिए, tags) के साथ.

यह एट्रिब्यूट के नामों से, पसंदीदा वैल्यू वाली डिक्शनरी दिखाता है. जिन एट्रिब्यूट की वैल्यू नहीं दिखाई जाती उन पर कोई असर नहीं पड़ता. वैल्यू के तौर पर None दिखाने पर, एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है.

किसी एट्रिब्यूट की परिभाषा में बताई गई डिफ़ॉल्ट वैल्यू से पहले, इनिशिएलाइज़र का आकलन किया जाता है. इसलिए, अगर इनिशलाइज़र के सिग्नेचर में कोई पैरामीटर डिफ़ॉल्ट वैल्यू के साथ है, तो यह एट्रिब्यूट की परिभाषा से डिफ़ॉल्ट वैल्यू को बदल देता है. हालांकि, None दिखाने पर ऐसा नहीं होता.

इसी तरह, अगर किसी पैरामीटर के लिए डिफ़ॉल्ट वैल्यू नहीं दी गई है, तो उसे पैरामीटर के तौर पर इस्तेमाल करना ज़रूरी हो जाएगा. ऐसे मामलों में, एट्रिब्यूट की परिभाषा में डिफ़ॉल्ट/ज़रूरी सेटिंग को हटाना अच्छा होता है.

जिन एट्रिब्यूट को मैनेज नहीं किया जाता उनके लिए **kwargs का इस्तेमाल करना अच्छा होता है.

एक्सटेंड किए गए नियमों के मामले में, सभी इनिशलाइज़र को चाइल्ड से लेकर पैरंट तक के क्रम में कॉल किया जाता है. हर इनिशलाइज़र को सिर्फ़ वे सार्वजनिक एट्रिब्यूट पास किए जाते हैं जिनके बारे में उसे पता होता है.

parent डिफ़ॉल्ट रूप से None
होता है एक्सपेरिमेंटल: Stalark का वह नियम जिसे बढ़ाया गया है. सेट होने पर, सार्वजनिक एट्रिब्यूट और विज्ञापन देने वाली कंपनियों को मर्ज कर दिया जाता है. यह नियम, पैरंट से executable और test से मेल खाता है. fragments, toolchains, exec_compatible_with, और exec_groups की वैल्यू मर्ज हो जाती हैं. लेगसी या ऐसे पैरामीटर सेट नहीं किए जा सकते जो काम नहीं कर रहे हैं. पैरंट के इनकमिंग कॉन्फ़िगरेशन ट्रांज़िशन cfg को, thisrule के इनकमिंग कॉन्फ़िगरेशन के बाद लागू किया जाता है.
extendable bool; या Label; या string; या 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; required
यह सबनियम लागू करने वाला Starlark फ़ंक्शन
attrs dict; डिफ़ॉल्ट तौर पर {}
होता है यह एक डिक्शनरी है, जिसमें सबनियम के सभी (निजी) एट्रिब्यूट की जानकारी होती है.

सबनियमों में सिर्फ़ निजी एट्रिब्यूट हो सकते हैं, जो लेबल-टाइप (जैसे, लेबल या लेबल-लिस्ट) के होते हैं. इन लेबल से जुड़ी हल की गई वैल्यू, Bazel अपने-आप सबनियम के लागू करने वाले फ़ंक्शन में नाम वाले आर्ग्युमेंट के तौर पर भेज देता है. इसलिए, लागू करने वाले फ़ंक्शन को एट्रिब्यूट के नाम से मैच करने वाले नाम वाले पैरामीटर स्वीकार करने होंगे. इन वैल्यू के टाइप ये होंगे:

  • executable=True वाले लेबल एट्रिब्यूट के लिए FilesToRunProvider
  • allow_single_file=True वाले लेबल एट्रिब्यूट के लिए File
  • अन्य सभी लेबल एट्रिब्यूट के लिए Target
  • सभी लेबल-लिस्ट एट्रिब्यूट के लिए [Target]
toolchains sequence; डिफ़ॉल्ट तौर पर []
सेट होता है अगर सेट किया जाता है, तो इस सबनियम के लिए ज़रूरी टूलचेन का सेट. इस सूची में, स्ट्रिंग, लेबल या StarlarkToolchainTypeApi ऑब्जेक्ट, किसी भी कॉम्बिनेशन में शामिल हो सकते हैं. मौजूदा प्लैटफ़ॉर्म की जांच करके टूलचेन ढूंढे जाएंगे और ctx.toolchains के ज़रिए सबनियम लागू करने के लिए उपलब्ध कराए जाएंगे. ध्यान दें कि अगर यह पैरामीटर सेट है, तो डेटा का इस्तेमाल करने वाले नियमों पर एईजी चालू होने चाहिए. अगर आपने अब तक AEGs पर माइग्रेट नहीं किया है, तो https://bazel.build/extending/auto-exec-groups#migration-aegs देखें.
fragments स्ट्रिंग का क्रम; डिफ़ॉल्ट []
है कॉन्फ़िगरेशन के उन फ़्रैगमेंट के नामों की सूची जिनकी टारगेट कॉन्फ़िगरेशन में सबनियम को ज़रूरत होती है.
subrules सबनियम का क्रम; डिफ़ॉल्ट []
है इस सबनियम के लिए ज़रूरी अन्य सबनियमों की सूची.

tag_class

tag_class tag_class(attrs={}, *, doc=None)

यह एक नया tag_class ऑब्जेक्ट बनाता है, जो टैग की क्लास के लिए एट्रिब्यूट स्कीमा तय करता है. ये ऐसे डेटा ऑब्जेक्ट होते हैं जिनका इस्तेमाल मॉड्यूल एक्सटेंशन कर सकता है.

पैरामीटर

पैरामीटर ब्यौरा
attrs dict; डिफ़ॉल्ट तौर पर {}
होता है इस टैग क्लास के सभी एट्रिब्यूट की जानकारी देने के लिए डिक्शनरी. यह एट्रिब्यूट के नाम को एट्रिब्यूट ऑब्जेक्ट से मैप करता है. attr मॉड्यूल देखें.

ध्यान दें कि rule(), aspect(), और repository_rule() के उलट, एट्रिब्यूट की वैल्यू के तौर पर एलान किए गए एट्रिब्यूट, None को डिफ़ॉल्ट वैल्यू में नहीं बदलेंगे. डिफ़ॉल्ट वैल्यू का इस्तेमाल करने के लिए, कॉल करने वाले को एट्रिब्यूट की वैल्यू सबमिट नहीं करनी होगी.
doc स्ट्रिंग या None; डिफ़ॉल्ट तौर पर None
टैग क्लास की जानकारी, जिसे दस्तावेज़ जनरेट करने वाले टूल से निकाला जा सकता है.

कैसा दिखाई दे

None visibility(value)

फ़िलहाल शुरू किए जा रहे .bzl मॉड्यूल की लोड विज़िबिलिटी सेट करता है.

मॉड्यूल के लोड होने की सेटिंग से यह तय होता है कि अन्य BUILD और .bzl फ़ाइलें उसे लोड कर सकती हैं या नहीं. (यह, .bzl सोर्स फ़ाइल के टारगेट के दिखने से अलग है. इससे यह तय होता है कि फ़ाइल, दूसरे टारगेट की डिपेंडेंसी के तौर पर दिख सकती है या नहीं.) लोड दिखने की सुविधा, पैकेज के लेवल पर काम करती है: किसी मॉड्यूल को लोड करने के लिए, लोड करने वाली फ़ाइल को उस पैकेज में होना चाहिए जिसे मॉड्यूल को दिखने की अनुमति दी गई है. किसी मॉड्यूल को उसके पैकेज में हमेशा लोड किया जा सकता है. भले ही, वह दिख रहा हो या नहीं.

visibility() को हर .bzl फ़ाइल में सिर्फ़ एक बार और सिर्फ़ टॉप लेवल पर कॉल किया जा सकता है, न कि किसी फ़ंक्शन में. इस कॉल को load() स्टेटमेंट और आर्ग्युमेंट तय करने के लिए ज़रूरी छोटे लॉजिक के ठीक नीचे रखना सबसे सही है.

अगर फ़्लैग --check_bzl_visibility को 'गलत है' पर सेट किया जाता है, तो लोड दिखने से जुड़े उल्लंघनों की चेतावनियां मिलेंगी. हालांकि, इससे बिल्ड पूरा नहीं होगा.

पैरामीटर

पैरामीटर ब्यौरा
value ज़रूरी है
पैकेज की जानकारी वाली स्ट्रिंग की सूची या पैकेज की जानकारी वाली एक स्ट्रिंग.

पैकेज की खास बातों के लिए, package_group के जैसे ही फ़ॉर्मैट का इस्तेमाल किया जाता है. हालांकि, पैकेज की नेगेटिव खास बातों की अनुमति नहीं है. इसका मतलब है कि स्पेसिफ़िकेशन में ये फ़ॉर्म हो सकते हैं:

  • "//foo": पैकेज //foo
  • "//foo/...": पैकेज //foo और उसके सभी सब-पैकेज.
  • "public" या "private": सभी पैकेज या कोई पैकेज नहीं

"@" सिंटैक्स का इस्तेमाल नहीं किया जा सकता. सभी खास बातों को मौजूदा मॉड्यूल के रिपॉज़िटरी के हिसाब से समझा जाता है.

अगर value, स्ट्रिंग की सूची है, तो इस मॉड्यूल को दिखाए जाने की अनुमति वाले पैकेज का सेट, हर स्पेसिफ़िकेशन से दिखाए गए पैकेज का यूनियन होता है. (खाली सूची का असर वैसा ही होता है जैसा private का होता है.) अगर value एक स्ट्रिंग है, तो उसे सिंगलटन सूची [value] माना जाता है.

ध्यान दें कि फ़्लैग --incompatible_package_group_has_public_syntax और --incompatible_fix_package_group_reporoot_syntax का इस आर्ग्युमेंट पर कोई असर नहीं पड़ता. "public" और "private" वैल्यू हमेशा उपलब्ध होती हैं. साथ ही, "//..." को हमेशा "मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज" के तौर पर समझा जाता है.