कार्रवाई
बिल्ड के दौरान चलाया जाने वाला कमांड. उदाहरण के लिए, किसी ऐसे कंपाइलर को कॉल करना जो इनपुट के तौर पर आर्टफ़ैक्ट लेता है और आउटपुट के तौर पर दूसरे आर्टफ़ैक्ट बनाता है. इसमें मेटाडेटा शामिल होता है, जैसे कि कमांड लाइन आर्ग्युमेंट, ऐक्शन बटन, एनवायरमेंट वैरिएबल, और एलान किए गए इनपुट/आउटपुट आर्टफ़ैक्ट.
यह भी देखें: नियमों का दस्तावेज़
ऐक्शन कैश
डिस्क पर मौजूद कैश मेमोरी, जो पूरी की गई कार्रवाइयों और उनके बनाए गए आउटपुट की मैपिंग को सेव करती है. कैश मेमोरी कुंजी को ऐक्शन कुंजी कहा जाता है. Bazel के इंक्रीमेंटल मॉडल के लिए मुख्य कॉम्पोनेंट. कैश मेमोरी, आउटपुट बेस डायरेक्ट्री में सेव की जाती है. इसलिए, Bazel सर्वर के रीस्टार्ट होने पर भी यह मेमोरी सेव रहती है.
ऐक्शन ग्राफ़
कार्रवाइयों और उन आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़, जिन्हें ये कार्रवाइयां पढ़ती हैं और जनरेट करती हैं. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो सोर्स फ़ाइलों (उदाहरण के लिए, फ़ाइल सिस्टम में) के तौर पर मौजूद होते हैं. साथ ही, इसमें जनरेट किए गए ऐसे इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनके बारे में BUILD फ़ाइलों में नहीं बताया गया है. विश्लेषण के चरण के दौरान जनरेट किया जाता है और कार्रवाई के चरण के दौरान इस्तेमाल किया जाता है.
ऐक्शन ग्राफ़ क्वेरी (aquery)
क्वेरी टूल, जो बिल्ट इन कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण करने में मदद मिलती है कि बिल्ड के नियम, असल काम के बिल्ड में कैसे बदलते हैं.
ऐक्शन बटन
किसी कार्रवाई की कैश मेमोरी कुंजी. यह वैल्यू, ऐक्शन मेटाडेटा के आधार पर कैलकुलेट की जाती है. इसमें ऐक्शन के आधार पर, ऐक्शन में लागू किए जाने वाले निर्देश, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. इससे Bazel, अलग-अलग कार्रवाइयों को कैश मेमोरी में सेव या अमान्य कर सकता है.
विश्लेषण का फ़ेज़
बिल्ड का दूसरा चरण. BUILD फ़ाइलों में बताए गए टारगेट ग्राफ़ को प्रोसेस करता है, ताकि इन-मेमोरी ऐक्शन ग्राफ़ बनाया जा सके. यह ग्राफ़, एक्सीक्यूशन फ़ेज़ के दौरान चलने वाली कार्रवाइयों का क्रम तय करता है. इस फ़ेज़ में, नियम लागू करने का आकलन किया जाता है.
सह-प्रॉडक्ट
सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है, जिसे ट्री आर्टफ़ैक्ट कहा जाता है.
आर्टफ़ैक्ट, एक से ज़्यादा कार्रवाइयों का इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक ही कार्रवाई से जनरेट किया जाना चाहिए.
फ़ाइल टारगेट से जुड़े आर्टफ़ैक्ट को लेबल से ऐक्सेस किया जा सकता है.
पक्ष
नियमों के लिए एक ऐसा तरीका जिससे उनकी डिपेंडेंसी में अतिरिक्त कार्रवाइयां बनाई जा सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर करता है, तो A पर ऐसा ऐस्पेक्ट लागू किया जा सकता है जो B के डिपेंडेंसी एज को अप ट्रैवर्स करता है. साथ ही, अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा करने के लिए, B में अतिरिक्त कार्रवाइयां करता है. इन अतिरिक्त कार्रवाइयों को कैश मेमोरी में सेव किया जाता है और उन टारगेट के बीच फिर से इस्तेमाल किया जाता है जिनके लिए एक ही आसपेक्ट की ज़रूरत होती है. इसे
aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. उदाहरण के लिए, इसका इस्तेमाल आईडीई के लिए मेटाडेटा जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.
यह भी देखें: ऐस्पेक्ट के दस्तावेज़
आसपेक्ट-ऑन-ऐस्पेक्ट
कॉम्पोज़िशन का एक तरीका, जिसमें अन्य एस्पेक्ट के नतीजों पर एस्पेक्ट लागू किए जा सकते हैं. उदाहरण के लिए, किसी प्रोटो से .java फ़ाइलें जनरेट करने वाले ऐस्पेक्ट के ऊपर, IDEs के इस्तेमाल के लिए जानकारी जनरेट करने वाले ऐस्पेक्ट को लागू किया जा सकता है.
किसी पहलू A को पहलू B के ऊपर लागू करने के लिए, B के provides एट्रिब्यूट में विज्ञापन देने वाले प्रोवाइडर, A के required_aspect_providers एट्रिब्यूट में बताए गए विज्ञापन से मेल खाने चाहिए.
एट्रिब्यूट
नियम का पैरामीटर, जिसका इस्तेमाल हर टारगेट के लिए बिल्ड की जानकारी देने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts, जो टारगेट की सोर्स फ़ाइलों, डिपेंडेंसी, और कस्टम कंपाइलर के विकल्पों के बारे में बताते हैं. किसी टारगेट के लिए उपलब्ध खास एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
Bazel की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, स्टार्टअप
फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने के लिए किया जाता है. साथ ही, इसकी मदद से विकल्पों के सामान्य ग्रुप तय किए जा सकते हैं. इसके बाद, --config फ़्लैग का इस्तेमाल करके, Bazel कमांड लाइन पर एक साथ सेट किए जा सकते हैं. Bazel, कई bazelrc फ़ाइलों (सिस्टमवाइड, हर वर्कस्पेस के लिए, हर उपयोगकर्ता के लिए या पसंद के मुताबिक जगह से) की सेटिंग को जोड़ सकता है. साथ ही, bazelrc फ़ाइल, अन्य bazelrc फ़ाइलों से सेटिंग इंपोर्ट भी कर सकती है.
Blaze
Bazel का Google का वर्शन. Google के मुख्य बिल्ड सिस्टम का इस्तेमाल, एक ही जगह पर मौजूद कई रिपॉज़िटरी के लिए किया जाता है.
BUILD फ़ाइल
BUILD फ़ाइल, मुख्य कॉन्फ़िगरेशन फ़ाइल होती है. इससे Bazel को पता चलता है कि कौनसा सॉफ़्टवेयर रिज़ल्ट बनाना है, उनकी डिपेंडेंसी क्या हैं, और उन्हें कैसे बनाना है. Bazel, BUILD फ़ाइल को इनपुट के तौर पर लेता है और इस फ़ाइल का इस्तेमाल करके, डिपेंडेंसी का ग्राफ़ बनाता है. साथ ही, यह उन कार्रवाइयों को पूरा करता है जो इंटरमीडिएट और फ़ाइनल सॉफ़्टवेयर आउटपुट बनाने के लिए ज़रूरी हैं. BUILD फ़ाइल, डायरेक्ट्री और ऐसी सब-डायरेक्ट्री को पैकेज के तौर पर मार्क करती है जिनमें BUILD फ़ाइल मौजूद नहीं होती. साथ ही, इसमें नियमों से बनाए गए टारगेट शामिल हो सकते हैं. फ़ाइल का नाम BUILD.bazel भी हो सकता है.
BUILD.bazel फ़ाइल
BUILD फ़ाइल देखें. एक ही डायरेक्ट्री में मौजूद BUILD फ़ाइल पर प्राथमिकता दी जाती है.
.bzl फ़ाइल
ऐसी फ़ाइल जिसमें Starlark में लिखे गए नियम, मैक्रो, और कॉन्स्टेंट की जानकारी होती है. इसके बाद, load() फ़ंक्शन का इस्तेमाल करके, इन्हें BUILD
फ़ाइलों में इंपोर्ट किया जा सकता है.
ग्राफ़ बनाना
डिपेंडेंसी ग्राफ़, जिसे Bazel बनाता है और बिल्ड करने के लिए ट्रैवर्स करता है. इसमें टारगेट, कॉन्फ़िगर किए गए टारगेट, ऐक्शन, और आर्टफ़ैक्ट जैसे नोड शामिल होते हैं. किसी बिल्ड को तब पूरा माना जाता है, जब उन सभी आर्टफ़ैक्ट की पुष्टि हो जाती है जिन पर अनुरोध किए गए टारगेट का सेट निर्भर करता है.
बिल्ड सेटिंग
Starlark से तय किया गया कॉन्फ़िगरेशन. ट्रांज़िशन, किसी सबग्राफ़ के कॉन्फ़िगरेशन को बदलने के लिए, बिल्ड सेटिंग सेट कर सकते हैं. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.
क्लीन बिल्ड
ऐसा बिल्ड जो पिछले बिल्ड के नतीजों का इस्तेमाल नहीं करता. आम तौर पर, यह इंक्रीमेंटल बिल्ड से धीमा होता है. हालांकि, आम तौर पर इसे ज़्यादा सही माना जाता है. Bazel यह पक्का करता है कि क्लीन और इंक्रीमेंटल, दोनों तरह के बिल्ड हमेशा सही हों.
क्लाइंट-सर्वर मॉडल
bazel कमांड-लाइन क्लाइंट, Bazel कमांड को लागू करने के लिए, स्थानीय मशीन पर बैकग्राउंड सर्वर को अपने-आप शुरू करता है. सर्वर सभी निर्देशों के लिए काम करता है. हालांकि, कुछ समय तक कोई गतिविधि न होने पर या साफ़ तौर पर bazel shutdown का इस्तेमाल करके, यह अपने-आप बंद हो जाता है. Bazel को सर्वर और क्लाइंट में बांटने से, JVM के शुरू होने में लगने वाले समय को कम करने में मदद मिलती है. साथ ही, इंक्रीमेंटल बिल्ड तेज़ी से होते हैं, क्योंकि ऐक्शन ग्राफ़ सभी निर्देशों में मेमोरी में बना रहता है.
कमांड
इसका इस्तेमाल कमांड लाइन पर, bazel
build, bazel test, bazel run, और bazel query जैसे अलग-अलग Bazel फ़ंक्शन को ट्रिगर करने के लिए किया जाता है.
कमांड फ़्लैग
किसी कमांड के लिए खास फ़्लैग का सेट. कमांड फ़्लैग, कमांड (bazel build <command flags>) के बाद दिए जाते हैं. फ़्लैग एक या उससे ज़्यादा कमांड पर लागू हो सकते हैं. उदाहरण के लिए, --configure सिर्फ़ bazel sync कमांड के लिए एक फ़्लैग है, लेकिन --keep_going sync, build, test वगैरह पर लागू होता है. फ़्लैग का इस्तेमाल अक्सर कॉन्फ़िगरेशन के लिए किया जाता है. इसलिए, फ़्लैग की वैल्यू में बदलाव होने पर, Bazel में-मेमोरी ग्राफ़ को अमान्य कर सकता है और विश्लेषण का फ़ेज़ फिर से शुरू कर सकता है.
कॉन्फ़िगरेशन
नियम की परिभाषाओं से बाहर की जानकारी, जो नियमों के कार्रवाइयों को जनरेट करने के तरीके पर असर डालती है. हर बिल्ड में कम से कम एक कॉन्फ़िगरेशन होता है, जिसमें टारगेट प्लैटफ़ॉर्म, ऐक्शन एनवायरमेंट वैरिएबल, और कमांड-लाइन बिल्ड फ़्लैग की जानकारी होती है. ट्रांज़िशन से, होस्ट टूल या क्रॉस-कंपाइलेशन जैसे अन्य कॉन्फ़िगरेशन बन सकते हैं.
यह भी देखें: कॉन्फ़िगरेशन
कॉन्फ़िगरेशन में बदलाव करना
सिर्फ़ उन कॉन्फ़िगरेशन को शामिल करने की प्रोसेस जिनकी ज़रूरत टारगेट को होती है. उदाहरण के लिए, अगर C++ डिपेंडेंसी //:c के साथ Java बाइनरी //:j को बनाया जाता है, तो //:c के कॉन्फ़िगरेशन में --javacopt की वैल्यू शामिल करना बेकार है. ऐसा इसलिए, क्योंकि --javacopt में बदलाव करने से C++ बाइनरी को कैश मेमोरी में सेव करने की सुविधा काम नहीं करती.
कॉन्फ़िगर की गई क्वेरी (cquery)
क्वेरी टूल, जो विश्लेषण के चरण के पूरा होने के बाद, कॉन्फ़िगर किए गए टारगेट पर क्वेरी करता है. इसका मतलब है कि select() और बिल्ड फ़्लैग (जैसे कि --platforms), नतीजों में सटीक तरीके से दिखते हैं.
यह भी देखें: cquery दस्तावेज़
कॉन्फ़िगर किया गया टारगेट
कॉन्फ़िगरेशन की मदद से टारगेट का आकलन करने का नतीजा. विश्लेषण के चरण में, बिल्ड के विकल्पों को उन टारगेट के साथ जोड़कर यह जानकारी मिलती है जिन्हें बनाना है.
उदाहरण के लिए, अगर //:foo एक ही बिल्ड में दो अलग-अलग आर्किटेक्चर के लिए बना है, तो उसके दो कॉन्फ़िगर किए गए टारगेट होंगे: <//:foo, x86> और <//:foo, arm>.
सही है या नहीं
कोई बिल्ड तब सही होता है, जब उसका आउटपुट, ट्रांज़िटिव इनपुट की स्थिति को सही तरीके से दिखाता हो. सही बिल्ड पाने के लिए, Bazel हर्मेटिक और दोबारा इस्तेमाल किया जा सकने वाला होना चाहिए. साथ ही, बिल्ड विश्लेषण और कार्रवाई को लागू करने की प्रोसेस, डिटरमिनिस्टिक होनी चाहिए.
निर्भर है
दो टारगेट के बीच डायरेक्ट किया गया एज. अगर //:foo के एट्रिब्यूट की वैल्यू में //:bar का रेफ़रंस है, तो टारगेट //:foo का टारगेट //:bar पर टारगेट डिपेंडेंसी है. अगर //:foo में मौजूद कोई कार्रवाई, //:bar में मौजूद किसी कार्रवाई से बनाए गए इनपुट आर्टफ़ैक्ट पर निर्भर करती है, तो //:foo में //:bar पर कार्रवाई की डिपेंडेंसी होती है.
कुछ मामलों में, इसका मतलब बाहरी डिपेंडेंसी से भी हो सकता है. मॉड्यूल देखें.
Depset
ट्रांज़िशन डिपेंडेंसी पर डेटा इकट्ठा करने के लिए डेटा स्ट्रक्चर. इसे ऑप्टिमाइज़ किया गया है, ताकि डिप्सेट को मर्ज करने में कम समय और स्टोरेज खर्च हो. ऐसा इसलिए, क्योंकि आम तौर पर डिप्सेट बहुत बड़े होते हैं (हज़ारों फ़ाइलें). जगह बचाने के लिए, बार-बार दूसरे डेपसेट का रेफ़रंस देने के मकसद से लागू किया गया. नियम को लागू करने के लिए, डिप्सेट को सूचियों में बदलकर उन्हें "फ़्लैट" नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि नियम, बिल्ड ग्राफ़ के सबसे ऊपरी लेवल पर न हो. बड़े डेपसेट को फ़्लैट करने पर, बहुत ज़्यादा मेमोरी खर्च होती है. इसे Bazel के अंदरूनी लागू करने के तरीके में, नेस्ट किए गए सेट भी कहा जाता है.
यह भी देखें: Depset का दस्तावेज़
डिस्क कैश मेमोरी
रिमोट कैश मेमोरी की सुविधा के लिए, डिस्क पर मौजूद एक लोकल ब्लॉब स्टोर. इसका इस्तेमाल, किसी असल रिमोट ब्लॉब स्टोर के साथ किया जा सकता है.
Distdir
रीड-ओनली डायरेक्ट्री, जिसमें ऐसी फ़ाइलें होती हैं जिन्हें Bazel, रिपॉज़िटरी के नियमों का इस्तेमाल करके इंटरनेट से फ़ेच करता. इससे बिल्ड पूरी तरह से ऑफ़लाइन चल पाते हैं.
डाइनैमिक तरीके से लागू करना
प्लान लागू करने की ऐसी रणनीति जो अलग-अलग हेयुरिस्टिक्स के आधार पर, स्थानीय और रिमोट प्लान लागू करने के बीच चुनती है. साथ ही, प्लान लागू करने के सबसे तेज़ तरीके के नतीजों का इस्तेमाल करती है. कुछ कार्रवाइयां स्थानीय तौर पर तेज़ी से पूरी की जाती हैं. जैसे, लिंक करना. वहीं, कुछ कार्रवाइयां रिमोट तौर पर तेज़ी से पूरी की जाती हैं. जैसे, एक साथ कई प्रोसेस करने की सुविधा वाला कंपाइलेशन. डाइनैमिक तरीके से लागू करने की रणनीति से, बेहतरीन और साफ़ तरीके से इंक्रीमेंटल बिल्ड का समय मिल सकता है.
लागू करने का फ़ेज़
बिल्ड का तीसरा चरण. विश्लेषण के चरण के दौरान बनाए गए ऐक्शन ग्राफ़ में ऐक्शन को लागू करता है. ये कार्रवाइयां, आर्टफ़ैक्ट को पढ़ने और लिखने के लिए, एक्सीक्यूटेबल (कंपाइलर, स्क्रिप्ट) को शुरू करती हैं. स्पैन की रणनीतियां यह कंट्रोल करती हैं कि इन कार्रवाइयों को कैसे लागू किया जाए: स्थानीय तौर पर, रिमोट तौर पर, डाइनैमिक तौर पर, सैंडबॉक्स में, डॉकर वगैरह.
एक्ज़ीक्यूशन रूट
वर्कस्पेस की आउटपुट बेस डायरेक्ट्री में मौजूद एक डायरेक्ट्री, जहां सैंडबॉक्स किए गए बिल्ड में लोकल ऐक्शन लागू किए जाते हैं. डायरेक्ट्री के कॉन्टेंट में, ज़्यादातर वर्कस्पेस के इनपुट आर्टफ़ैक्ट के सिंबललिंक होते हैं. एक्सीक्यूशन रूट में, अन्य इनपुट के तौर पर बाहरी रिपॉज़िटरी के लिए सिमलंक भी होते हैं. साथ ही, इसमें आउटपुट को सेव करने के लिए bazel-out डायरेक्ट्री भी होती है. लोड करने के फ़ेज़ के दौरान, उन डायरेक्ट्री का सिमलिंक फ़ॉरेस्ट बनाकर तैयार किया जाता है जो उन पैकेज के ट्रांज़िशन क्लोज़र को दिखाते हैं जिन पर बिल्ड निर्भर करता है. कमांड लाइन पर bazel info
execution_root का इस्तेमाल करके ऐक्सेस किया जा सकता है.
फ़ाइल
आर्टफ़ैक्ट देखें.
Hermeticity
अगर बिल्ड और टेस्ट ऑपरेशन पर बाहरी कोई असर नहीं पड़ता है, तो बिल्ड को हेर्मेटिक माना जाता है. इससे यह पक्का करने में मदद मिलती है कि नतीजे तय और सही हों. उदाहरण के लिए, आम तौर पर, एयरटाइट बिल्ड में कार्रवाइयों के लिए नेटवर्क ऐक्सेस की अनुमति नहीं होती. साथ ही, एयरटाइट बिल्ड में एलान किए गए इनपुट के ऐक्सेस पर पाबंदी होती है. साथ ही, इनमें तय टाइमस्टैंप और टाइमज़ोन का इस्तेमाल किया जाता है. इसके अलावा, एयरटाइट बिल्ड में, एनवायरमेंट वैरिएबल के ऐक्सेस पर पाबंदी होती है और रैंडम नंबर जनरेटर के लिए तय सीड का इस्तेमाल किया जाता है
इंक्रीमेंटल बिल्ड
इंक्रीमेंटल बिल्ड, पिछले बिल्ड के नतीजों का फिर से इस्तेमाल करता है, ताकि बिल्ड में लगने वाला समय और रिसॉर्स का इस्तेमाल कम हो. डिपेंडेंसी की जांच करने और कैश मेमोरी में डेटा सेव करने का मकसद, इस तरह के बिल्ड के लिए सही नतीजे देना है. इंक्रीमेंटल बिल्ड, क्लीन बिल्ड के उलट होता है.
लेबल
टारगेट के लिए आइडेंटिफ़ायर. आम तौर पर, इसका फ़ॉर्मैट @repo//path/to/package:target होता है. इसमें repo, टारगेट वाली रिपॉज़िटरी का नाम होता है. path/to/package, उस डायरेक्ट्री का पाथ होता है जिसमें टारगेट की जानकारी देने वाली BUILD फ़ाइल होती है. इस डायरेक्ट्री को पैकेज भी कहा जाता है. target, टारगेट का नाम होता है. स्थिति के हिसाब से, इस सिंटैक्स के कुछ हिस्सों को छोड़ा जा सकता है.
यह भी देखें: लेबल
लोडिंग का चरण
बिल्ड का पहला चरण, जिसमें पैकेज बनाने के लिए, Bazel BUILD फ़ाइलों को लागू करता है. इस फ़ेज़ में, मैक्रो और glob() जैसे कुछ फ़ंक्शन का आकलन किया जाता है. टारगेट ग्राफ़ बनाने के लिए, बिल्ड के दूसरे चरण, विश्लेषण के चरण के साथ इंटरलीव किया जाता है.
लेगसी मैक्रो
मैक्रो का एक फ़्लेवर, जिसे सामान्य Starlark फ़ंक्शन के तौर पर घोषित किया जाता है. यह BUILD फ़ाइल को चलाने के साइड इफ़ेक्ट के तौर पर चलता है.
लेगसी मैक्रो, फ़ंक्शन के तौर पर काम कर सकते हैं. इसका मतलब है कि ये सुविधाजनक हो सकते हैं,
लेकिन इन्हें पढ़ना, लिखना, और इस्तेमाल करना मुश्किल हो सकता है. लेगसी मैक्रो, अपने आर्ग्युमेंट में अचानक बदलाव कर सकता है या select() या गलत टाइप वाला आर्ग्युमेंट मिलने पर काम नहीं कर सकता.
सिंबल मैक्रो के साथ तुलना करें.
यह भी देखें: लेगसी मैक्रो का दस्तावेज़
मैक्रो
एक Starlark फ़ंक्शन में, एक साथ कई नियम टारगेट एलान बनाने का तरीका. BUILD फ़ाइलों में, नियम के एलान के सामान्य पैटर्न का फिर से इस्तेमाल करने की सुविधा देता है. लोडिंग फ़ेज़ के दौरान, मौजूदा नियम के टारगेट डिक्लेरेशन में बड़ा किया गया.
यह दो तरह का होता है: सिंबल मैक्रो (Bazel 8 के बाद से) और लेगसी मैक्रो.
Mnemonic
नियम बनाने वाले व्यक्ति की चुनी हुई एक छोटी और आसानी से पढ़ी जा सकने वाली स्ट्रिंग. इससे यह तुरंत समझा जा सकता है कि नियम में मौजूद कार्रवाई क्या कर रही है. स्पैन रणनीति चुनने के लिए, स्मृति सहायक का इस्तेमाल आइडेंटिफ़ायर के तौर पर किया जा सकता है. ऐक्शन के लिए याद रखने लायक कुछ उदाहरणों में, Java नियमों से Javac, C++ नियमों से CppCompile, और Android नियमों से AndroidManifestMerger शामिल हैं.
मॉड्यूल
Bazel प्रोजेक्ट, जिसमें कई वर्शन हो सकते हैं. इनमें से हर वर्शन में, दूसरे मॉड्यूल पर डिपेंडेंसी हो सकती है. यह, डिपेंडेंसी मैनेजमेंट के अन्य सिस्टम में मौजूद आम कॉन्सेप्ट से मिलता-जुलता है. जैसे, Maven आर्टफ़ैक्ट, npm पैकेज, Go मॉड्यूल या Cargo क्रेट. मॉड्यूल, Bazel के बाहरी डिपेंडेंसी मैनेजमेंट सिस्टम का मुख्य हिस्सा होते हैं.
हर मॉड्यूल के लिए, एक रिपो होता है. इस रिपो के रूट में MODULE.bazel फ़ाइल होती है. इस फ़ाइल में, मॉड्यूल के बारे में मेटाडेटा (जैसे, उसका नाम और वर्शन), उसकी डायरेक्ट डिपेंडेंसी, और अन्य डेटा शामिल होता है. जैसे, टूलचेन रजिस्टरेशन और मॉड्यूल एक्सटेंशन इनपुट.
मॉड्यूल का मेटाडेटा, Bazel रजिस्ट्री में होस्ट किया जाता है.
यह भी देखें: Bazel मॉड्यूल
मॉड्यूल एक्सटेंशन
यह एक लॉजिक है, जिसे रिपॉज़िटरी जनरेट करने के लिए चलाया जा सकता है. इसके लिए, मॉड्यूल के डिपेंडेंसी ग्राफ़ से इनपुट पढ़े जाते हैं और रिपॉज़िटरी के नियम लागू किए जाते हैं. मॉड्यूल एक्सटेंशन में, repo के नियमों जैसी सुविधाएं होती हैं. इनकी मदद से, इंटरनेट को ऐक्सेस किया जा सकता है, फ़ाइल I/O किया जा सकता है वगैरह.
यह भी देखें: मॉड्यूल एक्सटेंशन
नेटिव नियम
Bazel में बने और Java में लागू किए गए नियम. ये नियम, .bzl फ़ाइलों में नेटिव मॉड्यूल के फ़ंक्शन के तौर पर दिखते हैं. उदाहरण के लिए, native.cc_library या native.java_library. उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव), Starlark का इस्तेमाल करके बनाए जाते हैं.
आउटपुट बेस
Bazel की आउटपुट फ़ाइलों को सेव करने के लिए, फ़ाइल फ़ोल्डर से जुड़ी डायरेक्ट्री. फ़ाइल फ़ोल्डर के सोर्स ट्री (मुख्य रिपॉज़िटरी) से आउटपुट को अलग करने के लिए इस्तेमाल किया जाता है. यह आउटपुट उपयोगकर्ता रूट में मौजूद होता है.
आउटपुट ग्रुप
फ़ाइलों का एक ग्रुप, जिसे Bazel के टारगेट बनाने के बाद बिल्ड किया जाना है. नियम, अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में डालते हैं.उदाहरण के लिए, cc_library टारगेट के लिए java_library, .a, और .so की .jar फ़ाइल. डिफ़ॉल्ट आउटपुट ग्रुप वह आउटपुट ग्रुप होता है जिसके आर्टफ़ैक्ट, कमांड-लाइन पर टारगेट का अनुरोध किए जाने पर बनाए जाते हैं.
नियमों से, नाम वाले ज़्यादा आउटपुट ग्रुप तय किए जा सकते हैं. इन ग्रुप के बारे में, BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन (--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.
उपयोगकर्ता रूट को आउटपुट करना
Bazel के आउटपुट को सेव करने के लिए, उपयोगकर्ता के हिसाब से बनाई गई डायरेक्ट्री. डायरेक्ट्री का नाम, उपयोगकर्ता के सिस्टम उपयोगकर्ता नाम से लिया जाता है. अगर एक ही समय पर कई उपयोगकर्ता, सिस्टम पर एक ही प्रोजेक्ट बना रहे हैं, तो आउटपुट फ़ाइल के क्रैश होने से रोकता है. इसमें अलग-अलग फ़ाइल फ़ोल्डर के बिल्ड आउटपुट से जुड़ी सबडायरेक्ट्री होती हैं. इन्हें आउटपुट बेस भी कहा जाता है.
पैकेज
BUILD फ़ाइल से तय किया गया टारगेट का सेट. पैकेज का नाम, रिपो के रूट के हिसाब से BUILD फ़ाइल का पाथ होता है. किसी पैकेज में सब-पैकेज या BUILD
फ़ाइलें हो सकती हैं. इससे पैकेज की हैरारकी बनती है.
पैकेज ग्रुप
पैकेज के सेट को दिखाने वाला टारगेट. इसका इस्तेमाल अक्सर visibility एट्रिब्यूट की वैल्यू में किया जाता है.
प्लैटफ़ॉर्म
किसी बिल्ड में शामिल "मशीन टाइप". इसमें वह मशीन शामिल है जिस पर Bazel चलता है ("होस्ट" प्लैटफ़ॉर्म), मशीन के बिल्ड टूल ("exec" प्लैटफ़ॉर्म) पर चलने वाले टूल, और मशीन के टारगेट ("टारगेट प्लैटफ़ॉर्म") के लिए बनाए गए टूल शामिल हैं.
सेवा देने वाली कंपनी
यह एक स्कीमा है, जिसमें जानकारी की एक इकाई के बारे में बताया गया है. यह इकाई, डिपेंडेंसी रिलेशनशिप के साथ नियम के टारगेट के बीच पास की जाती है. आम तौर पर, इसमें कॉम्पाइलर के विकल्प, ट्रांज़िशन सोर्स या आउटपुट फ़ाइलें, और बिल्ड मेटाडेटा जैसी जानकारी शामिल होती है. इकट्ठा किए गए ट्रांज़िशन डेटा को बेहतर तरीके से सेव करने के लिए, अक्सर depsets के साथ इस्तेमाल किया जाता है. पहले से मौजूद प्रोवाइडर का उदाहरण DefaultInfo है.
यह भी देखें: सेवा देने वाली कंपनी का दस्तावेज़
क्वेरी (कॉन्सेप्ट)
टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझने के लिए, बिल्ड ग्राफ़ का विश्लेषण करने की प्रोसेस. Bazel में क्वेरी के तीन वैरिएंट इस्तेमाल किए जा सकते हैं: query, cquery, और aquery.
क्वेरी (कमांड)
क्वेरी टूल, जो बिल्ड के लोड होने के बाद के चरण के टारगेट ग्राफ़ पर काम करता है. यह अपेक्षाकृत तेज़ है,
लेकिन इससे select(), बिल्ड फ़्लैग,
आर्टफ़ैक्ट या ऐक्शन के असर का विश्लेषण नहीं किया जा सकता.
यह भी देखें: क्वेरी करने का तरीका, क्वेरी का रेफ़रंस
रिपॉज़िटरी
रूट में बाउंड्री मार्कर फ़ाइल वाला डायरेक्ट्री ट्री, जिसमें ऐसी सोर्स फ़ाइलें होती हैं जिनका इस्तेमाल Bazel बिल्ड में किया जा सकता है. इसे अक्सर repo के तौर पर छोटा किया जाता है.
किसी रिपॉज़िटरी की सीमा के मार्कर की फ़ाइल, MODULE.bazel (इससे पता चलता है कि यह रिपॉज़िटरी, Bazel मॉड्यूल को दिखाती है), REPO.bazel या लेगसी कॉन्टेक्स्ट में, WORKSPACE या
WORKSPACE.bazel हो सकती है. किसी भी रिपॉज़िटरी की सीमा को मार्क करने वाली फ़ाइल, रिपॉज़िटरी की सीमा को दिखाएगी. एक ही डायरेक्ट्री में ऐसी कई फ़ाइलें मौजूद हो सकती हैं.
मुख्य रिपॉज़िटरी वह रिपॉज़िटरी होती है जिसमें मौजूदा Bazel कमांड चलाया जा रहा है.
बाहरी रिपॉज़िटरी तय करने के लिए, MODULE.bazel फ़ाइलों में मॉड्यूल तय किए जाते हैं या मॉड्यूल एक्सटेंशन में रिपॉज़िटरी के नियम लागू किए जाते हैं. इन्हें डिस्क पर पहले से तय की गई "मैजिकल" जगह पर, मांग के हिसाब से फ़ेच किया जा सकता है.
हर रिपॉज़िटरी का एक यूनीक और हमेशा एक जैसा कैननिकल नाम होता है. साथ ही, अन्य रिपॉज़िटरी से देखने पर, रिपॉज़िटरी के अलग-अलग ऐपैरेंट नाम दिख सकते हैं.
यह भी देखें: बाहरी डिपेंडेंसी के बारे में खास जानकारी
डेटा स्टोर करने की जगह की कैश मेमोरी
यह, कॉन्टेंट के पते के हिसाब से कैश मेमोरी होती है. इसमें, Bazel के ज़रिए बिल्ड के लिए डाउनलोड की गई फ़ाइलें होती हैं. इन्हें वर्कस्पेस में शेयर किया जा सकता है. शुरुआती डाउनलोड के बाद, ऑफ़लाइन बिल्ड की सुविधा चालू करता है. आम तौर पर, http_archive जैसे रिपॉज़िटरी नियम और repository_ctx.download जैसे रिपॉज़िटरी नियम एपीआई की मदद से डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए इस्तेमाल किया जाता है. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब डाउनलोड के लिए उनके SHA-256 चेकसम तय किए गए हों.
रिपॉज़िटरी का नियम
रिपॉज़िटरी डेफ़िनिशन के लिए स्कीमा, जो Bazel को रिपॉज़िटरी को मैटीरियलाइज़ (या "फ़ेच") करने का तरीका बताता है. इसे अक्सर रिपो नियम कहा जाता है.
मॉड्यूल के ज़रिए बैक किए गए रिपॉज़िटरी तय करने के लिए, Bazel इन नियमों को अंदरूनी तौर पर लागू करता है. इसके अलावा, मॉड्यूल एक्सटेंशन भी इन नियमों को लागू कर सकते हैं.
रिपॉज़िटरी के नियमों की मदद से, इंटरनेट को ऐक्सेस किया जा सकता है या फ़ाइल I/O किया जा सकता है. रिपॉज़िटरी का सबसे सामान्य नियम यह है कि http_archive इंटरनेट से सोर्स फ़ाइलों वाला संग्रह डाउनलोड किया जाए.
यह भी देखें: रिपो के नियमों का दस्तावेज़
फिर से बनाया जा सकने वाला
बिल्ड या टेस्ट की वह प्रॉपर्टी जिससे यह पता चलता है कि बिल्ड या टेस्ट में इनपुट का एक सेट, समय, तरीके या एनवायरमेंट के बावजूद, हर बार एक ही आउटपुट सेट बनाएगा. ध्यान दें कि इसका यह मतलब नहीं है कि आउटपुट सही हैं या वे आउटपुट हैं जिनकी आपको ज़रूरत है.
नियम
BUILD फ़ाइल में नियम के टारगेट तय करने के लिए स्कीमा, जैसे कि
cc_library. BUILD फ़ाइल के लेखक के हिसाब से, किसी नियम में एट्रिब्यूट का एक सेट और ब्लैक बॉक्स लॉजिक शामिल होता है. लॉजिक, नियम के टारगेट को यह बताता है कि आउटपुट आर्टफ़ैक्ट कैसे बनाएं और अन्य नियम के टारगेट को जानकारी कैसे दें. .bzl के लेखकों के हिसाब से, नियमों का इस्तेमाल करके ही Bazel को नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने लायक बनाया जा सकता है.
लोडिंग फ़ेज़ में नियम टारगेट बनाने के लिए, नियमों को इंस्टैंशिएट किया जाता है. विश्लेषण के चरण में, नियम के टारगेट, प्रोवाइडर के तौर पर अपनी डाउनस्ट्रीम डिपेंडेंसी को जानकारी देते हैं. साथ ही, अपने आउटपुट आर्टफ़ैक्ट जनरेट करने का तरीका बताने वाली कार्रवाइयां रजिस्टर करते हैं. ये कार्रवाइयां कार्रवाई करने के चरण में की जाती हैं.
यह भी देखें: नियमों का दस्तावेज़
नियम का टारगेट
ऐसा टारगेट जो किसी नियम का इंस्टेंस हो. फ़ाइल टारगेट और पैकेज ग्रुप के मुकाबले, यह अलग होता है. इसे नियम से न जोड़ें.
रनफ़ाइलें
किसी एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, रनफ़ाइलें, जांच के रनटाइम डेटा की डिपेंडेंसी होती हैं और रनफ़ाइलें, जांच के नियम का रनटाइम आउटपुट होती हैं. बज़ल टेस्ट के दौरान, प्रोग्राम को शुरू करने से पहले Bazel, सोर्स डायरेक्ट्री के स्ट्रक्चर के हिसाब से, टेस्ट प्रोग्राम के साथ-साथ रनफ़ाइलों का ट्री तैयार करता है.
यह भी देखें: रनफ़ाइलों का दस्तावेज़
सैंडबॉक्सिंग
यह एक ऐसी तकनीक है जिसकी मदद से, चल रही कार्रवाई को पाबंदी वाले और कुछ समय के लिए उपलब्ध एक्सीक्यूशन रूट में अलग रखा जाता है. इससे यह पक्का करने में मदद मिलती है कि वह बिना एलान किए इनपुट न पढ़े या बिना एलान किए आउटपुट न लिखे. सैंडबॉक्सिंग से सुरक्षा को बेहतर बनाने में काफ़ी मदद मिलती है. हालांकि, आम तौर पर इससे परफ़ॉर्मेंस पर असर पड़ता है. साथ ही, इसके लिए ऑपरेटिंग सिस्टम की मदद भी ज़रूरी होती है. परफ़ॉर्मेंस की लागत, प्लैटफ़ॉर्म पर निर्भर करती है. Linux पर, इसकी कोई ज़रूरत नहीं है. हालांकि, macOS पर सैंडबॉक्सिंग का इस्तेमाल नहीं किया जा सकता.
Skyframe
Skyframe, Bazel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैलुएशन फ़्रेमवर्क है.
छपाई का काम
Bazel से बनाए गए आर्टफ़ैक्ट में ज़्यादा जानकारी जोड़ने की सुविधा. उदाहरण के लिए, इसका इस्तेमाल रिलीज़ बिल्ड के लिए, सोर्स कंट्रोल, बिल्ड के समय, और वर्कस्पेस या एनवायरमेंट से जुड़ी अन्य जानकारी के लिए किया जा सकता है.
स्टैंप एट्रिब्यूट के साथ काम करने वाले --workspace_status_command फ़्लैग और नियमों की मदद से चालू करें.
Starlark
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के मकसद से, Python का सीमित सबसेट (सिंटैक्स और व्याकरण के हिसाब से). .bzl
फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें, Starlark के ज़्यादा पाबंदी वाले वर्शन का इस्तेमाल करती हैं. जैसे, def फ़ंक्शन की परिभाषाएं नहीं. इसे पहले Skylark कहा जाता था.
यह भी देखें: Starlark भाषा का दस्तावेज़
स्टार्टअप फ़्लैग
bazel और कमांड के बीच दिए गए फ़्लैग का सेट. उदाहरण के लिए, bazel --host_jvm_debug build. ये फ़्लैग, Bazel सर्वर के कॉन्फ़िगरेशन में बदलाव करते हैं. इसलिए, स्टार्टअप फ़्लैग में कोई भी बदलाव करने पर, सर्वर रीस्टार्ट हो जाता है. स्टार्टअप फ़्लैग किसी खास कमांड के लिए नहीं होते.
सिंबल वाला मैक्रो
मैक्रो का एक फ़्लेवर, जिसे नियम जैसे एट्रिब्यूट स्कीमा के साथ एलान किया जाता है. इससे, एलान किए गए इंटरनल टारगेट को अपने पैकेज से छिपाने की अनुमति मिलती है. साथ ही, मैक्रो के एलान किए गए टारगेट पर, नाम तय करने का अनुमानित पैटर्न लागू होता है. इसे बड़े लेगसी मैक्रो कोडबेस में दिखने वाली कुछ समस्याओं से बचने के लिए डिज़ाइन किया गया है.
यह भी देखें: सिंबल मैक्रो का दस्तावेज़
टारगेट
ऐसा ऑब्जेक्ट जिसे BUILD फ़ाइल में तय किया गया है और जिसकी पहचान लेबल से की जाती है. टारगेट, असली उपयोगकर्ता के नज़रिए से, वर्कस्पेस की ऐसी यूनिट दिखाते हैं जिन्हें बनाया जा सकता है.
नियम को इंस्टैंशिएट करके बनाए गए टारगेट को नियम
टारगेट कहा जाता है. नियम के आधार पर, ये टारगेट cc_binary की तरह चलाए जा सकते हैं या cc_test की तरह जांचे जा सकते हैं. आम तौर पर, नियम के टारगेट अपने एट्रिब्यूट (जैसे, deps) के ज़रिए दूसरे टारगेट पर निर्भर होते हैं. ये डिपेंडेंसी, टारगेट ग्राफ़ का आधार बनाती हैं.
नियम के टारगेट के अलावा, फ़ाइल टारगेट और पैकेज ग्रुप के टारगेट भी होते हैं. फ़ाइल टारगेट, आर्टफ़ैक्ट से जुड़े होते हैं जिनका रेफ़रंस BUILD फ़ाइल में दिया गया होता है. किसी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल टारगेट माना जाता है.
टारगेट, लोडिंग फ़ेज़ के दौरान खोजे जाते हैं. विश्लेषण के फ़ेज़ के दौरान, कॉन्फ़िगर किए गए टारगेट बनाने के लिए, टारगेट को बिल्ड कॉन्फ़िगरेशन से जोड़ा जाता है.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. लोडिंग फ़ेज़ के दौरान जनरेट होता है और विश्लेषण फ़ेज़ में इनपुट के तौर पर इस्तेमाल किया जाता है.
टारगेट पैटर्न
कमांड लाइन पर टारगेट के ग्रुप की जानकारी देने का तरीका. आम तौर पर इस्तेमाल किए जाने वाले पैटर्न में :all (सभी नियम टारगेट), :* (सभी नियम + फ़ाइल टारगेट), ... (मौजूदा पैकेज और सभी सब-पैकेज बार-बार) शामिल हैं. इनका इस्तेमाल एक साथ किया जा सकता है. उदाहरण के लिए, //...:* का मतलब है कि वर्कस्पेस के रूट से, सभी पैकेज में मौजूद सभी नियम और फ़ाइल टारगेट को बार-बार लागू किया जाएगा.
जांच
नियम टारगेट, टेस्ट नियमों से इंस्टैंशिएट किए जाते हैं. इसलिए, इनमें टेस्ट को लागू करने वाला कोड होता है. अगर एक्सीक्यूटेबल कोड पूरा होने पर, रिटर्न कोड शून्य है, तो इसका मतलब है कि जांच पूरी हो गई है. Bazel और टेस्ट के बीच के कानूनी समझौते के बारे में टेस्ट एनसाइक्लोपीडिया में बताया गया है. जैसे, टेस्ट एनवायरमेंट वैरिएबल, टेस्ट के नतीजे इकट्ठा करने के तरीके.
टूलचेन
किसी भाषा के लिए आउटपुट बनाने के टूल का सेट. आम तौर पर, टूलचेन में कमपाइलर, लिंकर, इंटरप्रिटर या/और लिंटर शामिल होते हैं. प्लैटफ़ॉर्म के हिसाब से भी टूलचेन अलग-अलग हो सकते हैं. इसका मतलब है कि Unix कंपाइलर टूलचेन के कॉम्पोनेंट, Windows के वैरिएंट के लिए अलग-अलग हो सकते हैं. भले ही, टूलचेन एक ही भाषा के लिए हो. प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप-लेवल टारगेट
अगर Bazel कमांड लाइन पर किसी बिल्ड टारगेट का अनुरोध किया जाता है, तो वह टॉप-लेवल का होता है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर करता है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए, //:foo टॉप-लेवल है और //:bar टॉप-लेवल नहीं है. हालांकि, दोनों टारगेट को बिल्ड करना होगा. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच एक अहम अंतर यह है कि Bazel कमांड लाइन पर सेट किए गए कमांड फ़्लैग (या .bazelrc के ज़रिए), टॉप-लेवल टारगेट के लिए कॉन्फ़िगरेशन सेट करेंगे. हालांकि, नॉन-टॉप-लेवल टारगेट के लिए, ट्रांज़िशन की मदद से इनमें बदलाव किया जा सकता है.
ट्रांज़िशन
कॉन्फ़िगरेशन की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. बिल्ड ग्राफ़ में टारगेट के लिए अलग-अलग कॉन्फ़िगरेशन इस्तेमाल करने की सुविधा चालू करता है. भले ही, उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. ट्रांज़िशन का आम तौर पर इस्तेमाल, स्प्लिट ट्रांज़िशन के साथ किया जाता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को अलग-अलग कॉन्फ़िगरेशन के साथ फ़ॉर्क किया जाता है. उदाहरण के लिए, एक ही बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल करके, ARM और x86 के लिए कॉम्पाइल की गई नेटिव बाइनरी के साथ Android APK बनाया जा सकता है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
पेड़ का आर्टफ़ैक्ट
फ़ाइलों का कलेक्शन दिखाने वाला आर्टफ़ैक्ट. ये फ़ाइलें खुद आर्टफ़ैक्ट नहीं होतीं. इसलिए, इन पर काम करने वाली कार्रवाई को ट्री आर्टफ़ैक्ट को अपने इनपुट या आउटपुट के तौर पर रजिस्टर करना होगा.
किसको दिखे
बिल्ड सिस्टम में अनचाही डिपेंडेंसी को रोकने के लिए, दो में से कोई एक तरीका अपनाया जा सकता है: टारगेट की विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि किसी टारगेट पर दूसरे टारगेट डिपेंड कर सकते हैं या नहीं; और लोड की विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि कोई BUILD या .bzl फ़ाइल, किसी .bzl फ़ाइल को लोड कर सकती है या नहीं. आम तौर पर, बिना संदर्भ के, "दिखना" का मतलब टारगेट के दिखने से होता है.
यह भी देखें: 'किसको दिखे' सेटिंग के बारे में दस्तावेज़
Workspace
Bazel के सभी कमांड के साथ शेयर किया गया एनवायरमेंट, एक ही मुख्य रिपॉज़िटरी से चलता है.
ध्यान दें कि "रिपॉज़िटरी" और "वर्कस्पेस" के कॉन्सेप्ट को ऐतिहासिक तौर पर एक ही माना जाता रहा है. "वर्कस्पेस" शब्द का इस्तेमाल अक्सर मुख्य रिपॉज़िटरी के लिए किया जाता है. कभी-कभी, इसका इस्तेमाल "रिपॉज़िटरी" के लिए भी किया जाता है. साफ़ तौर पर बताने के लिए, इस तरह के इस्तेमाल से बचना चाहिए.