सामान्य परिभाषाएं

किसी समस्या की शिकायत करें सोर्स देखें

इस सेक्शन में ऐसे शब्दों और सिद्धांतों के बारे में बताया गया है जो कई तरह के फ़ंक्शन के लिए आम हैं या नियम बनाते हैं.

विषय सूची

बर्न शेल टोकनाइज़ेशन

कुछ नियमों की कुछ स्ट्रिंग एट्रिब्यूट, बॉर्न शेल के टोकनाइज़ेशन नियमों के मुताबिक एक से ज़्यादा शब्दों में बंटे होते हैं: बिना कोट वाले स्पेस में अलग-अलग शब्दों का इस्तेमाल किया जाता है. साथ ही, सिंगल और डबल कोट वाले वर्ण और बैकस्लैश का इस्तेमाल, टोकनाइज़ेशन को रोकने के लिए किया जाता है.

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

"बनाएं" वैरिएबल एक्सपैंशन और बॉर्न शेल टोकनाइज़ेशन वाले एट्रिब्यूट का इस्तेमाल, आम तौर पर कंपाइलर और अन्य टूल के लिए आर्बिट्रेरी विकल्प पास करने के लिए किया जाता है. cc_library.copts और java_library.javacopts, ऐसे एट्रिब्यूट के उदाहरण हैं. इन बदलावों को एक साथ जोड़कर सिंगल स्ट्रिंग वैरिएबल को विकल्प शब्दों की कॉन्फ़िगरेशन के हिसाब से बनी सूची में बड़ा किया जा सकता है.

लेबल एक्सपैंशन

बहुत कम नियमों के कुछ स्ट्रिंग एट्रिब्यूट, लेबल एक्सपैंशन के तहत आते हैं: अगर उन स्ट्रिंग में सबस्ट्रिंग के तौर पर कोई मान्य लेबल शामिल है, जैसे कि //mypkg:target, और वह लेबल मौजूदा नियम की ज़रूरी शर्त है, तो वह टारगेट //mypkg:target से दिखाई गई फ़ाइल के पाथनाम में बड़ा कर दिया जाता है.

एट्रिब्यूट के उदाहरण में genrule.cmd और cc_binary.linkopts शामिल हैं. हर मामले में जानकारी में बहुत ज़्यादा अंतर हो सकता है. जैसे: मिलते-जुलते लेबल बड़े किए गए हैं या नहीं, एक से ज़्यादा फ़ाइलों में बड़े होने वाले लेबल के साथ क्या किया जाता है वगैरह. किसी खास जानकारी के लिए, नियम से जुड़े एट्रिब्यूट का दस्तावेज़ देखें.

बिल्ड के ज़्यादातर नियमों की ओर से तय की गई सामान्य विशेषताएं

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

एट्रिब्यूट ब्यौरा
data

लेबल की सूची; [] डिफ़ॉल्ट है

रनटाइम के दौरान, इस नियम के मुताबिक ज़रूरी फ़ाइलें. फ़ाइल या नियम से जुड़े टारगेट को लिस्ट कर सकता है. आम तौर पर, सभी टारगेट को अनुमति देता है.

data एट्रिब्यूट में मौजूद टारगेट के डिफ़ॉल्ट आउटपुट और रनफ़ाइल, किसी भी एक्ज़ीक्यूटेबल के *.runfiles एरिया में दिखना चाहिए. यह एक्ज़ीक्यूटेबल है, जो इस टारगेट पर रनटाइम डिपेंडेंसी होता है या होता है. इसमें इस टारगेट के srcs के एक्ज़ीक्यूट होने पर इस्तेमाल की गई डेटा फ़ाइलें या बाइनरी शामिल हो सकती हैं. डेटा फ़ाइलों पर निर्भरता और उनका इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, डेटा डिपेंडेंसी सेक्शन देखें.

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

deps

लेबल की सूची; [] डिफ़ॉल्ट है

इस टारगेट के लिए डिपेंडेंसी. आम तौर पर, सिर्फ़ नियम से जुड़े टारगेट की सूची बनानी चाहिए. (हालांकि, कुछ नियमों की मदद से फ़ाइलों को सीधे deps में शामिल किया जा सकता है. हालांकि, जहां तक हो सके, इससे बचना चाहिए.)

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

deps का इस्तेमाल करके किसी टारगेट पर निर्भर होने का मतलब क्या होता है, इसका सही सिमेंटिक्स खास होता है. यह नियम अलग-अलग तरह के नियम पर निर्भर करता है. साथ ही, किसी खास नियम के दस्तावेज़ में ज़्यादा जानकारी दी जाती है. सोर्स कोड को प्रोसेस करने वाले नियमों के लिए, deps आम तौर पर srcs में मौजूद कोड की डिपेंडेंसी के बारे में बताता है.

