इस सेक्शन में ऐसे अलग-अलग शब्दों और अवधारणाओं के बारे में बताया गया है, जो कई फ़ंक्शन के लिए सामान्य हैं या जो नियम बनाते हैं.
विषय सूची
- बॉर्न शेल टोकनाइज़ेशन
- लेबल एक्सपैंशन
- बिल बनाने के ज़्यादातर नियमों से तय किए गए सामान्य एट्रिब्यूट
- बिल बनाने के सभी नियमों के लिए सामान्य एट्रिब्यूट
- टेस्ट के सभी नियमों के लिए एक जैसे एट्रिब्यूट (*_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 टेस्ट के लिए सबसे ज़्यादा काम के होते हैं, क्योंकि इनमें रनटाइम के बारे में बताने वाली कोई सुविधा नहीं होती. टैग और साइज़ एलिमेंट का इस्तेमाल करने से, कोड बेस में चेक-इन करने की नीति के हिसाब से, टेस्ट के सुइट असेंबल करने की सुविधा मिलती है.
अगर Bazel को टेस्ट के नियम के
|
target_compatible_with |
जो टारगेट पूरी तरह से काम नहीं करने वाले टारगेट पर निर्भर रहते हैं उन्हें ही काम का नहीं माना जाता है. इन्हें भी बनाने और टेस्ट करने के लिए हटा दिया जाता है. एक खाली सूची (जो डिफ़ॉल्ट है) बताती है कि टारगेट सभी प्लैटफ़ॉर्म के साथ काम करता है.
फ़ाइल फ़ोल्डर के नियम को छोड़कर, बाकी सभी नियम इस एट्रिब्यूट के साथ काम करते हैं.
कुछ नियमों के लिए, इस एट्रिब्यूट का कोई असर नहीं होता. उदाहरण के लिए,
काम न करने वाले टारगेट को स्किप करने के बारे में ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें. |
testonly |
अगर सही है, तो सिर्फ़ जांच करने वाले टारगेट (जैसे कि टेस्ट) इस टारगेट पर निर्भर कर सकते हैं.
इसी तरह, जो नियम
टेस्ट ( इस एट्रिब्यूट का मकसद यह है कि टारगेट, प्रोडक्शन के लिए रिलीज़ किए गए बाइनरी फ़ॉर्मैट में नहीं होना चाहिए. क्योंकि testसिर्फ़ बिल्ड के समय लागू किया जाता है, न कि रन टाइम पर. साथ ही, डिपेंडेंसी ट्री के ज़रिए वायरल होता है. इसलिए, इसे सोच-समझकर लागू किया जाना चाहिए. जैसे, यूनिट टेस्ट के लिए काम आने वाले स्टब और फ़ेक, इंटिग्रेशन टेस्ट के लिए भी काम आ सकते हैं. इनमें ऐसी बाइनरी शामिल हैं जिन्हें प्रोडक्शन के लिए रिलीज़ किया जाएगा. इसलिए, इन्हें शायद सिर्फ़ टेस्ट के लिए मार्क नहीं किया जाना चाहिए. इसके ठीक उलट, जो नियम लिंक करना भी खतरनाक हैं, उन्हें सिर्फ़ टेस्ट-ओनली के तौर पर मार्क किया जाना चाहिए. शायद इसलिए, क्योंकि वे सामान्य व्यवहार को बिना किसी शर्त के ओवरराइड करते हैं. |
toolchains |
टारगेट का वह सेट जिसके वैरिएबल बनाएं इस टारगेट को
ऐक्सेस करने की अनुमति है. ये टारगेट या तो
ध्यान रखें कि यह
टूलचेन रिज़ॉल्यूशन से अलग है.
इसका इस्तेमाल प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए, नियम लागू करने में किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह पता नहीं लगाया जा सकता कि टारगेट किस |
visibility |
टारगेट पर मौजूद |
जांच के सभी नियमों के लिए एक जैसे एट्रिब्यूट (*_test)
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो जांच के सभी नियमों में एक जैसे होते हैं.
एट्रिब्यूट | ब्यौरा | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
args |
वे कमांड लाइन तर्क जिन्हें
इन तर्कों को, |
||||||||||||||||||||
env |
इस नीति से, अतिरिक्त एनवायरमेंट वैरिएबल के बारे में जानकारी मिलती है, जिन्हें
यह एट्रिब्यूट सिर्फ़ |
||||||||||||||||||||
env_inherit |
इस नीति से, ऐसे अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं जो
बाहरी एनवायरमेंट से इनहेरिट किए जाते हैं. ऐसा तब होता है, जब
यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि |
||||||||||||||||||||
size |
इससे पता चलता है कि टेस्ट टारगेट को कितना "ज़्यादा" चाहिए: इसे चलाने के लिए कितना समय/संसाधन चाहिए. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट "मीडियम", और एंड-टू-एंड टेस्ट "बड़ा" या
"बहुत ज़्यादा" माने जाते हैं. Bazel, डिफ़ॉल्ट टाइम आउट तय करने के लिए साइज़ का इस्तेमाल करता है. इसे टेस्ट साइज़, नीचे दिए गए डिफ़ॉल्ट टाइम आउट और अनुमानित स्थानीय रिसॉर्स के इस्तेमाल से जुड़े होते हैं:
टेस्ट को तैयार करते समय, एनवायरमेंट वैरिएबल |
||||||||||||||||||||
timeout |
वापस लौटने से पहले टेस्ट कितनी देर तक चलना चाहिए.
टेस्ट का साइज़ एट्रिब्यूट, रिसॉर्स के अनुमान को कंट्रोल करता है. हालांकि, टेस्ट का टाइम आउट अलग से सेट किया जा सकता है. अगर साफ़ तौर पर नहीं बताया गया है, तो
समयसीमा टेस्ट के साइज़ पर आधारित होती है. जांच के टाइम आउट को
ऊपर बताई गई स्थितियों के अलावा, जांच के टाइम आउट को टेस्ट को शुरू करते समय, एनवायरमेंट वैरिएबल |
||||||||||||||||||||
flaky |
टेस्ट को फ़्लैकी के तौर पर मार्क करता है. सेट किए जाने पर, टेस्ट को ज़्यादा से ज़्यादा तीन बार करता है. अगर इसे हर बार फ़ेल कर दिया जाता है, तो इसे 'फ़ेल हुआ' के तौर पर मार्क किया जाता है. डिफ़ॉल्ट रूप से, यह एट्रिब्यूट 'गलत' पर सेट होता है और जांच सिर्फ़ एक बार की जाती है. ध्यान दें कि आम तौर पर इस एट्रिब्यूट के इस्तेमाल की सलाह नहीं दी जाती है. जब दावे बरकरार रहते हैं, तब जांच को भरोसेमंद तरीके से पास किया जाना चाहिए. |
||||||||||||||||||||
shard_count |
यह तय करता है कि टेस्ट करने के लिए, पैरलल शार्ड की संख्या कितनी है. यह वैल्यू, ऐसे पैरलल शार्ड की संख्या तय करने के लिए इस्तेमाल किए जाने वाले किसी भी अनुमान को बदल देगी
जिनसे टेस्ट करना है. ध्यान दें कि कुछ टेस्ट नियमों के लिए, इस पैरामीटर को पहली जगह शार्डिंग की सुविधा चालू करने की ज़रूरत पड़ सकती है. अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को बनाते समय एनवायरमेंट वैरिएबल शार्डिंग के लिए टेस्ट रनर की ज़रूरत होती है, ताकि वह टेस्ट शार्डिंग प्रोटोकॉल के साथ काम कर सके. अगर ऐसा नहीं है, तो हो सकता है कि यह हर शार्ड में हर टेस्ट को चलाएगा, जो कि आप चाहते नहीं हैं. शार्डिंग के बारे में जानकारी के लिए, टेस्ट एन्साइक्लोपीडिया में टेस्टिंग देखें. |
||||||||||||||||||||
local |
सैंडबॉक्सिंग के बिना, टेस्ट को स्थानीय रूप से चलाने के लिए मजबूर करता है. इसे 'सही है' पर सेट करने का मतलब, "स्थानीय" को टैग ( |
सभी बाइनरी नियमों (*_बाइनरी) के लिए सामान्य विशेषताएं
इस सेक्शन में उन एट्रिब्यूट के बारे में बताया गया है जो बाइनरी के सभी नियमों में एक जैसे होते हैं.
एट्रिब्यूट | ब्यौरा |
---|---|
args |
वे कमांड लाइन तर्क जिन्हें Bazel, टारगेट को तब पास करेगा, जब उसे
ध्यान दें: जब टारगेट को Bazel के बाहर
चलाया जाता है, तो आर्ग्युमेंट पास नहीं होते. उदाहरण के लिए,
|
env |
इस नीति से, अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं, जिन्हें
यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि
ध्यान दें: जब टारगेट को 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
के तौर पर मार्क किया गया है वे
इस सुविधा का इस्तेमाल नहीं कर सकते. आम तौर पर, एक एट्रिब्यूट को कॉन्फ़िगर नहीं किया जा सकता, क्योंकि select()
को ठीक करने का तरीका जानने से पहले, Bazel को
इसकी वैल्यू पता होनी चाहिए.
ज़्यादा जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले बिल्ड एट्रिब्यूट देखें.
इंप्लिसिट आउटपुट टारगेट
C++ में इंप्लिसिट आउटपुट के इस्तेमाल पर रोक लगा दी गई है. कृपया जहां भी हो सके, दूसरी भाषाओं में इसका इस्तेमाल न करें. हमारे पास अभी तक कोई एक्सक्लूज़न पाथ नहीं है. हालांकि, आने वाले समय में यह भी बंद हो जाएगी.
BUILD फ़ाइल में बिल्ड का नियम तय करने का मतलब है कि
किसी पैकेज में, नाम वाले नए नियम के टारगेट का एलान किया जा रहा है. कई बिल्ड रूल
फ़ंक्शन भी अनुमान तौर पर, एक या उससे ज़्यादा आउटपुट फ़ाइल
टारगेट शामिल करते हैं, जिनका कॉन्टेंट और मतलब, अलग-अलग नियमों के हिसाब से होता है.
उदाहरण के लिए, जब साफ़ तौर पर
java_binary(name='foo', ...)
नियम का एलान किया जाता है, तो इसका मतलब है कि
किसी आउटपुट फ़ाइल टारगेट foo_deploy.jar
को भी उसी पैकेज के सदस्य के तौर पर बताया जाता है.
(यह खास तौर पर अपने-आप पूरा किया हुआ Java संग्रह है, जो डिप्लॉयमेंट के लिए सही है.)
इंप्लिसिट आउटपुट टारगेट, ग्लोबल टारगेट ग्राफ़ के फ़र्स्ट क्लास सदस्य हैं. दूसरे टारगेट की तरह ही, इन्हें भी मांग पर बनाया जाता है. ऐसा तब किया जाता है,
जब टॉप-लेवल के निर्देश में इसकी जानकारी दी गई हो या अन्य बिल्ड टारगेट के लिए
ज़रूरी शर्तें पूरी की गई हों. इन्हें BUILD फ़ाइलों में डिपेंडेंसी के तौर पर रेफ़र किया जा सकता है. साथ ही, इन्हें bazel query
जैसे विश्लेषण करने वाले टूल के आउटपुट में देखा जा सकता है.
हर तरह के बिल्ड के नियम के लिए, नियम के दस्तावेज़ में एक खास सेक्शन होता है. इस दस्तावेज़ में, ऐसे नियम के बारे में जानकारी से जुड़े किसी भी इंप्लिसिट आउटपुट के नाम और कॉन्टेंट की जानकारी दी जाती है.
बिल्ड सिस्टम में इस्तेमाल किए जाने वाले दो नेमस्पेस के बीच,
एक अहम, लेकिन थोड़ा मामूली अंतर:
लेबल, टारगेट की पहचान करते हैं,
जो नियम या फ़ाइलें हो सकते हैं. साथ ही, फ़ाइल टारगेट को
सोर्स (या इनपुट) फ़ाइल टारगेट और डेराइव किए गए (या आउटपुट) फ़ाइल टारगेट में से
बांटा जा सकता है. इन चीज़ों के बारे में BUILD फ़ाइलों में बताया जा सकता है, कमांड लाइन से बनाया जा सकता है या bazel query
का इस्तेमाल करके जांच की जा सकती है. यह टारगेट नेमस्पेस है. हर फ़ाइल टारगेट, डिस्क पर मौजूद एक असल फ़ाइल ("फ़ाइल सिस्टम नेमस्पेस") से जुड़ा होता है. हर नियम
टारगेट, डिस्क पर मौजूद एक या एक से ज़्यादा असल फ़ाइलों से जुड़ा हो सकता है.
डिस्क पर ऐसी फ़ाइलें हो सकती हैं जिनसे जुड़ा कोई टारगेट न हो. उदाहरण के लिए, C++ कंपाइलेशन के दौरान बनी .o
ऑब्जेक्ट फ़ाइलों को BUILD फ़ाइलों या कमांड लाइन से रेफ़र नहीं किया जा सकता.
इस तरह से हो सकता है कि बिल्ड टूल, लागू करने से जुड़ी कुछ जानकारी छिपा दे.
इससे यह पता चलता है कि आपका काम कैसे करता है. इस बारे में ज़्यादा जानकारी,
बिल्ड कॉन्सेप्ट के रेफ़रंस में दी गई है.