तारीख सेव करें: BazelCon 2023, 24 से 25 अक्टूबर तक Google म्यूनिख में होगा! ज़्यादा जानें

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

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

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

विषय सूची

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

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

इस तरह के टोकन की पहचान, इस दस्तावेज़ में उनकी परिभाषा में साफ़ तौर पर दिखाई गई है.

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

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

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

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

ज़्यादातर एट्रिब्यूट, बिल्ड के ज़्यादातर नियमों से तय होते हैं

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

एट्रिब्यूट जानकारी
data

List of labels ; optional

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

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

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

deps

List of labels ; optional

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

आम तौर पर, भाषा के हिसाब से नियमों के तहत, सूची में दी गई टारगेट ऑडियंस को, टारगेट की गई कंपनी के हिसाब से टारगेट किया जाता है.

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

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

licenses

List of strings; optional; nonconfigurable

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

srcs

List of labels ; optional

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

भाषा-विशिष्ट नियमों के लिए यह आवश्यक है कि सूचीबद्ध फ़ाइलों में विशेष फ़ाइल एक्सटेंशन हों.

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

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

एट्रिब्यूट जानकारी
compatible_with

List of labels ; optional; nonconfigurable

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

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

deprecation

String; optional; nonconfigurable

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

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

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

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

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

distribs

List of strings; optional; nonconfigurable

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

exec_compatible_with

List of labels ; optional; nonconfigurable

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

exec_properties

Dictionary of strings; optional

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

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

List of feature strings; optional

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

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

restricted_to

List of labels ; optional; nonconfigurable

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

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

tags

List of strings; optional; nonconfigurable

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

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

  • no-sandbox कीवर्ड कार्रवाई या जांच को कभी भी सैंडबॉक्स नहीं किया जाता है; इसे अब भी कैश मेमोरी में सेव किया जा सकता है या कहीं से भी चलाया जा सकता है - no-cache या no-remote का इस्तेमाल करके इनमें से किसी एक या दोनों को रोकें.
  • no-cache कीवर्ड, कार्रवाई में हैं या टेस्ट को कभी भी कैश मेमोरी में सेव नहीं किया जाता (रिमोट या स्थानीय तौर पर)
  • no-remote-cache कीवर्ड कार्रवाई का काम करते हैं या जांच को कभी भी कैश मेमोरी में सेव नहीं किया जाता (लेकिन उसे स्थानीय तौर पर कैश किया जा सकता है; इसे कहीं और से भी चलाया जा सकता है). ध्यान दें: इस टैग के लिए, डिस्क की कैश मेमोरी को लोकल कैश मेमोरी माना जाता है, जबकि एचटीटीपी और जीआरपीसी कैश को रिमोट माना जाता है. अगर लोकल डिस्क की कैश मेमोरी और कैश मेमोरी को मिलाकर इस्तेमाल किया जाता है, तो इसे एक रिमोट कैश मेमोरी के तौर पर माना जाता है और पूरी तरह से बंद कर दिया जाता है. ऐसा तब तक होता है, जब तक --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 कीवर्ड, सैंडबॉक्स में से बाहरी नेटवर्क को ऐक्सेस करने से रोकता है. इस मामले में, सिर्फ़ स्थानीय होस्ट से बातचीत करने की अनुमति है. इस टैग का असर सिर्फ़ तब दिखता है, जब सैंडबॉक्स की सुविधा चालू हो.
  • requires-fakeroot, टेस्ट या कार्रवाई को uid और gid 0 के तौर पर चलाता है (यानी रूट उपयोगकर्ता). यह सिर्फ़ Linux पर काम करता है. इस टैग को --sandbox_fake_username कमांड-लाइन के विकल्प के मुकाबले प्राथमिकता दी जाती है.

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

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

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

List of labels ; optional

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

अस्थायी तौर पर, काम न करने वाले टारगेट पर निर्भर करने वाले टारगेट को काम नहीं करता. उन्हें इमारत बनाने और जांच करने के लिए भी स्किप किया जाता है.

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

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

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

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

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

इसी तरह, testonly के अलावा, किसी दूसरे नियम की मदद से, testonly का इस्तेमाल नहीं किया जा सकता.

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

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

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

toolchains

List of labels ; optional; nonconfigurable

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

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

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

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

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

विशेषताएं, सभी टेस्ट नियमों के लिए आम हैं (*_test)

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

एट्रिब्यूट जानकारी
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

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

ये तर्क, bazel test कमांड लाइन पर बताई गई --test_arg वैल्यू से पहले पास किए जाते हैं.

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

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

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

env_inherit

List of strings; optional

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

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

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

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

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

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

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

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

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

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

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

टाइम आउट का मान समयावधि
छोटा 1 मिनट
मध्यम पांच मिनट
लंबा 15 मिनट
शाश्वत 60 मिनट

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

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

Boolean; optional; default False; nonconfigurable

टेस्ट को खराब के तौर पर मार्क करता है.

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

shard_count

Non-negative integer less than or equal to 50; optional

टेस्ट को चलाने के लिए, पैरलल शार्ड की संख्या तय करता है.

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

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

शार्डिंग में परीक्षण धावक के समर्थन के लिए परीक्षण रनर की आवश्यकता होती है. अगर ऐसा नहीं किया जाता है, तो हो सकता है कि यह हर शार्ड में हर जांच को चलाए, जो आपको नहीं चाहिए.

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

Boolean; default False; nonconfigurable

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

इसे 'सही है' पर सेट करना, एक टैग के तौर पर "स्थानीय" उपलब्ध कराने के बराबर है (tags=["local"]).

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

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

एट्रिब्यूट जानकारी
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

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

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

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

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

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

output_licenses

List of strings; optional

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