आम तौर पर, deps डिपेंडेंसी का इस्तेमाल किया जाता है, ताकि एक मॉड्यूल उसी प्रोग्रामिंग भाषा में लिखे गए और अलग से कंपाइल किए गए दूसरे मॉड्यूल में तय किए गए सिंबल का इस्तेमाल कर सके. कई मामलों में, क्रॉस-भाषा डिपेंडेंसी की अनुमति भी होती है: उदाहरण के लिए, java_library टारगेट, cc_library टारगेट में C++ कोड पर निर्भर हो सकता है. ऐसा deps एट्रिब्यूट में बाद वाले टारगेट को शामिल करके किया जा सकता है. ज़्यादा जानकारी के लिए डिपेंडेंसी की परिभाषा देखें.

licenses

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह ["none"] होता है

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

srcs

लेबल की सूची; [] डिफ़ॉल्ट है

इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, फ़ाइलों को सीधे तौर पर सूची में रखा जाता है. हालांकि, डिफ़ॉल्ट आउटपुट को शामिल करने के लिए, नियम वाले टारगेट (जैसे कि filegroup या genrule) की सूची बनाई जा सकती है.

भाषा के हिसाब से बने नियमों के लिए अक्सर यह ज़रूरी होता है कि सूची में मौजूद फ़ाइलों में खास फ़ाइल एक्सटेंशन हों.

बिल्ड के सभी नियमों में मौजूद विशेषताएं

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

एट्रिब्यूट ब्यौरा
compatible_with

लेबल की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

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

यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह बता सकते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहरी तौर पर डिप्लॉय की जा सकने वाली बाइनरी को, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं करना चाहिए. ज़्यादा जानकारी के लिए, ConstraintSemantics पर जाएं.

deprecation

स्ट्रिंग; कॉन्फ़िगर करने लायक नहीं; डिफ़ॉल्ट तौर पर None है

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

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

इंट्रा-पैकेज डिपेंडेंसी को इस चेतावनी से छूट दी जाती है. इसलिए, उदाहरण के लिए, किसी ऐसे नियम के टेस्ट बनाने पर चेतावनी नहीं मिलती जो अब काम नहीं करता.

अगर कोई बंद किया गया टारगेट, किसी दूसरे काम न करने वाले टारगेट पर निर्भर करता है, तो चेतावनी वाला कोई मैसेज नहीं दिखाया जाता.

जब लोग इसका इस्तेमाल करना बंद कर देते हैं, तो टारगेट को हटाया जा सकता है.

distribs

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

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

exec_compatible_with

लेबल की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

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

exec_properties

स्ट्रिंग का शब्दकोश; {} डिफ़ॉल्ट है

स्ट्रिंग का ऐसा शब्दकोश जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के exec_properties में जोड़ा जाएगा. प्लैटफ़ॉर्म के नियम का exec_properties देखें.

अगर कोई कुंजी प्लैटफ़ॉर्म और टारगेट-लेवल प्रॉपर्टी, दोनों में मौजूद है, तो वैल्यू को टारगेट से लिया जाएगा.

features

सुविधा स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] है

यह सुविधा स्ट्रिंग टैग है, जिसे किसी टारगेट के लिए चालू या बंद किया जा सकता है. सुविधा का मतलब, नियम के हिसाब से तय होता है.

इस features एट्रिब्यूट को पैकेज लेवल features एट्रिब्यूट के साथ जोड़ा जाता है. उदाहरण के लिए, अगर अगर सुविधाएं ["a", "b"] पैकेज लेवल पर चालू हैं और टारगेट के features एट्रिब्यूट में ["-a", "c"] है, तो नियम के लिए चालू की गई सुविधाएं "b" और "c" होंगी. उदाहरण देखें.

restricted_to

लेबल की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

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

यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, compatible_with पर जाएं.

tags

स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

टैग का इस्तेमाल किसी भी नियम के लिए किया जा सकता है. टेस्ट पर टैग और test_suite नियम, टेस्ट को कैटगरी में बांटने के लिए काम के होते हैं. नॉन-टेस्ट टारगेट पर टैग का इस्तेमाल, genrules और Starlark ऐक्शन के सैंडबॉक्स किए गए प्रोग्राम को कंट्रोल करने के लिए किया जाता है. साथ ही, इनका इस्तेमाल इंसानों और/या बाहरी टूल से पार्स करने के लिए किया जाता है.

