BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

सूची

बोर्न शेल टोकन

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

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

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

लेबल को बड़ा करना

बहुत कम नियमों के कुछ स्ट्रिंग एट्रिब्यूट पर लेबल को बड़ा किया जा सकता है: अगर उन स्ट्रिंग में, सबस्ट्रिंग के तौर पर कोई मान्य लेबल शामिल है, जैसे कि //mypkg:target. इसके अलावा, यह लेबल एक ज़रूरी शर्त है, जिसके तहत मौजूदा नियम, फ़ाइल को पाथ के नाम में बड़ा किया जाता है, जो टारगेट //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 लक्ष्य C++ कोड पर निर्भर कर सकता है cc_library टारगेट करने के लिए, deps एट्रिब्यूट ज़्यादा जानकारी के लिए निर्भरता की परिभाषा देखें.

licenses

List of strings; optional; nonconfigurable

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

srcs

List of labels ; optional

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

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

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

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

विशेषता विवरण
compatible_with

List of labels ; optional; nonconfigurable

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

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

deprecation

String; optional; nonconfigurable

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

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

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

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

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

distribs

List of strings; optional; nonconfigurable

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

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

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

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

tags

List of strings; optional; nonconfigurable

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

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

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

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

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

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

List of labels ; optional

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

कुछ समय के लिए काम न करने वाले टारगेट पर निर्भर करने वाले टारगेट को खुद काम नहीं करने वाला माना जाता है. उन्हें बिल्डिंग और टेस्टिंग के लिए भी स्किप किया गया.

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

फ़ाइल फ़ोल्डर के नियमों के अलावा, दूसरे सभी नियम इस एट्रिब्यूट के साथ काम करते हैं. कुछ नियमों के लिए इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए, 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_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

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

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

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 एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है. जब टेस्ट स्थानीय तौर पर चलाया जाता है, तो 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 मिनट
मध्यम 5 मिनट
लंबा 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

कमांड लाइन का आर्ग्युमेंट, जो बेज़ल को टारगेट करने पर पास करेगा, चाहे वह 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 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 टारगेट के कॉन्फ़िगरेशन को पूरा करता है.

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

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

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

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

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

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

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

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

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