इस सेक्शन में ऐसे कई शब्दों और कॉन्सेप्ट के बारे में बताया गया है जो आम तौर पर कई फ़ंक्शन या बिल्ड नियमों के लिए होते हैं.
विषय सूची
- बोन शेल टोकनाइज़ेशन
- लेबल एक्सपैंशन
- आम तौर पर, बिल्ड के ज़्यादातर नियमों से तय होने वाले एट्रिब्यूट
- बिल्डिंग के सभी नियमों में समान विशेषताएं
- जांच के सभी नियमों में आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट (*_test)
- सभी बाइनरी नियमों के लिए समान विशेषताएं (*_binary)
- कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट
- इंप्लिसिट आउटपुट टारगेट
बॉर्न शेल टोकनाइज़ेशन
बॉर्न शेल के टोकन के नियमों के मुताबिक, कुछ नियमों के कुछ स्ट्रिंग एट्रिब्यूट को कई शब्दों में बांटा जाता है: जिन स्पेस में कोट नहीं किए गए हैं उनकी संख्या अलग-अलग होती है. साथ ही, सिंगल-कोटेशन वर्ण और बैकस्लैश का इस्तेमाल टोकन को रोकने के लिए किया जाता है.
इस तरह के टोकन की पहचान, इस दस्तावेज़ में उनकी परिभाषा में साफ़ तौर पर दिखाई गई है.
"बनाएं" वैरिएबल और बॉर्न शेल टोकन से बने एट्रिब्यूट के तहत आने वाले एट्रिब्यूट का इस्तेमाल, आम तौर पर कंपाइलर और अन्य टूल के लिए, आर्बिट्रेरी विकल्पों को पास करने के लिए किया जाता है. इस तरह के एट्रिब्यूट
cc_library.copts
और java_library.javacopts
हैं.
इन विकल्पों को मिलाकर, एक स्ट्रिंग वैरिएबल, विकल्प के शब्दों की कॉन्फ़िगरेशन के हिसाब से बनी सूची में शामिल हो सकता है.
लेबल एक्सपैंशन
कुछ स्ट्रिंग के कुछ एट्रिब्यूट पर लेबल को बड़ा किया जा सकता है: अगर इन स्ट्रिंग में सबस्ट्रिंग के तौर पर कोई मान्य लेबल है, जैसे कि //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 |
अगर सही है, तो सिर्फ़ इस टारगेट पर सिर्फ़ टेस्ट टारगेट ही हो सकते हैं (जैसे कि टेस्ट).
इसी तरह,
टेस्ट ( इस एट्रिब्यूट का मतलब है कि टारगेट को उन बाइनरी में शामिल नहीं किया जाना चाहिए जो प्रोडक्शन के लिए रिलीज़ किए गए हैं. टेस्ट सिर्फ़ बिल्ड टाइम पर लागू किया जाता है, रन टाइम पर नहीं, और डिपेंडेंसी ट्री से मुख्य रूप से लागू किया जाता है. इसलिए, इसे सोच-समझकर लागू करना चाहिए. उदाहरण के लिए, स्टब और फेक जो यूनिट टेस्ट के लिए उपयोगी हैं, इंटिग्रेशन टेस्ट के लिए भी काम के हो सकते हैं. इनमें वे बाइनरी शामिल होती हैं जिन्हें प्रोडक्शन में रिलीज़ किया जाएगा. इसलिए, हो सकता है कि इन्हें सिर्फ़ टेस्ट मार्क न किया जाए. इसके उलट, उन नियमों को टेस्ट के तौर पर मार्क किया जाना चाहिए जो बिना किसी शर्त के सामान्य व्यवहार को अनदेखा कर देते हैं. |
toolchains |
टारगेट का वह सेट जिसके वैरिएबल बनाएं इस टारगेट को
ऐक्सेस करने की अनुमति हो. ये टारगेट, नियमों के ऐसे उदाहरण होते हैं जो
ध्यान रखें कि यह टूलचेन रिज़ॉल्यूशन के सिद्धांत से अलग है. इसका इस्तेमाल, नियम बनाकर लागू करने के लिए प्लैटफ़ॉर्म पर निर्भर कॉन्फ़िगरेशन के लिए किया जाता है. इस एट्रिब्यूट का इस्तेमाल करके, यह तय नहीं किया जा सकता कि कोई टारगेट |
visibility |
टारगेट पर |
विशेषताएं, सभी टेस्ट नियमों के लिए आम हैं (*_test)
इस सेक्शन में, उन एट्रिब्यूट के बारे में बताया गया है जो जांच के सभी नियमों के लिए आम हैं.
एट्रिब्यूट | जानकारी | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
args |
ये तर्क, |
||||||||||||||||||||
env |
यह नीति,
यह एट्रिब्यूट सिर्फ़ नेटिव नियमों, जैसे कि |
||||||||||||||||||||
env_inherit |
जब
यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि |
||||||||||||||||||||
size |
इससे, किसी जांच के टारगेट की "ज़्यादा" के बारे में पता चलता है. उसे चलने में कितना समय/संसाधन लगता है. यूनिट टेस्ट को "छोटा", इंटिग्रेशन टेस्ट "मीडियम", और एंड-टू-एंड टेस्ट "बड़े" या
"ज़्यादा" वाले टेस्ट माने जाते हैं. डिफ़ॉल्ट रूप से टाइम आउट तय करने के लिए, बेज़ल साइज़ का इस्तेमाल करता है. इसे जांच के आकार इन डिफ़ॉल्ट टाइम आउट के मुताबिक होते हैं और इन्हें स्थानीय संसाधन के इस्तेमाल के तौर पर माना जाता है:
टेस्ट को ट्रिगर करते समय, एनवायरमेंट वैरिएबल |
||||||||||||||||||||
timeout |
वापस आने से पहले, टेस्ट को कितने समय तक चलने की उम्मीद है.
जांच का साइज़, रिसॉर्स के अनुमान को कंट्रोल करता है. हालांकि, जांच का टाइम आउट अलग से सेट किया जा सकता है. अगर साफ़ तौर पर न बताया गया हो, तो टाइम आउट टेस्ट के साइज़ पर आधारित होता है. टेस्ट
टाइम आउट को
ऊपर दिए गए समय के अलावा, टेस्ट टाइम आउट को टेस्ट को ट्रिगर करते समय, एनवायरमेंट वैरिएबल |
||||||||||||||||||||
flaky |
टेस्ट को खराब के तौर पर मार्क करता है. अगर नीति को सेट किया जाता है, तो जांच को तीन बार किया जा सकता है. साथ ही, हर बार फ़ेल होने पर, जांच को 'पूरा नहीं हुआ' के तौर पर मार्क किया जा सकता है. डिफ़ॉल्ट रूप से, यह एट्रिब्यूट 'गलत है' पर सेट होता है और जांच सिर्फ़ एक बार होती है. ध्यान दें, इस एट्रिब्यूट का इस्तेमाल आम तौर पर न किया जाए - उनके दावे बरकरार रहने के बाद टेस्ट भरोसेमंद तरीके से पास किए जाने चाहिए. |
||||||||||||||||||||
shard_count |
टेस्ट को चलाने के लिए, पैरलल शार्ड की संख्या तय करता है. यह मान उन समानार्थी शार्ड की संख्या तय करने के लिए
इस्तेमाल किए गए अनुमानों को बदल देगा, जिनके साथ टेस्ट चलाना है. ध्यान दें कि कुछ टेस्ट नियमों के लिए, पहली बार में शार्डिंग चालू करने के लिए, इस पैरामीटर की ज़रूरत पड़ सकती है. अगर टेस्ट शार्डिंग चालू है, तो टेस्ट को ट्रिगर करते समय एनवायरमेंट वैरिएबल शार्डिंग में परीक्षण धावक के समर्थन के लिए परीक्षण रनर की आवश्यकता होती है. अगर ऐसा नहीं किया जाता है, तो हो सकता है कि यह हर शार्ड में हर जांच को चलाए, जो आपको नहीं चाहिए. शार्डिंग के बारे में ज़्यादा जानने के लिए, टेस्ट एन्साइक्लोपीडिया में टेस्ट शार्डिंग देखें. |
||||||||||||||||||||
local |
इससे सैंडबॉक्स के बिना, टेस्ट स्थानीय रूप से चलता है. इसे 'सही है' पर सेट करना, एक टैग के तौर पर "स्थानीय" उपलब्ध कराने के बराबर है
( |
सभी बाइनरी नियमों के लिए समान विशेषताएं (*_binary)
इस सेक्शन में, उन एट्रिब्यूट के बारे में बताया गया है जो सभी बाइनरी नियमों के लिए आम हैं.
एट्रिब्यूट | जानकारी |
---|---|
args |
कमांड लाइन आर्ग्युमेंट, जो Bazel को टारगेट करने पर पास होगा. ऐसा
ध्यान दें: अगर आप बेज़ल के बाहर टारगेट (उदाहरण के लिए, |
env |
यह नीति
यह एट्रिब्यूट सिर्फ़ नेटिव नियमों पर लागू होता है, जैसे कि
ध्यान दें: अगर आप बेज़ल के बाहर टारगेट (उदाहरण के लिए, |
output_licenses |
इस बाइनरी फ़ाइल से जनरेट की जाने वाली आउटपुट फ़ाइलों के लाइसेंस. यह लाइसेंस देने वाले एपीआई का वह हिस्सा है जिसे अब इस्तेमाल नहीं किया जाता. 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 फ़ाइलों में या कमांड लाइन से नहीं दिया जा सकता.
इस तरह, बिल्ड टूल काम करने के तरीके से जुड़ी कुछ खास जानकारी छिपा सकता है. ज़्यादा जानकारी के लिए,
बिल्ड कॉन्सेप्ट रेफ़रंस में जाएं.