अगर हमें किसी टेस्ट या genrule टारगेट के tags एट्रिब्यूट में, ये कीवर्ड मिलते हैं या Starlark की किसी भी कार्रवाई के लिए execution_requirements की कुंजियां मिलती हैं, तो Bazel अपने सैंडबॉक्सिंग कोड के काम करने के तरीके में बदलाव करता है.

  • कार्रवाई या टेस्ट में no-sandbox कीवर्ड के नतीजे कभी भी सैंडबॉक्स नहीं किए जाते. इसे अब भी कैश मेमोरी में सेव किया जा सकता है या दूर से चलाया जा सकता है. इनमें से किसी एक या दोनों को रोकने के लिए, no-cache या no-remote का इस्तेमाल करें.
  • कार्रवाई या टेस्ट में इस्तेमाल होने वाले no-cache कीवर्ड के नतीजे, कभी भी कैश मेमोरी में सेव नहीं किए जाते (स्थानीय या किसी दूसरे जगह से). ध्यान दें: इस टैग के लिए, डिस्क की कैश मेमोरी को लोकल कैश मेमोरी माना जाता है, जबकि एचटीटीपी और gRPC कैश मेमोरी को रिमोट कैश मेमोरी माना जाता है. स्काईफ़्रेम या स्थायी ऐक्शन कैश मेमोरी जैसी अन्य कैश मेमोरी पर इसका कोई असर नहीं पड़ेगा.
  • कार्रवाई या टेस्ट में no-remote-cache कीवर्ड के नतीजे कभी भी कैश मेमोरी में सेव नहीं किए जाते. हालांकि, इसे स्थानीय तौर पर कैश मेमोरी में सेव किया जा सकता है, और इसे कहीं से भी इस्तेमाल किया जा सकता है. ध्यान दें: इस टैग के लिए, डिस्क की कैश मेमोरी को लोकल कैश मेमोरी माना जाता है, जबकि एचटीटीपी और जीआरपीसी कैश मेमोरी को रिमोट कैश मेमोरी माना जाता है. Skyframe या परसिस्टेंट ऐक्शन कैश जैसी अन्य कैश मेमोरी पर इसका कोई असर नहीं पड़ेगा. अगर लोकल डिस्क कैश और रिमोट कैश, दोनों को एक साथ इस्तेमाल किया जाता है, तो इसे रिमोट कैश के तौर पर माना जाएगा. साथ ही, अगर --incompatible_remote_results_ignore_disk सेट नहीं है, तो इसे पूरी तरह से बंद रखा जाएगा. ऐसा होने पर, लोकल कॉम्पोनेंट का इस्तेमाल किया जाएगा.
  • कार्रवाई या टेस्ट में no-remote-exec कीवर्ड के नतीजे कभी भी रिमोट तरीके से एक्ज़ीक्यूट नहीं किए गए हैं (हालांकि, इसे किसी दूसरे डिवाइस से कैश मेमोरी में सेव किया जा सकता है).
  • no-remote कीवर्ड, किसी कार्रवाई या टेस्ट को कहीं से भी एक्ज़ीक्यूट होने या कैश मेमोरी में सेव किए जाने से रोकता है. यह no-remote-cache और no-remote-exec, दोनों का इस्तेमाल करने के बराबर है.
  • no-remote-cache-upload कीवर्ड, स्पॉन की रिमोट कैशिंग के अपलोड वाले हिस्से को बंद करता है. इससे रिमोट एक्ज़ीक्यूशन बंद नहीं होता.
  • local कीवर्ड, किसी कार्रवाई या टेस्ट को रिमोट तरीके से कैश मेमोरी में सेव करने, रिमोट तरीके से एक्ज़ीक्यूट करने या सैंडबॉक्स में चलाने से रोकता है. जेन रूल और टेस्ट के लिए, नियम को local = True एट्रिब्यूट से मार्क करने पर भी वही असर पड़ता है.
  • requires-network कीवर्ड की मदद से, सैंडबॉक्स में बाहरी नेटवर्क को ऐक्सेस किया जा सकता है. इस टैग का असर सिर्फ़ तब होता है, जब सैंडबॉक्स की सुविधा चालू हो.
  • block-network कीवर्ड, सैंडबॉक्स के अंदर से बाहरी नेटवर्क के ऐक्सेस को रोकता है. इस मामले में, सिर्फ़ localhost से संपर्क किया जा सकता है. इस टैग का असर सिर्फ़ तब होता है, जब सैंडबॉक्स चालू हो.
  • requires-fakeroot, uid और gid 0 (यानी, रूट उपयोगकर्ता) के तौर पर जांच या कार्रवाई करता है. यह सिर्फ़ Linux पर काम करता है. इस टैग को --sandbox_fake_username कमांड लाइन विकल्प के बजाय प्राथमिकता दी जाती है.

