इस सेक्शन में ऐसे शब्दों और सिद्धांतों के बारे में बताया गया है जो कई तरह के फ़ंक्शन के लिए आम हैं या नियम बनाते हैं.
विषय सूची
- बॉर्न शेल टोकनाइज़ेशन
- लेबल एक्सपैंशन
- ज़्यादातर बिल्ड नियमों में बताए गए सामान्य एट्रिब्यूट
- बिल्ड के सभी नियमों के लिए सामान्य एट्रिब्यूट
- जांच के सभी नियमों के लिए सामान्य एट्रिब्यूट (*_test)
- सभी बाइनरी नियमों (*_binary) के लिए सामान्य एट्रिब्यूट
- कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट
- इंप्लिसिट आउटपुट टारगेट
बर्न शेल टोकनाइज़ेशन
कुछ नियमों की कुछ स्ट्रिंग एट्रिब्यूट, बॉर्न शेल के टोकनाइज़ेशन नियमों के मुताबिक एक से ज़्यादा शब्दों में बंटे होते हैं: बिना कोट वाले स्पेस में अलग-अलग शब्दों का इस्तेमाल किया जाता है. साथ ही, सिंगल और डबल कोट वाले वर्ण और बैकस्लैश का इस्तेमाल, टोकनाइज़ेशन को रोकने के लिए किया जाता है.
जिन एट्रिब्यूट पर यह टोकनाइज़ेशन लागू होता है उनके बारे में, इस दस्तावेज़ में दी गई परिभाषाओं में साफ़ तौर पर बताया गया है.
"बनाएं" वैरिएबल एक्सपैंशन और बॉर्न शेल टोकनाइज़ेशन वाले एट्रिब्यूट का इस्तेमाल, आम तौर पर कंपाइलर और अन्य टूल के लिए आर्बिट्रेरी विकल्प पास करने के लिए किया जाता है. cc_library.copts
और java_library.javacopts
, ऐसे एट्रिब्यूट के उदाहरण हैं.
इन बदलावों को एक साथ जोड़कर सिंगल स्ट्रिंग वैरिएबल को विकल्प शब्दों की कॉन्फ़िगरेशन के हिसाब से बनी सूची में बड़ा किया जा सकता है.
लेबल एक्सपैंशन
बहुत कम नियमों के कुछ स्ट्रिंग एट्रिब्यूट, लेबल
एक्सपैंशन के तहत आते हैं: अगर उन स्ट्रिंग में सबस्ट्रिंग के तौर पर
कोई मान्य लेबल शामिल है, जैसे कि //mypkg:target
, और वह लेबल मौजूदा नियम
की ज़रूरी शर्त है, तो वह
टारगेट
//mypkg:target
से दिखाई गई फ़ाइल के पाथनाम में बड़ा कर दिया जाता है.
एट्रिब्यूट के उदाहरण में genrule.cmd
और
cc_binary.linkopts
शामिल हैं. हर मामले में
जानकारी में बहुत ज़्यादा अंतर हो सकता है. जैसे: मिलते-जुलते लेबल
बड़े किए गए हैं या नहीं, एक से ज़्यादा फ़ाइलों में बड़े होने वाले लेबल
के साथ क्या किया जाता है वगैरह. किसी खास जानकारी के लिए, नियम
से जुड़े एट्रिब्यूट का दस्तावेज़ देखें.
बिल्ड के ज़्यादातर नियमों की ओर से तय की गई सामान्य विशेषताएं
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो बिल्ड के कई नियमों के ज़रिए तय किए जाते हैं, लेकिन सभी के नहीं.
एट्रिब्यूट | ब्यौरा |
---|---|
data |
लेबल की सूची; रनटाइम के दौरान, इस नियम के मुताबिक ज़रूरी फ़ाइलें. फ़ाइल या नियम से जुड़े टारगेट को लिस्ट कर सकता है. आम तौर पर, सभी टारगेट को अनुमति देता है.
अगर नए नियम ऐसे इनपुट प्रोसेस करते हैं जो रनटाइम के दौरान दूसरे इनपुट का इस्तेमाल कर सकते हैं, तो उन्हें |
deps |
लेबल की सूची;
इस टारगेट के लिए डिपेंडेंसी. आम तौर पर, सिर्फ़ नियम से जुड़े टारगेट की सूची बनानी चाहिए. (हालांकि, कुछ नियमों की मदद से फ़ाइलों को सीधे आम तौर पर, भाषा के हिसाब से बने नियमों में, सूची में शामिल टारगेट सिर्फ़ वे लोग शामिल किए जाते हैं जिनके पास सेवा देने वाली कंपनियां होती हैं.
आम तौर पर, |
licenses |
स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती;
डिफ़ॉल्ट तौर पर यह इस टारगेट के लिए इस्तेमाल की जाने वाली लाइसेंस-टाइप स्ट्रिंग की सूची. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. यह Bazel अब इस्तेमाल नहीं करता. इसका इस्तेमाल न करें. |
srcs |
लेबल की सूची;
इस नियम के तहत प्रोसेस की गई या शामिल की गई फ़ाइलें. आम तौर पर, फ़ाइलों को सीधे तौर पर सूची में रखा जाता है. हालांकि, डिफ़ॉल्ट आउटपुट को शामिल करने के लिए, नियम वाले टारगेट (जैसे कि भाषा के हिसाब से बने नियमों के लिए अक्सर यह ज़रूरी होता है कि सूची में मौजूद फ़ाइलों में खास फ़ाइल एक्सटेंशन हों. |
बिल्ड के सभी नियमों में मौजूद विशेषताएं
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जिन्हें बिल्ड के सभी नियमों में जोड़ दिया जाता है.
एट्रिब्यूट | ब्यौरा |
---|---|
compatible_with |
लेबल की सूची;
कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट के साथ-साथ उन एनवायरमेंट की सूची जिनके लिए इस टारगेट को बनाया जा सकता है. यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. इससे उपयोगकर्ता यह बता सकते हैं कि कौनसे टारगेट एक-दूसरे पर निर्भर हो सकते हैं और कौनसे नहीं. उदाहरण के लिए, बाहरी तौर पर डिप्लॉय की जा सकने वाली बाइनरी को, कंपनी के सीक्रेट कोड वाली लाइब्रेरी पर निर्भर नहीं करना चाहिए. ज़्यादा जानकारी के लिए, ConstraintSemantics पर जाएं. |
deprecation |
स्ट्रिंग; कॉन्फ़िगर करने लायक नहीं; डिफ़ॉल्ट तौर पर इस टारगेट से जुड़ा चेतावनी वाला मैसेज. आम तौर पर, इसका इस्तेमाल उपयोगकर्ताओं को यह बताने के लिए किया जाता है कि टारगेट पुराना हो गया है या किसी दूसरे नियम की वजह से उसकी जगह ले लिया गया है. यह किसी पैकेज के लिए निजी होता है या किसी वजह से उसे नुकसान पहुंचाने वाला माना जाता है. कुछ रेफ़रंस (जैसे कि वेबपेज, गड़बड़ी की संख्या या माइग्रेशन सीएलए के उदाहरण) शामिल करना अच्छा रहता है, ताकि आसानी से यह पता लगाया जा सके कि मैसेज से बचने के लिए कौनसे बदलाव करने की ज़रूरत है. अगर कोई ऐसा नया टारगेट है जिसका इस्तेमाल कम करने के लिए किया जा सकता है, तो पुराने टारगेट के सभी उपयोगकर्ताओं को माइग्रेट करना बेहतर होगा.
इस एट्रिब्यूट से चीज़ों को बनाने के तरीके पर कोई असर नहीं पड़ता. हालांकि, इसका असर बिल्ड टूल के डाइग्नोस्टिक आउटपुट पर पड़ सकता है. जब इंट्रा-पैकेज डिपेंडेंसी को इस चेतावनी से छूट दी जाती है. इसलिए, उदाहरण के लिए, किसी ऐसे नियम के टेस्ट बनाने पर चेतावनी नहीं मिलती जो अब काम नहीं करता. अगर कोई बंद किया गया टारगेट, किसी दूसरे काम न करने वाले टारगेट पर निर्भर करता है, तो चेतावनी वाला कोई मैसेज नहीं दिखाया जाता. जब लोग इसका इस्तेमाल करना बंद कर देते हैं, तो टारगेट को हटाया जा सकता है. |
distribs |
स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती;
डिफ़ॉल्ट तौर पर यह इस खास टारगेट के लिए इस्तेमाल की जाने वाली डिस्ट्रिब्यूशन-तरीका स्ट्रिंग की सूची. यह लाइसेंस देने वाले ऐसे एपीआई का हिस्सा है जो अब काम नहीं करता. यह Bazel अब इस्तेमाल नहीं करता. इसका इस्तेमाल न करें. |
exec_compatible_with |
लेबल की सूची;
कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह
इस टारगेट के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म में |
exec_properties |
स्ट्रिंग का शब्दकोश; स्ट्रिंग का ऐसा शब्दकोश जिसे इस टारगेट के लिए चुने गए प्लैटफ़ॉर्म के अगर कोई कुंजी प्लैटफ़ॉर्म और टारगेट-लेवल प्रॉपर्टी, दोनों में मौजूद है, तो वैल्यू को टारगेट से लिया जाएगा. |
features |
सुविधा स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से यह सुविधा स्ट्रिंग टैग है, जिसे किसी टारगेट के लिए चालू या बंद किया जा सकता है. सुविधा का मतलब, नियम के हिसाब से तय होता है. इस |
restricted_to |
लेबल की सूची;
कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह डिफ़ॉल्ट रूप से काम करने वाले एनवायरमेंट के बजाय, इस टारगेट एनवायरमेंट की सूची बनाई जा सकती है.
यह Bazel के कंस्ट्रेंट सिस्टम का हिस्सा है. ज़्यादा जानकारी के लिए, |
tags |
स्ट्रिंग की सूची; कॉन्फ़िगर नहीं की जा सकती;
डिफ़ॉल्ट तौर पर यह
टैग का इस्तेमाल किसी भी नियम के लिए किया जा सकता है. टेस्ट पर टैग और
अगर हमें किसी टेस्ट या
टेस्ट पर टैग का इस्तेमाल, आम तौर पर डीबग और रिलीज़ की प्रोसेस में, टेस्ट की भूमिका के बारे में बताने के लिए किया जाता है. आम तौर पर, टैग ऐसे C++ और Python टेस्ट के लिए सबसे ज़्यादा काम के होते हैं जिनमें रनटाइम के दौरान एनोटेशन बताने की कोई सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोड बेस चेक-इन नीति के आधार पर टेस्ट के सुइट असेंबल करने में आसानी होती है.
अगर बैजल को टेस्ट के नियम के
|
target_compatible_with |
लेबल की सूची;
ऐसे टारगेट जो पूरी तरह से काम न करने वाले टारगेट पर निर्भर करते हैं, वे अपने-आप ही काम नहीं करते हैं. उन्हें बनाने और टेस्ट करने के लिए भी छोड़ दिया जाता है. एक खाली सूची (जो डिफ़ॉल्ट है) बताती है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है.
Workspace के नियमों के अलावा, दूसरे सभी नियम इस एट्रिब्यूट के साथ काम करते हैं.
कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए,
काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें. |
testonly |
बूलियन; कॉन्फ़िगर करने लायक; टेस्ट और टेस्ट सुइट टारगेट को छोड़कर, डिफ़ॉल्ट
अगर
इसी तरह,
जांच ( इस एट्रिब्यूट का मतलब यह है कि टारगेट, प्रोडक्शन के लिए रिलीज़ की गई बाइनरी में नहीं होना चाहिए. क्योंकि testonly को बिल्ड के समय लागू किया जाता है, न कि रन टाइम पर. साथ ही, डिपेंडेंसी ट्री के ज़रिए वायरल होने पर उसे लागू किया जाता है. इसलिए, उसे सोच-समझकर लागू किया जाना चाहिए. उदाहरण के लिए, यूनिट टेस्ट के लिए काम आने वाले स्टब और नकली स्टब, इंटिग्रेशन टेस्ट में भी काम आ सकते हैं. इसमें वही बाइनरी शामिल होती हैं जिन्हें प्रोडक्शन के लिए रिलीज़ किया जाएगा. इसलिए, शायद उन्हें सिर्फ़ टेस्ट के तौर पर मार्क नहीं किया जाना चाहिए. इसके ठीक उलट, जिन नियमों को लिंक करना भी खतरनाक होता है उन्हें सिर्फ़ टेस्ट के तौर पर मार्क किया जाना चाहिए. |
toolchains |
लेबल की सूची;
कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट तौर पर यह
टारगेट का वह सेट जिसके वैरिएबल बनाएं इस टारगेट को
ऐक्सेस करने की अनुमति है. ये टारगेट या तो नियमों के इंस्टेंस हैं, जो
ध्यान रखें कि यह
टूलचेन रिज़ॉल्यूशन
के सिद्धांत से अलग है. इस सिद्धांत का इस्तेमाल, प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए नियम लागू करके किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह पता नहीं लगाया जा सकता कि टारगेट किस |
visibility |
लेबल की सूची;
कॉन्फ़िगर नहीं किया जा सकता;
अगर तय किया गया हो, तो
पैकेज से
टारगेट पर |
जांच के सभी नियमों के लिए सामान्य एट्रिब्यूट (*_test)
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो जांच के सभी नियमों में एक जैसे होते हैं.
एट्रिब्यूट | ब्यौरा | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
args |
स्ट्रिंग की सूची; यह $(location) और "वैरिएबल बनाएं" की जगह पर, और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. यह डिफ़ॉल्ट रूप से वे कमांड लाइन आर्ग्युमेंट जिन्हें
इन आर्ग्युमेंट को |
||||||||||||||||||||
env |
स्ट्रिंग की डिक्शनरी; वैल्यू के तौर पर
$(location) और
"वैरिएबल बनाएं" की जगह लागू की जाती है. डिफ़ॉल्ट तौर पर, यह
यह एट्रिब्यूट सिर्फ़ |
||||||||||||||||||||
env_inherit |
स्ट्रिंग की सूची;
यह एट्रिब्यूट सिर्फ़ |
||||||||||||||||||||
size |
स्ट्रिंग इससे यह पता चलता है कि टेस्ट टारगेट का कितना "ज़्यादा" कितना "है", इसे चलाने के लिए कितना समय/संसाधन चाहिए. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट को "मीडियम", और एंड-टू-एंड टेस्ट को "बड़ा" या
"बड़ा" माना जाता है. Bazel डिफ़ॉल्ट रूप से टाइम आउट तय करने के लिए, साइज़ का इस्तेमाल करता है. इसे टेस्ट साइज़, इन डिफ़ॉल्ट टाइम आउट और सबसे ज़्यादा स्थानीय संसाधनों के इस्तेमाल के मुताबिक होते हैं:
टेस्ट को जनरेट करते समय, एनवायरमेंट वैरिएबल
|
||||||||||||||||||||
timeout |
स्ट्रिंग लौटने से पहले टेस्ट को कितने समय तक चलने की उम्मीद है.
टेस्ट का साइज़ एट्रिब्यूट, संसाधन के अनुमान को कंट्रोल करता है. हालांकि, टेस्ट का टाइम आउट अलग से सेट किया जा सकता है. अगर साफ़ तौर पर इसकी जानकारी नहीं दी जाती है, तो समयसीमा टेस्ट के साइज़ के हिसाब से तय होती है. जांच के समय को
ऊपर दिए गए समय के अलावा, किसी अन्य समय के लिए, जांच के टाइम आउट को
टेस्ट को शुरू करते समय, एनवायरमेंट वैरिएबल
|
||||||||||||||||||||
flaky |
बूलियन; कॉन्फ़िगर करने लायक;
डिफ़ॉल्ट तौर पर टेस्ट को फ़्लैकी के तौर पर मार्क करता है. सेट करने पर, टेस्ट को ज़्यादा से ज़्यादा तीन बार लागू करता है. साथ ही, अगर यह हर बार फ़ेल होता है, तो इसे फ़ेल के तौर पर मार्क किया जाता है. डिफ़ॉल्ट रूप से, यह एट्रिब्यूट 'गलत' पर सेट होता है और टेस्ट सिर्फ़ एक बार चलाया जाता है. ध्यान दें कि आम तौर पर, इस एट्रिब्यूट के इस्तेमाल की सलाह नहीं दी जाती है. जब दावे सही साबित होते हैं, तब जांच सही तरीके से पास हो जानी चाहिए. |
||||||||||||||||||||
shard_count |
50 से कम या उसके बराबर गैर-ऋणात्मक पूर्णांक; डिफ़ॉल्ट उन पैरलल शार्ड की संख्या बताता है जिनका इस्तेमाल टेस्ट चलाने के लिए किया जाता है. अगर यह वैल्यू सेट कर दी जाती है, तो यह उन समानांतर शार्ड की संख्या तय करने के लिए इस्तेमाल किए जाने वाले
किसी भी अनुभव को बदल देगी जिनसे टेस्ट करना है. ध्यान दें कि कुछ टेस्ट नियमों में, इस पैरामीटर की ज़रूरत हो सकती है, ताकि पहली बार में शार्डिंग की सुविधा चालू की जा सके. अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को जनरेट करते समय एनवायरमेंट वैरिएबल शार्डिंग का इस्तेमाल करने के लिए, टेस्ट रनर की ज़रूरत होती है, ताकि वह टेस्ट शार्डिंग प्रोटोकॉल के साथ काम कर सके. अगर ऐसा नहीं होता है, तो इस बात की संभावना है कि यह हर शार्ड में हर टेस्ट को चलाएगा, जो कि आपकी ज़रूरत नहीं है. शार्डिंग के बारे में जानकारी के लिए, टेस्ट एनसाइक्लोपीडिया में टेस्ट शार्डिंग देखें. |
||||||||||||||||||||
local |
बूलियन; कॉन्फ़िगर करने लायक;
डिफ़ॉल्ट तौर पर टेस्ट को हर हाल में, सैंडबॉक्सिंग के बिना स्थानीय रूप से चलाए जाने के लिए मजबूर करता है. इसे 'सही है' पर सेट करना, टैग ( |
सभी बाइनरी नियमों (*_बाइनरी) के लिए समान विशेषताएं
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो बाइनरी के सभी नियमों में एक जैसे होते हैं.
एट्रिब्यूट | ब्यौरा |
---|---|
args |
स्ट्रिंग की सूची;
$(location) और
"वैरिएबल" के बदले, और
बॉर्न शेल टोकनाइज़ेशन;
कॉन्फ़िगर नहीं किया जा सकता;
डिफ़ॉल्ट रूप से
वे कमांड लाइन तर्क जिन्हें
ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तब आर्ग्युमेंट पास नहीं किए जाते. उदाहरण के लिए, |
env |
स्ट्रिंग की डिक्शनरी. वैल्यू, $(location) और "वैरिएबल बनाएं" की जगह पर लागू होती हैं. डिफ़ॉल्ट तौर पर, यह जब टारगेट को
यह एट्रिब्यूट सिर्फ़
ध्यान दें: जब टारगेट को Bazel के बाहर चलाया जाता है, तब एनवायरमेंट वैरिएबल सेट नहीं किए जाते. उदाहरण के लिए, |
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 फ़ाइलों में या कमांड लाइन से नहीं किया जा सकता.
इस तरह, बिल्ड टूल अपना काम करने के तरीके की कुछ जानकारी छिपा सकता है. इस बारे में ज़्यादा जानकारी, बिल्ड कॉन्सेप्ट के रेफ़रंस में दी गई है.