टेस्ट पर टैग का इस्तेमाल, आम तौर पर डीबग और रिलीज़ की प्रोसेस में, टेस्ट की भूमिका के बारे में बताने के लिए किया जाता है. आम तौर पर, टैग ऐसे C++ और Python टेस्ट के लिए सबसे ज़्यादा काम के होते हैं जिनमें रनटाइम के दौरान एनोटेशन बताने की कोई सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोड बेस चेक-इन नीति के आधार पर टेस्ट के सुइट असेंबल करने में आसानी होती है.

अगर बैजल को टेस्ट के नियम के tags एट्रिब्यूट में ये कीवर्ड मिलते हैं, तो वह टेस्ट रनिंग व्यवहार में बदलाव करता है:

  • exclusive सिर्फ़ "खास" मोड में टेस्ट को ज़बरदस्ती चलाएगा, ताकि यह पक्का किया जा सके कि एक ही समय पर कोई भी अन्य टेस्ट न चल रहा हो. बिल्ड से जुड़ी सभी गतिविधियों और सामान्य जांचों को पूरा करने के बाद, इस तरह के टेस्ट सीरियल तरीके से किए जाएंगे. ऐसे टेस्ट के लिए, रिमोट एक्ज़ीक्यूशन की सुविधा बंद रहती है. ऐसा इसलिए, क्योंकि बैजल के पास रिमोट मशीन पर चल रही कार्रवाई को कंट्रोल करने का विकल्प नहीं होता.
  • अगर इसे स्थानीय तौर पर एक्ज़ीक्यूट किया जाता है, तो exclusive-if-local जांच को "खास" मोड में ही चलाने के लिए मजबूर करेगा. हालांकि, अगर इसे कहीं से भी एक्ज़ीक्यूट किया जाता है, तो यह टेस्ट साथ-साथ चलाएगा.
  • manual कीवर्ड, टारगेट पैटर्न वाइल्डकार्ड (..., :*, :all वगैरह) और test_suite नियमों के विस्तार से टारगेट को बाहर रखेगा. ये नियम, build, test, और coverage के लिए, बिल्ड या रन करने के लिए टॉप-लेवल टारगेट के सेट की गणना करते समय साफ़ तौर पर टेस्ट की सूची नहीं देते. इससे, query कमांड के साथ-साथ अन्य कॉन्टेक्स्ट में, टारगेट वाइल्डकार्ड या टेस्ट सुइट एक्सपैंशन पर कोई असर नहीं पड़ता. ध्यान दें कि manual यह नहीं बताता है कि टारगेट लगातार बिल्ड/टेस्ट सिस्टम से अपने-आप नहीं बनाया/चलना चाहिए. उदाहरण के लिए, किसी टारगेट को bazel test ... से बाहर रखना ज़रूरी हो सकता है, क्योंकि इसके लिए खास Bazel फ़्लैग की ज़रूरत होती है. हालांकि, यह ठीक से कॉन्फ़िगर किए गए पहले से सबमिट किए जाने वाले या लगातार होने वाले टेस्ट में भी शामिल रहता है.
  • external कीवर्ड, टेस्ट को बिना किसी शर्त के लागू करने के लिए कहेगा (चाहे --cache_test_results वैल्यू कुछ भी हो).
टेस्ट एनसाइक्लोपीडिया में टैग कन्वेंशन देखें. इससे, आपको टेस्ट टारगेट से जुड़े टैग के बारे में और ज़्यादा नए तरीकों के बारे में जानकारी मिलेगी.
target_compatible_with

लेबल की सूची; [] डिफ़ॉल्ट है

constraint_value की सूची, जिन्हें टारगेट प्लैटफ़ॉर्म में मौजूद होना चाहिए, ताकि इस टारगेट को काम करता माना जाए. यह नियम टाइप के हिसाब से पहले से सेट की गई पाबंदियों के अलावा है. अगर टारगेट प्लैटफ़ॉर्म, सूची में दी गई सभी सीमाओं को पूरा नहीं करता है, तो टारगेट को incompatible माना जाता है. टारगेट पैटर्न बड़ा होने पर, काम न करने वाले टारगेट को बनाने और टेस्ट करने के लिए स्किप कर दिए जाते हैं (जैसे, //..., :all). कमांड लाइन पर साफ़ तौर पर बताए जाने पर, काम न करने वाले टारगेट की वजह से Bazel गड़बड़ी प्रिंट करता है. इसकी वजह से बिल्ड या टेस्ट फ़ेल हो जाता है.

ऐसे टारगेट जो पूरी तरह से काम न करने वाले टारगेट पर निर्भर करते हैं, वे अपने-आप ही काम नहीं करते हैं. उन्हें बनाने और टेस्ट करने के लिए भी छोड़ दिया जाता है.

एक खाली सूची (जो डिफ़ॉल्ट है) बताती है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है.

Workspace के नियमों के अलावा, दूसरे सभी नियम इस एट्रिब्यूट के साथ काम करते हैं. कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए, cc_toolchain के लिए target_compatible_with तय करना काम का नहीं है.

काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें.

testonly

बूलियन; कॉन्फ़िगर करने लायक; टेस्ट और टेस्ट सुइट टारगेट को छोड़कर, डिफ़ॉल्ट False है

अगर True, तो सिर्फ़ टेस्ट के लिए टारगेट किए गए टारगेट (जैसे, टेस्ट) इस टारगेट पर निर्भर कर सकते हैं.

इसी तरह, testonly न होने वाले नियम को testonly वाले किसी भी नियम पर निर्भर करने की अनुमति नहीं है.

जांच (*_test नियम) और टेस्ट सुइट (test_suite नियम) डिफ़ॉल्ट रूप से testonly होते हैं.

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

क्योंकि testonly को बिल्ड के समय लागू किया जाता है, न कि रन टाइम पर. साथ ही, डिपेंडेंसी ट्री के ज़रिए वायरल होने पर उसे लागू किया जाता है. इसलिए, उसे सोच-समझकर लागू किया जाना चाहिए. उदाहरण के लिए, यूनिट टेस्ट के लिए काम आने वाले स्टब और नकली स्टब, इंटिग्रेशन टेस्ट में भी काम आ सकते हैं. इसमें वही बाइनरी शामिल होती हैं जिन्हें प्रोडक्शन के लिए रिलीज़ किया जाएगा. इसलिए, शायद उन्हें सिर्फ़ टेस्ट के तौर पर मार्क नहीं किया जाना चाहिए. इसके ठीक उलट, जिन नियमों को लिंक करना भी खतरनाक होता है उन्हें सिर्फ़ टेस्ट के तौर पर मार्क किया जाना चाहिए.

toolchains

लेबल की सूची; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह [] होता है

टारगेट का वह सेट जिसके वैरिएबल बनाएं इस टारगेट को ऐक्सेस करने की अनुमति है. ये टारगेट या तो नियमों के इंस्टेंस हैं, जो TemplateVariableInfo या Bazel में पहले से मौजूद टूलचेन टाइप के लिए खास टारगेट की सुविधा देते हैं. इनमें शामिल हैं:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

ध्यान रखें कि यह टूलचेन रिज़ॉल्यूशन के सिद्धांत से अलग है. इस सिद्धांत का इस्तेमाल, प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए नियम लागू करके किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह पता नहीं लगाया जा सकता कि टारगेट किस cc_toolchain या java_toolchain का इस्तेमाल करेगा.

visibility

लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; अगर तय किया गया हो, तो पैकेज से default_visibility या "//visibility:private" डिफ़ॉल्ट है

टारगेट पर visibility एट्रिब्यूट की मदद से यह कंट्रोल किया जाता है कि टारगेट को दूसरे पैकेज में इस्तेमाल किया जा सकता है या नहीं. किसको दिखे, यह जानने के लिए दस्तावेज़ देखें.

जांच के सभी नियमों के लिए सामान्य एट्रिब्यूट (*_test)

इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो जांच के सभी नियमों में एक जैसे होते हैं.

एट्रिब्यूट ब्यौरा
args

स्ट्रिंग की सूची; यह $(location) और "वैरिएबल बनाएं" की जगह पर, और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. यह डिफ़ॉल्ट रूप से [] पर सेट होता है

वे कमांड लाइन आर्ग्युमेंट जिन्हें bazel test के साथ लागू करने पर, Bazel टारगेट को पास करता है.

इन आर्ग्युमेंट को bazel test कमांड लाइन पर दी गई किसी भी --test_arg वैल्यू से पहले पास किया जाता है.

env

स्ट्रिंग की डिक्शनरी; वैल्यू के तौर पर $(location) और "वैरिएबल बनाएं" की जगह लागू की जाती है. डिफ़ॉल्ट तौर पर, यह {} पर सेट होती है

bazel test से टेस्ट एक्ज़ीक्यूट होने पर, सेट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करते हैं.

यह एट्रिब्यूट सिर्फ़ cc_test, py_test, और sh_test जैसे नेटिव नियमों पर लागू होता है. यह स्टारलार्क के तय किए गए जांच के नियमों पर लागू नहीं होता. अपने खुद के Starlark नियमों के लिए, "env" एट्रिब्यूट जोड़ा जा सकता है और इसका इस्तेमाल TestEnvironment प्रोवाइडर को भरा जा सकता है.

env_inherit

स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है

bazel test से टेस्ट किए जाने पर, बाहरी एनवायरमेंट से इनहेरिट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है.

यह एट्रिब्यूट सिर्फ़ cc_test, py_test, और sh_test जैसे नेटिव नियमों पर लागू होता है. यह Starlark के तय किए गए जांच के नियमों पर लागू नहीं होता.

size

स्ट्रिंग "enormous", "large", "medium" या "small"; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट तौर पर "medium" है

इससे यह पता चलता है कि टेस्ट टारगेट का कितना "ज़्यादा" कितना "है", इसे चलाने के लिए कितना समय/संसाधन चाहिए.

यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या "बड़ा" माना जाता है. Bazel डिफ़ॉल्ट रूप से टाइम आउट तय करने के लिए, साइज़ का इस्तेमाल करता है. इसे timeout एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. यह टाइम आउट, BUILD टारगेट के सभी टेस्ट के लिए है, न कि हर अलग टेस्ट के लिए. जब स्थानीय डिवाइस पर टेस्ट किया जाता है, तो शेड्यूल करने के लिए size का भी इस्तेमाल किया जाता है: Bazel, --local_{ram,cpu}_resources का सम्मान करने की कोशिश करता है. साथ ही, एक ही समय पर कई भारी टेस्ट करता है, ताकि वह स्थानीय मशीन पर दबाव न बनाए.

टेस्ट साइज़, इन डिफ़ॉल्ट टाइम आउट और सबसे ज़्यादा स्थानीय संसाधनों के इस्तेमाल के मुताबिक होते हैं:

साइज़ रैम (एमबी में) सीपीयू (CPU) (सीपीयू कोर में) टाइम आउट होने का डिफ़ॉल्ट समय
छोटा 20 1 छोटा (1 मिनट)
medium 100 1 सामान्य (5 मिनट)
बड़ा 300 1 लंबा (15 मिनट)
विशाल 800 1 एटरनल (60 मिनट)

टेस्ट को जनरेट करते समय, एनवायरमेंट वैरिएबल TEST_SIZE को इस एट्रिब्यूट की वैल्यू पर सेट किया जाएगा.

timeout

स्ट्रिंग "short", "moderate", "long" या "eternal"; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट को टेस्ट के size एट्रिब्यूट से लिया जाता है

लौटने से पहले टेस्ट को कितने समय तक चलने की उम्मीद है.

टेस्ट का साइज़ एट्रिब्यूट, संसाधन के अनुमान को कंट्रोल करता है. हालांकि, टेस्ट का टाइम आउट अलग से सेट किया जा सकता है. अगर साफ़ तौर पर इसकी जानकारी नहीं दी जाती है, तो समयसीमा टेस्ट के साइज़ के हिसाब से तय होती है. जांच के समय को --test_timeout फ़्लैग से बदला जा सकता है. उदाहरण के लिए, कुछ ऐसी स्थितियों में चलने के लिए जिन्हें धीमा माना जाता है. जांच के टाइम आउट की वैल्यू, नीचे दी गई समयावधि के हिसाब से होनी चाहिए:

टाइम आउट का मान समयावधि
छोटा 1 मिनट
मध्यम 5 मिनट
लंबा 15 मिनट
एटरनल 60 मिनट

ऊपर दिए गए समय के अलावा, किसी अन्य समय के लिए, जांच के टाइम आउट को --test_timeout बाज़ार फ़्लैग से बदला जा सकता है. उदाहरण के लिए, उन शर्तों के तहत मैन्युअल रूप से चलाने पर जिन्हें धीमा माना जाता है. --test_timeout की वैल्यू सेकंड में होती हैं. उदाहरण के लिए, --test_timeout=120 जांच का समय दो मिनट पर सेट करेगा.

टेस्ट को शुरू करते समय, एनवायरमेंट वैरिएबल TEST_TIMEOUT को टेस्ट टाइम आउट (सेकंड में) पर सेट किया जाएगा.

flaky

बूलियन; कॉन्फ़िगर करने लायक; डिफ़ॉल्ट तौर पर False है

टेस्ट को फ़्लैकी के तौर पर मार्क करता है.

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

shard_count

50 से कम या उसके बराबर गैर-ऋणात्मक पूर्णांक; डिफ़ॉल्ट -1 है

उन पैरलल शार्ड की संख्या बताता है जिनका इस्तेमाल टेस्ट चलाने के लिए किया जाता है.

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

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

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

शार्डिंग के बारे में जानकारी के लिए, टेस्ट एनसाइक्लोपीडिया में टेस्ट शार्डिंग देखें.

local

बूलियन; कॉन्फ़िगर करने लायक; डिफ़ॉल्ट तौर पर False है

टेस्ट को हर हाल में, सैंडबॉक्सिंग के बिना स्थानीय रूप से चलाए जाने के लिए मजबूर करता है.

इसे 'सही है' पर सेट करना, टैग (tags=["local"]) के तौर पर "लोकल" को देने के बराबर है.

सभी बाइनरी नियमों (*_बाइनरी) के लिए समान विशेषताएं

इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो बाइनरी के सभी नियमों में एक जैसे होते हैं.

एट्रिब्यूट ब्यौरा
args

स्ट्रिंग की सूची; $(location) और "वैरिएबल" के बदले, और बॉर्न शेल टोकनाइज़ेशन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से [] पर सेट होता है

वे कमांड लाइन तर्क जिन्हें run कमांड या टेस्ट के तौर पर लागू करने पर, Bazel टारगेट को पास करेगा. इन आर्ग्युमेंट को bazel run या bazel test कमांड लाइन में दिए गए आर्ग्युमेंट से पहले पास किया जाता है.

ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तब आर्ग्युमेंट पास नहीं किए जाते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से रन करने पर.

env

स्ट्रिंग की डिक्शनरी. वैल्यू, $(location) और "वैरिएबल बनाएं" की जगह पर लागू होती हैं. डिफ़ॉल्ट तौर पर, यह {} पर सेट होती है

जब टारगेट को bazel run से एक्ज़ीक्यूट किया जाता है, तब अतिरिक्त एनवायरमेंट वैरिएबल सेट किए जाते हैं.

यह एट्रिब्यूट सिर्फ़ cc_binary, py_binary, और sh_binary जैसे नेटिव नियमों पर लागू होता है. यह Starlark के तय किए गए एक्ज़ीक्यूटेबल नियमों पर लागू नहीं होता.

ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तब एनवायरमेंट वैरिएबल सेट नहीं किए जाते. उदाहरण के लिए, bazel-bin/ में बाइनरी को मैन्युअल तरीके से एक्ज़ीक्यूट करके.

output_licenses

स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है

यह बाइनरी जनरेट की जाने वाली आउटपुट फ़ाइलों के लाइसेंस. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. यह Bazel अब इस्तेमाल नहीं करता. इसका इस्तेमाल न करें.

कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट

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

इस उदाहरण में, अलग-अलग टारगेट आर्किटेक्चर के लिए अलग-अलग सोर्स के बारे में बताया गया है. bazel build :multiplatform_lib --cpu x86 चलाने से, x86_impl.cc का इस्तेमाल करके टारगेट बनाया जाएगा. हालांकि, --cpu arm को बदलने पर, arm_impl.cc का इस्तेमाल होगा.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() फ़ंक्शन, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के लिए, अलग-अलग वैल्यू में से किसी एक को चुनता है. इस वैल्यू के आधार पर, टारगेट के कॉन्फ़िगरेशन के मुताबिक config_setting या constraint_value ज़रूरी शर्तें पूरी होती हैं.

Bazel, मैक्रो को प्रोसेस करने के बाद और नियमों को प्रोसेस करने से पहले, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट का आकलन करता है (तकनीकी रूप से, लोडिंग और विश्लेषण के चरणों के बीच). select() के इवैलुएशन से पहले होने वाली किसी भी प्रोसेस में, यह नहीं पता चलता है कि select() कौनसी शाखा चुनता है. उदाहरण के लिए, मैक्रो, चुनी गई ब्रांच के आधार पर अपने व्यवहार में बदलाव नहीं कर सकते. साथ ही, bazel query सिर्फ़ टारगेट की कॉन्फ़िगर की जा सकने वाली डिपेंडेंसी के बारे में सिर्फ़ पुराने अनुमान लगा सकता है. नियमों और मैक्रो के साथ select() का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले ये सवाल देखें.

दस्तावेज़ में जिन एट्रिब्यूट को nonconfigurable के तौर पर मार्क किया गया है वे इस सुविधा का इस्तेमाल नहीं कर सकतीं. आम तौर पर, एक एट्रिब्यूट को कॉन्फ़िगर नहीं किया जा सकता, क्योंकि Bazel को इसकी वैल्यू की जानकारी होना ज़रूरी है. इसके बाद ही, वह select() को ठीक करने का तरीका जान पाएगा.

ज़्यादा जानकारी के लिए, कॉन्फ़िगर करने लायक बिल्ड एट्रिब्यूट देखें.

इंप्लिसिट आउटपुट टारगेट

C++ में इंप्लिसिट आउटपुट अब काम नहीं करते. कृपया जहां भी हो सके, दूसरी भाषाओं में इसका इस्तेमाल न करें. फ़िलहाल, हमारे पास कोई एक्सक्लूज़न पाथ नहीं है. हालांकि, इसे भी बंद कर दिया जाएगा.

BUILD फ़ाइल में बिल्ड नियम तय करने का मतलब है कि पैकेज में, नाम वाले नए नियम के टारगेट के बारे में साफ़ तौर पर जानकारी दी जाती है. कई बिल्ड रूल फ़ंक्शन, एक या उससे ज़्यादा आउटपुट फ़ाइल टारगेट भी करते हैं, जिनका कॉन्टेंट और मतलब नियम के हिसाब से होते हैं. उदाहरण के लिए, जब साफ़ तौर पर java_binary(name='foo', ...) नियम का एलान किया जाता है, तब आउटपुट फ़ाइल टारगेट foo_deploy.jar को भी साफ़ तौर पर उसी पैकेज के सदस्य के तौर पर एलान किया जाता है. (यह टारगेट अपने-आप पूरा होने वाला Java संग्रह है, जो डिप्लॉयमेंट के लिए सही है.)

इंप्लिसिट आउटपुट टारगेट, ग्लोबल टारगेट ग्राफ़ के फ़र्स्ट-क्लास सदस्य हैं. दूसरे टारगेट की तरह ही, ये मांग पर बनाए जाते हैं. ऐसा तब किया जाता है, जब टॉप-लेवल के निर्देश में इनकी जानकारी दी गई हो या जब दूसरे बिल्ड टारगेट के लिए ज़रूरी शर्तें पूरी की गई हों. इन्हें BUILD फ़ाइलों में डिपेंडेंसी के तौर पर रेफ़र किया जा सकता है. साथ ही, इन्हें bazel query जैसे विश्लेषण टूल के आउटपुट में देखा जा सकता है.

हर तरह के बिल्ड नियम के लिए, नियम के दस्तावेज़ में एक खास सेक्शन शामिल होता है, जिसमें उस तरह के नियम के एलान से जुड़े किसी भी इंप्लिसिट आउटपुट के नाम और कॉन्टेंट की जानकारी दी जाती है.

बिल्ड सिस्टम के लिए इस्तेमाल किए जाने वाले दो नेमस्पेस के बीच एक अहम, लेकिन थोड़ा मामूली अंतर: लेबल से टारगेट की पहचान होती है, जो नियम या फ़ाइलें हो सकते हैं. साथ ही, फ़ाइल टारगेट को सोर्स (या इनपुट) फ़ाइल टारगेट और डेराइव्ड (या आउटपुट) फ़ाइल टारगेट में बांटा जा सकता है. यहां कुछ ऐसी चीज़ों के बारे में बताया जा सकता है जिनका ज़िक्र BUILD फ़ाइलों में किया जा सकता है, जिन्हें कमांड-लाइन से बनाया जा सकता है या bazel query का इस्तेमाल करके जांच की जा सकती है. यह टारगेट नेमस्पेस है. हर फ़ाइल टारगेट, डिस्क पर मौजूद एक असल फ़ाइल से जुड़ा होता है ("फ़ाइल सिस्टम नेमस्पेस"); हर नियम टारगेट, डिस्क पर मौजूद एक या उससे ज़्यादा असल फ़ाइलों के हिसाब से हो सकता है. डिस्क पर ऐसी फ़ाइलें हो सकती हैं जिनसे जुड़ा कोई टारगेट न हो. उदाहरण के लिए, C++ के कंपाइलेशन के दौरान बनी .o ऑब्जेक्ट फ़ाइलों का रेफ़रंस BUILD फ़ाइलों में या कमांड लाइन से नहीं किया जा सकता. इस तरह, बिल्ड टूल अपना काम करने के तरीके की कुछ जानकारी छिपा सकता है. इस बारे में ज़्यादा जानकारी, बिल्ड कॉन्सेप्ट के रेफ़रंस में दी गई है.