कार्रवाई
बिल्ड के दौरान चलाने के लिए कोई कमांड. उदाहरण के लिए, कंपाइलर को कॉल करना. यह आर्टफ़ैक्ट को इनपुट के तौर पर लेता है और दूसरे आर्टफ़ैक्ट को आउटपुट के तौर पर जनरेट करता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन की, एनवायरमेंट वैरिएबल, और इनपुट/आउटपुट आर्टफ़ैक्ट जैसे मेटाडेटा शामिल होते हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
ऐक्शन कैश
यह डिस्क पर मौजूद एक कैश मेमोरी होती है. इसमें, पूरी की गई कार्रवाइयों को उनके बनाए गए आउटपुट से मैप करने की जानकारी सेव होती है. कैश मेमोरी की कुंजी को ऐक्शन की कहा जाता है. यह Bazel के इंक्रीमेंटैलिटी मॉडल का एक मुख्य कॉम्पोनेंट है. कैश को आउटपुट बेस डायरेक्ट्री में सेव किया जाता है. इसलिए, Bazel सर्वर को फिर से शुरू करने पर भी यह मौजूद रहती है.
ऐक्शन ग्राफ़
यह कार्रवाइयों और आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़ होता है. इन कार्रवाइयों से, आर्टफ़ैक्ट को पढ़ा और जनरेट किया जाता है. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो सोर्स फ़ाइलों (उदाहरण के लिए, फ़ाइल सिस्टम में) के तौर पर मौजूद हैं. साथ ही, जनरेट किए गए इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनका ज़िक्र BUILD फ़ाइलों में नहीं किया गया है. इन्हें विश्लेषण के चरण के दौरान बनाया जाता है और लागू करने के चरण के दौरान इस्तेमाल किया जाता है.
ऐक्शन ग्राफ़ क्वेरी (aquery)
यह एक क्वेरी टूल है, जो बिल्ड कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण किया जा सकता है कि बिल्ड के नियम, असल में बिल्ड के काम में कैसे बदलते हैं.
ऐक्शन बटन
किसी ऐक्शन की कैश मेमोरी की कुंजी. यह कार्रवाई के मेटाडेटा के आधार पर कैलकुलेट किया जाता है. इसमें कार्रवाई में लागू की जाने वाली कमांड, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. यह कार्रवाई के हिसाब से तय होता है. इस कुकी की मदद से Bazel, अलग-अलग कार्रवाइयों को कैश मेमोरी में सेव कर पाता है या उन्हें रद्द कर पाता है.
विश्लेषण का फ़ेज़
बिल्ड का दूसरा फ़ेज़. यह BUILD फ़ाइलों में दिए गए टारगेट ग्राफ़ को प्रोसेस करता है, ताकि मेमोरी में मौजूद ऐक्शन ग्राफ़ बनाया जा सके. इससे यह तय होता है कि एक्ज़ीक्यूशन फ़ेज़ के दौरान, कार्रवाइयां किस क्रम में की जाएंगी. इस फ़ेज़ में, नियमों को लागू करने का आकलन किया जाता है.
सह-प्रॉडक्ट
सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है. इसे ट्री आर्टफ़ैक्ट कहा जाता है.
कोई आर्टफ़ैक्ट, कई कार्रवाइयों के लिए इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक कार्रवाई से जनरेट किया जाना चाहिए.
फ़ाइल टारगेट से जुड़े किसी आर्टफ़ैक्ट को लेबल से ऐक्सेस किया जा सकता है.
पक्ष
नियमों के लिए एक ऐसा तरीका जिससे वे अपनी डिपेंडेंसी में अतिरिक्त कार्रवाइयां कर सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर करता है, तो A पर एक ऐसा पहलू लागू किया जा सकता है जो निर्भरता वाले एज को ऊपर की ओर ले जाता है. साथ ही, B में अतिरिक्त कार्रवाइयां करता है, ताकि अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा की जा सकें. ये अतिरिक्त कार्रवाइयां कैश मेमोरी में सेव होती हैं. साथ ही, एक जैसी ज़रूरत वाले टारगेट के बीच इनका फिर से इस्तेमाल किया जाता है. इसे aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. इसका इस्तेमाल, उदाहरण के लिए, आईडीई के लिए मेटाडेटा जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.
यह भी देखें: Aspects का दस्तावेज़
आसपेक्ट-ऑन-आसपेक्ट
यह कंपोज़िशन का एक ऐसा तरीका है जिसमें किसी पहलू के नतीजों पर दूसरे पहलू लागू किए जा सकते हैं. उदाहरण के लिए, आईडीई के इस्तेमाल के लिए जानकारी जनरेट करने वाले पहलू को, .java फ़ाइलों को किसी प्रोटो से जनरेट करने वाले पहलू के ऊपर लागू किया जा सकता है.
A को B पर लागू करने के लिए, providers को provides एट्रिब्यूट में B के विज्ञापन के लिए दी गई वैल्यू को A के required_aspect_providers एट्रिब्यूट में दी गई वैल्यू से मैच करना होगा.
एट्रिब्यूट
यह नियम का पैरामीटर है. इसका इस्तेमाल, हर टारगेट के हिसाब से बिल्ड की जानकारी देने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts. ये क्रमशः किसी टारगेट की सोर्स फ़ाइलें, डिपेंडेंसी, और कस्टम कंपाइलर के विकल्प तय करते हैं. किसी टारगेट के लिए उपलब्ध एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
Bazel की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, स्टार्टअप फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने के लिए किया जाता है. साथ ही, विकल्पों के सामान्य ग्रुप तय करने के लिए भी इसका इस्तेमाल किया जाता है. इन ग्रुप को बाद में, Bazel कमांड लाइन पर --config फ़्लैग का इस्तेमाल करके एक साथ सेट किया जा सकता है. 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 में तय किया गया कॉन्फ़िगरेशन होता है. Transitions, सबग्राफ़ के कॉन्फ़िगरेशन में बदलाव करने के लिए, बिल्ड सेटिंग सेट कर सकते हैं. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.
क्लीन बिल्ड
ऐसा बिल्ड जो पहले के बिल्ड के नतीजों का इस्तेमाल नहीं करता. यह आम तौर पर, इंक्रीमेंटल बिल्ड से ज़्यादा समय लेता है. हालांकि, इसे आम तौर पर ज़्यादा सही माना जाता है. Bazel यह पक्का करता है कि क्लीन और इंक्रीमेंटल बिल्ड हमेशा सही हों.
क्लाइंट-सर्वर मॉडल
bazel कमांड-लाइन क्लाइंट, Bazel कमांड को चलाने के लिए, लोकल मशीन पर बैकग्राउंड सर्वर अपने-आप शुरू कर देता है. सर्वर, सभी कमांड के लिए चालू रहता है. हालांकि, कुछ समय तक कोई गतिविधि न होने पर यह अपने-आप बंद हो जाता है. इसके अलावा, इसे bazel shutdown कमांड का इस्तेमाल करके भी बंद किया जा सकता है. Bazel को सर्वर और क्लाइंट में बांटने से, JVM के स्टार्टअप में लगने वाले समय को कम करने में मदद मिलती है. साथ ही, इससे इंक्रीमेंटल बिल्ड को तेज़ी से सपोर्ट किया जा सकता है, क्योंकि ऐक्शन ग्राफ़ सभी कमांड के लिए मेमोरी में रहता है.
निर्देश
इसका इस्तेमाल कमांड लाइन पर अलग-अलग Bazel फ़ंक्शन को शुरू करने के लिए किया जाता है. जैसे, bazel
build, bazel test, bazel run, और bazel query.
कमांड फ़्लैग
किसी कमांड के लिए फ़्लैग का सेट. कमांड फ़्लैग, कमांड (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
यह डेटा स्ट्रक्चर, ट्रांज़िटिव डिपेंडेंसी का डेटा इकट्ठा करने के लिए होता है. इसे इस तरह से ऑप्टिमाइज़ किया गया है कि डिपसेट को मर्ज करने में कम समय लगे और कम स्टोरेज इस्तेमाल हो. ऐसा इसलिए, क्योंकि बहुत बड़े डिपसेट (लाखों फ़ाइलें) होना आम बात है. इसे इसलिए लागू किया गया है, ताकि स्पेस को कम से कम इस्तेमाल किया जा सके. इसके लिए, यह अन्य depsets को बार-बार रेफ़र करता है. नियम लागू करने के दौरान, डिपसेट को सूचियों में बदलकर उन्हें "फ़्लैट" नहीं किया जाना चाहिए. हालांकि, ऐसा तब किया जा सकता है, जब नियम बिल्ड ग्राफ़ के सबसे ऊपर वाले लेवल पर हो. बड़े डिपसेट को फ़्लैट करने पर, बहुत ज़्यादा मेमोरी खर्च होती है. Bazel के इंटरनल इंप्लीमेंटेशन में, इन्हें नेस्टेड सेट भी कहा जाता है.
यह भी देखें: Depset का दस्तावेज़
डिस्क कैश
यह रिमोट कैश मेमोरी की सुविधा के लिए, डिस्क पर मौजूद लोकल ब्लॉब स्टोर है. इसका इस्तेमाल, रिमोट के असल ब्लब स्टोर के साथ किया जा सकता है.
Distdir
यह सिर्फ़ पढ़ने के लिए उपलब्ध डायरेक्ट्री होती है. इसमें ऐसी फ़ाइलें होती हैं जिन्हें Bazel, इंटरनेट से फ़ेच करता है. इसके लिए, वह रिपॉज़िटरी के नियमों का इस्तेमाल करता है. इस विकल्प को चालू करने पर, बिल्ड पूरी तरह से ऑफ़लाइन मोड में चलाए जा सकते हैं.
डाइनैमिक एक्ज़ीक्यूशन
यह एक ऐसी रणनीति है जो अलग-अलग ह्यूरिस्टिक के आधार पर, लोकल और रिमोट एक्ज़ीक्यूशन में से किसी एक को चुनती है. साथ ही, यह तेज़ी से काम करने वाली और सफल तरीके से काम करने वाली विधि के एक्ज़ीक्यूशन के नतीजों का इस्तेमाल करती है. कुछ कार्रवाइयां स्थानीय तौर पर तेज़ी से पूरी होती हैं. जैसे, लिंक करना. वहीं, कुछ कार्रवाइयां रिमोट तौर पर तेज़ी से पूरी होती हैं. जैसे, ज़्यादा पैरलल किए जा सकने वाले कंपाइलेशन. डाइनैमिक एक्ज़ीक्यूशन की रणनीति से, सबसे कम समय में इंक्रीमेंटल और क्लीन बिल्ड तैयार किए जा सकते हैं.
लागू करने का चरण
बिल्ड का तीसरा चरण. यह विश्लेषण के चरण के दौरान बनाए गए ऐक्शन ग्राफ़ में मौजूद ऐक्शन को लागू करता है. ये कार्रवाइयां, एक्ज़ीक्यूटेबल (कंपाइलर, स्क्रिप्ट) को आर्टफ़ैक्ट को पढ़ने और लिखने के लिए शुरू करती हैं. स्पॉन करने की रणनीतियां यह कंट्रोल करती हैं कि इन कार्रवाइयों को कैसे लागू किया जाए: स्थानीय तौर पर, रिमोटली, डाइनैमिक तौर पर, सैंडबॉक्स में, डॉकर में वगैरह.
एक्ज़ीक्यूशन रूट
यह workspace के output base डायरेक्ट्री में मौजूद एक डायरेक्ट्री होती है. इसमें, नॉन-सैंडबॉक्स बिल्ड में लोकल कार्रवाइयां की जाती हैं. डायरेक्ट्री में मौजूद कॉन्टेंट, वर्कस्पेस से मिले इनपुट आर्टफ़ैक्ट के ज़्यादातर सिमलंक होते हैं. एक्ज़ीक्यूशन रूट में, अन्य इनपुट के तौर पर बाहरी रिपॉज़िटरी के सिमलिंक और आउटपुट सेव करने के लिए 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 के बाद से) और लेगसी मैक्रो.
याद रखने का तरीका
यह एक छोटी स्ट्रिंग होती है, जिसे नियम बनाने वाला व्यक्ति चुनता है. इससे यह समझने में आसानी होती है कि नियम में कार्रवाई क्या कर रही है. निमोनिक का इस्तेमाल, स्पॉन रणनीति चुनने के लिए आइडेंटिफ़ायर के तौर पर किया जा सकता है. कार्रवाई के लिए इस्तेमाल होने वाले कुछ निमोनिक के उदाहरण यहां दिए गए हैं: Java के नियमों के लिए Javac, C++ के नियमों के लिए CppCompile, और Android के नियमों के लिए AndroidManifestMerger.
मॉड्यूल
Bazel प्रोजेक्ट, जिसके कई वर्शन हो सकते हैं. इनमें से हर वर्शन, अन्य मॉड्यूल पर निर्भर हो सकता है. यह अन्य डिपेंडेंसी मैनेजमेंट सिस्टम में मौजूद जाने-पहचाने कॉन्सेप्ट के जैसा ही है. जैसे, Maven आर्टफ़ैक्ट, npm पैकेज, Go मॉड्यूल या Cargo क्रेट. मॉड्यूल, Bazel के बाहरी डिपेंडेंसी मैनेजमेंट सिस्टम का मुख्य हिस्सा होते हैं.
हर मॉड्यूल के साथ एक repo जुड़ा होता है. इसके रूट में एक MODULE.bazel फ़ाइल होती है. इस फ़ाइल में, मॉड्यूल के बारे में मेटाडेटा होता है. जैसे, इसका नाम और वर्शन. इसमें इसकी डायरेक्ट डिपेंडेंसी और टूलचेन रजिस्ट्रेशन और मॉड्यूल एक्सटेंशन इनपुट सहित कई अन्य डेटा भी शामिल होता है.
मॉड्यूल का मेटाडेटा, Bazel की रजिस्ट्री में होस्ट किया जाता है.
यह भी देखें: Bazel मॉड्यूल
मॉड्यूल एक्सटेंशन
यह एक लॉजिक है, जिसे मॉड्यूल डिपेंडेंसी ग्राफ़ से इनपुट पढ़कर और repo rules को लागू करके, repos जनरेट करने के लिए चलाया जा सकता है. मॉड्यूल एक्सटेंशन में, repo rules जैसी सुविधाएं होती हैं. इनकी मदद से, इंटरनेट को ऐक्सेस किया जा सकता है, फ़ाइल I/O किया जा सकता है वगैरह.
यह भी देखें: मॉड्यूल एक्सटेंशन
नेटिव नियम
नियम, Bazel में पहले से मौजूद होते हैं और Java में लागू किए जाते हैं. इस तरह के नियम, .bzl फ़ाइलों में नेटिव मॉड्यूल के फ़ंक्शन के तौर पर दिखते हैं. उदाहरण के लिए, native.cc_library या native.java_library. उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव) Starlark का इस्तेमाल करके बनाए जाते हैं.
आउटपुट बेस
Bazel की आउटपुट फ़ाइलों को सेव करने के लिए, वर्कस्पेस के हिसाब से डायरेक्ट्री. इस कुकी का इस्तेमाल, वर्कस्पेस के सोर्स ट्री (मुख्य repo) से आउटपुट को अलग करने के लिए किया जाता है. यह output user root में मौजूद होता है.
आउटपुट ग्रुप
फ़ाइलों का एक ग्रुप, जिसे Bazel के किसी टारगेट को बनाने के बाद बनाया जाता है. नियम, अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं
(उदाहरण के लिए, cc_library टारगेट के लिए java_library, .a, और .so की .jar फ़ाइल). डिफ़ॉल्ट आउटपुट ग्रुप, वह आउटपुट ग्रुप होता है जिसके आर्टफ़ैक्ट तब बनाए जाते हैं, जब कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है.
नियमों में, नाम वाले ज़्यादा आउटपुट ग्रुप तय किए जा सकते हैं. इन्हें BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन (--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.
उपयोगकर्ता रूट आउटपुट करें
यह उपयोगकर्ता के हिसाब से डायरेक्ट्री होती है. इसका इस्तेमाल Bazel के आउटपुट को सेव करने के लिए किया जाता है. डायरेक्ट्री का नाम, उपयोगकर्ता के सिस्टम के उपयोगकर्ता नाम से लिया जाता है. अगर कई उपयोगकर्ता एक ही समय पर सिस्टम पर एक ही प्रोजेक्ट बना रहे हैं, तो यह विकल्प आउटपुट फ़ाइल के टकराव को रोकता है. इसमें हर वर्कस्पेस के बिल्ड आउटपुट से जुड़ी सबडायरेक्ट्री होती हैं. इन्हें आउटपुट बेस भी कहा जाता है.
पैकेज
BUILD फ़ाइल में तय किए गए टारगेट का सेट. पैकेज का नाम, repo रूट के हिसाब से BUILD फ़ाइल का पाथ होता है. किसी पैकेज में सबपैकेज या BUILD फ़ाइलें शामिल हो सकती हैं. इस तरह, पैकेज का क्रम बनता है.
पैकेज ग्रुप
टारगेट, पैकेज के सेट को दिखाता है. इसका इस्तेमाल अक्सर visibility एट्रिब्यूट की वैल्यू में किया जाता है.
प्लैटफ़ॉर्म
बिल्ड में शामिल "मशीन टाइप". इसमें Bazel को चलाने वाला मशीन ("होस्ट" प्लैटफ़ॉर्म), बिल्ड टूल को चलाने वाली मशीनें ("एक्ज़ेक" प्लैटफ़ॉर्म), और टारगेट के लिए बनाई गई मशीनें ("टारगेट प्लैटफ़ॉर्म") शामिल हैं.
सेवा देने वाली कंपनी
यह एक ऐसा स्कीमा है जो जानकारी की एक यूनिट के बारे में बताता है. इस यूनिट को डिपेंडेंसी के आधार पर, नियमों के टारगेट के बीच पास किया जाता है. आम तौर पर, इसमें कंपाइलर के विकल्प, ट्रांज़िटिव सोर्स या आउटपुट फ़ाइलें, और बिल्ड मेटाडेटा जैसी जानकारी होती है. इसका इस्तेमाल अक्सर depsets के साथ किया जाता है, ताकि ट्रांज़िटिव डेटा को असरदार तरीके से सेव किया जा सके. DefaultInfo, बिल्ट-इन प्रोवाइडर का एक उदाहरण है.
यह भी देखें: सेवा देने वाली कंपनी का दस्तावेज़
क्वेरी (कॉन्सेप्ट)
बिल्ड ग्राफ़ का विश्लेषण करने की प्रोसेस, ताकि टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझा जा सके. Bazel, क्वेरी के तीन वर्शन के साथ काम करता है: query, cquery, और aquery.
क्वेरी (कमांड)
यह एक क्वेरी टूल है. यह बिल्ड के पोस्ट-लोडिंग फ़ेज़ टारगेट ग्राफ़ पर काम करता है. यह प्रोसेस काफ़ी तेज़ होती है. हालांकि, इससे select(), बिल्ड फ़्लैग, आर्टफ़ैक्ट या बिल्ड ऐक्शन के असर का विश्लेषण नहीं किया जा सकता.
यह भी देखें: क्वेरी करने का तरीका, क्वेरी का रेफ़रंस
रिपॉज़िटरी
एक डायरेक्ट्री ट्री, जिसके रूट में बाउंड्री मार्कर फ़ाइल होती है. इसमें ऐसी सोर्स फ़ाइलें होती हैं जिनका इस्तेमाल Bazel बिल्ड में किया जा सकता है. इसे अक्सर छोटा करके सिर्फ़ repo कहा जाता है.
रेपो बाउंड्री मार्कर फ़ाइल, MODULE.bazel (यह बताती है कि यह रेपो, Bazel मॉड्यूल को दिखाता है), REPO.bazel या लेगसी कॉन्टेक्स्ट में, WORKSPACE या WORKSPACE.bazel हो सकती है. किसी भी repo boundary marker फ़ाइल से, repo की सीमा का पता चलेगा. ऐसी कई फ़ाइलें, किसी डायरेक्ट्री में एक साथ मौजूद हो सकती हैं.
मुख्य रेपो वह रेपो होती है जिसमें मौजूदा Bazel कमांड चलाई जा रही है.
बाहरी रेपो को MODULE.bazel फ़ाइलों में मॉड्यूल तय करके या मॉड्यूल एक्सटेंशन में रेपो के नियम लागू करके तय किया जाता है. इन्हें डिस्क पर पहले से तय की गई "मैजिकल" जगह पर, ज़रूरत के हिसाब से फ़ेच किया जा सकता है.
हर रिपॉज़िटरी का एक यूनीक और स्थायी कैननिकल नाम होता है. साथ ही, दूसरी रिपॉज़िटरी से देखने पर, उसके दिखने वाले नाम अलग-अलग हो सकते हैं.
यह भी देखें: बाहरी डिपेंडेंसी के बारे में खास जानकारी
डेटा संग्रह स्थान की कैश मेमोरी
यह एक शेयर की गई, कॉन्टेंट के हिसाब से पता लगाने वाली फ़ाइलों की कैश मेमोरी होती है. इसे Bazel, बिल्ड के लिए डाउनलोड करता है. इसे वर्कस्पेस के बीच शेयर किया जा सकता है. यह शुरुआती डाउनलोड के बाद, ऑफ़लाइन बिल्ड की सुविधा चालू करता है. इसका इस्तेमाल आम तौर पर, repository
rules के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए किया जाता है. जैसे, http_archive और repository rule API, जैसे कि repository_ctx.download. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब डाउनलोड करने के लिए उनके SHA-256 चेकसम दिए गए हों.
रिपॉज़िटरी का नियम
यह रिपॉज़िटरी की परिभाषाओं के लिए स्कीमा है. इससे Bazel को यह पता चलता है कि रिपॉज़िटरी को कैसे तैयार किया जाए या "फ़ेच" किया जाए. इसे अक्सर रेपो नियम कहा जाता है.
Repo नियमों को Bazel, अंदरूनी तौर पर लागू करता है. इससे मॉड्यूल की मदद से बैकअप लिए गए रेपो को तय किया जाता है. इसके अलावा, इन्हें मॉड्यूल एक्सटेंशन भी लागू कर सकते हैं.
Repo के नियमों के तहत, इंटरनेट ऐक्सेस किया जा सकता है या फ़ाइल I/O किया जा सकता है. Repo का सबसे सामान्य नियम http_archive है. इसका इस्तेमाल, इंटरनेट से सोर्स फ़ाइलें शामिल करने वाले संग्रह को डाउनलोड करने के लिए किया जाता है.
यह भी देखें: Repo rule से जुड़े दस्तावेज़
दोहराने की क्षमता
किसी बिल्ड या टेस्ट की ऐसी प्रॉपर्टी जिसमें बिल्ड या टेस्ट के लिए इनपुट का एक सेट, हर बार आउटपुट का एक ही सेट जनरेट करता है. भले ही, समय, तरीका या एनवायरमेंट कुछ भी हो. ध्यान दें कि इसका यह मतलब नहीं है कि आउटपुट सही हैं या आपकी ज़रूरत के मुताबिक हैं.
नियम
BUILD फ़ाइल में नियमों के टारगेट तय करने के लिए स्कीमा, जैसे कि
cc_library. BUILD फ़ाइल के लेखक के हिसाब से, किसी नियम में एट्रिब्यूट का सेट और ब्लैक बॉक्स लॉजिक शामिल होता है. लॉजिक से, नियम के टारगेट को यह पता चलता है कि आउटपुट आर्टफ़ैक्ट कैसे जनरेट करें और अन्य नियम के टारगेट को जानकारी कैसे पास करें. .bzl लेखकों के नज़रिए से, नियम Bazel को नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने के लिए बढ़ाने का मुख्य तरीका है.
लोडिंग फ़ेज़ में, नियमों को इंस्टैंटिएट किया जाता है, ताकि नियम के टारगेट जनरेट किए जा सकें. विश्लेषण के चरण में, नियम के टारगेट, डाउनस्ट्रीम डिपेंडेंसी को प्रोवाइडर के तौर पर जानकारी देते हैं. साथ ही, कार्रवाइयां रजिस्टर करते हैं, जिनसे यह पता चलता है कि आउटपुट आर्टफ़ैक्ट कैसे जनरेट किए जाएं. ये कार्रवाइयां, एक्ज़ीक्यूशन फ़ेज़ में की जाती हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
नियम का टारगेट
ऐसा टारगेट जो किसी नियम का इंस्टेंस हो. यह फ़ाइल टारगेट और पैकेज ग्रुप से अलग होता है. इसे नियम से भ्रमित न हों.
Runfiles
किसी एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, एक्ज़ीक्यूटेबल, टेस्ट के नियम का एक्ज़ीक्यूटेबल आउटपुट होता है. साथ ही, रनफ़ाइलें, टेस्ट की रनटाइम डेटा डिपेंडेंसी होती हैं. Bazel, एक्ज़ीक्यूटेबल को शुरू करने से पहले (bazel test के दौरान), सोर्स डायरेक्ट्री स्ट्रक्चर के मुताबिक टेस्ट एक्ज़ीक्यूटेबल के साथ-साथ रनफ़ाइल का ट्री तैयार करता है.
यह भी देखें: रनफ़ाइल का दस्तावेज़
सैंडबॉक्सिंग
यह एक ऐसी तकनीक है जिससे किसी कार्रवाई को प्रतिबंधित और कुछ समय के लिए एक्ज़ीक्यूशन रूट में अलग किया जाता है. इससे यह पक्का करने में मदद मिलती है कि कार्रवाई, बिना बताए इनपुट न पढ़े या बिना बताए आउटपुट न लिखे. सैंडबॉक्सिंग से हर्मेटिसिटी में काफ़ी सुधार होता है. हालांकि, आम तौर पर इससे परफ़ॉर्मेंस पर असर पड़ता है. साथ ही, इसके लिए ऑपरेटिंग सिस्टम से सहायता की ज़रूरत होती है. परफ़ॉर्मेंस कॉस्ट, प्लैटफ़ॉर्म के हिसाब से तय होती है. Linux पर, इससे कोई खास फ़र्क़ नहीं पड़ता. हालांकि, macOS पर सैंडबॉक्सिंग का इस्तेमाल नहीं किया जा सकता.
Skyframe
Skyframe, Bazel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैल्यूएशन फ़्रेमवर्क है.
छपाई का काम
यह सुविधा, Bazel की मदद से बनाए गए आर्टफ़ैक्ट में अतिरिक्त जानकारी एम्बेड करने के लिए है. उदाहरण के लिए, इसका इस्तेमाल सोर्स कंट्रोल, बिल्ड टाइम, और रिलीज़ बिल्ड के लिए वर्कस्पेस या एनवायरमेंट से जुड़ी अन्य जानकारी के लिए किया जा सकता है.
--workspace_status_command फ़्लैग और स्टैंप एट्रिब्यूट के साथ काम करने वाले नियमों का इस्तेमाल करके, इस सुविधा को चालू करें.
Starlark
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. यह Python का एक सीमित सबसेट है. इसका इस्तेमाल कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के लिए किया जाता है. इसमें सिंटैक्टिक और व्याकरण के नियमों का पालन किया जाता है. .bzl
फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें, Starlark के ज़्यादा पाबंदियों वाले वर्शन का इस्तेमाल करती हैं. जैसे, def फ़ंक्शन की कोई परिभाषा नहीं. इसे पहले Skylark के नाम से जाना जाता था.
यह भी देखें: Starlark भाषा का दस्तावेज़
स्टार्टअप फ़्लैग
bazel और command के बीच तय किए गए फ़्लैग का सेट. उदाहरण के लिए, bazel --host_jvm_debug build. ये फ़्लैग, Bazel सर्वर के कॉन्फ़िगरेशन में बदलाव करते हैं. इसलिए, स्टार्टअप फ़्लैग में किसी भी तरह का बदलाव करने पर, सर्वर रीस्टार्ट हो जाता है. स्टार्टअप फ़्लैग, किसी भी कमांड के लिए खास नहीं होते.
सिंबॉलिक मैक्रो
यह macro का एक फ़्लेवर है. इसे rule जैसे attribute स्कीमा के साथ एलान किया जाता है. इससे, एलान किए गए इंटरनल targets को उनके पैकेज से छिपाया जा सकता है. साथ ही, मैक्रो के एलान किए गए टारगेट पर नाम रखने के एक तय पैटर्न को लागू किया जा सकता है. इसे लेगसी मैक्रो के बड़े कोडबेस में आने वाली कुछ समस्याओं से बचने के लिए डिज़ाइन किया गया है.
यह भी देखें: सिंबॉलिक मैक्रो का दस्तावेज़
टारगेट
यह एक ऐसा ऑब्जेक्ट होता है जिसे BUILD फ़ाइल में तय किया जाता है और जिसकी पहचान label से होती है. टारगेट, असली उपयोगकर्ता के नज़रिए से वर्कस्पेस की ऐसी यूनिट को कहते हैं जिन्हें बनाया जा सकता है.
नियम को इंस्टैंटिएट करके तय किए गए टारगेट को नियम टारगेट कहा जाता है. नियम के हिसाब से, ये रन किए जा सकते हैं (जैसे कि cc_binary) या इनकी जांच की जा सकती है (जैसे कि cc_test). नियम के टारगेट आम तौर पर, एट्रिब्यूट (जैसे कि deps) के ज़रिए अन्य टारगेट पर निर्भर करते हैं. ये निर्भरताएं, टारगेट ग्राफ़ का आधार बनती हैं.
नियम के टारगेट के अलावा, फ़ाइल टारगेट और पैकेज ग्रुप टारगेट भी होते हैं. फ़ाइल टारगेट, आर्टफ़ैक्ट से मेल खाते हैं. ये आर्टफ़ैक्ट, BUILD फ़ाइल में रेफ़रंस के तौर पर इस्तेमाल किए जाते हैं. खास मामले के तौर पर, किसी भी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल टारगेट माना जाता है.
लोडिंग फ़ेज़ के दौरान टारगेट का पता चलता है. विश्लेषण के चरण के दौरान, टारगेट को बिल्ड कॉन्फ़िगरेशन से जोड़ा जाता है, ताकि कॉन्फ़िगर किए गए टारगेट बनाए जा सकें.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. यह कुकी, लोडिंग फ़ेज़ के दौरान जनरेट होती है. इसका इस्तेमाल विश्लेषण फ़ेज़ के इनपुट के तौर पर किया जाता है.
टारगेट पैटर्न
कमांड लाइन पर टारगेट के ग्रुप को तय करने का तरीका. आम तौर पर इस्तेमाल किए जाने वाले पैटर्न ये हैं: :all (नियम के सभी टारगेट), :* (नियम और फ़ाइल के सभी टारगेट), ... (मौजूदा पैकेज और सभी सबपैकेज). इनका एक साथ इस्तेमाल किया जा सकता है. उदाहरण के लिए, //...:* का मतलब है कि वर्कस्पेस के रूट से सभी पैकेज में, सभी नियमों और फ़ाइल टारगेट को बार-बार शामिल किया जाता है.
जांच
नियम टारगेट, जांच के नियमों से इंस्टैंटिएट किए जाते हैं. इसलिए, इनमें जांच के लिए एक्ज़ीक्यूटेबल शामिल होता है. एक्ज़ीक्यूटेबल के पूरा होने पर, शून्य का रिटर्न कोड मिलने का मतलब है कि टेस्ट सफल रहा. Bazel और टेस्ट के बीच कानूनी समझौते (जैसे कि टेस्ट एनवायरमेंट वैरिएबल, टेस्ट के नतीजे इकट्ठा करने के तरीके) के बारे में टेस्ट एनसाइक्लोपीडिया में बताया गया है.
टूलचेन
किसी भाषा के लिए आउटपुट जनरेट करने वाले टूल का सेट. आम तौर पर, टूलचेन में कंपाइलर, लिंकर, इंटरप्रेटर या/और लिंटर शामिल होते हैं. टूलचेन, प्लैटफ़ॉर्म के हिसाब से भी अलग-अलग हो सकती है. इसका मतलब है कि Unix कंपाइलर टूलचेन के कॉम्पोनेंट, Windows वर्शन के लिए अलग-अलग हो सकते हैं. भले ही, टूलचेन एक ही भाषा के लिए हो. प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने की प्रोसेस को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप-लेवल का टारगेट
अगर Bazel कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है, तो उसे टॉप-लेवल का टारगेट माना जाता है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर करता है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए //:foo टॉप-लेवल का है और //:bar टॉप-लेवल का नहीं है. हालांकि, दोनों टारगेट को बिल्ड करना होगा. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच एक अहम अंतर यह है कि Bazel कमांड लाइन पर सेट किए गए कमांड फ़्लैग (या .bazelrc के ज़रिए) टॉप-लेवल टारगेट के लिए कॉन्फ़िगरेशन सेट करेंगे. हालांकि, नॉन-टॉप-लेवल टारगेट के लिए, ट्रांज़िशन से इन्हें बदला जा सकता है.
ट्रांज़िशन
configuration की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. इस विकल्प को चालू करने पर, बिल्ड ग्राफ़ में मौजूद टारगेट के अलग-अलग कॉन्फ़िगरेशन हो सकते हैं. भले ही, उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. ट्रांज़िशन का इस्तेमाल, स्प्लिट ट्रांज़िशन के साथ किया जाता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को अलग-अलग कॉन्फ़िगरेशन के साथ फ़ोर्क किया जाता है. उदाहरण के लिए, एक ही बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल करके, ARM और x86 के लिए कंपाइल किए गए नेटिव बाइनरी के साथ Android APK बनाया जा सकता है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
पेड़ का आर्टफ़ैक्ट
आर्टफ़ैक्ट, फ़ाइलों के कलेक्शन को दिखाता है. ये फ़ाइलें, खुद आर्टफ़ैक्ट नहीं होती हैं. इसलिए, इन पर काम करने वाले ऐक्शन को ट्री आर्टफ़ैक्ट को अपने इनपुट या आउटपुट के तौर पर रजिस्टर करना होगा.
किसको दिखे
बिल्ड सिस्टम में अवांछित डिपेंडेंसी को रोकने के लिए, दो में से एक तरीका:
टारगेट विज़िबिलिटी का इस्तेमाल करके यह कंट्रोल किया जाता है कि अन्य टारगेट, किसी टारगेट पर निर्भर हो सकते हैं या नहीं. वहीं, लोड विज़िबिलिटी का इस्तेमाल करके यह कंट्रोल किया जाता है कि कोई BUILD या .bzl फ़ाइल, किसी दी गई .bzl फ़ाइल को लोड कर सकती है या नहीं. कॉन्टेक्स्ट के बिना, आम तौर पर "दिखने की स्थिति" का मतलब टारगेट दिखने की स्थिति से होता है.
यह भी देखें: 'किसको दिखे' सेटिंग के बारे में जानकारी देने वाला दस्तावेज़
Workspace
सभी Bazel कमांड, एक ही main repository से शेयर किए गए एनवायरमेंट में चलती हैं.
ध्यान दें कि पहले "रिपॉज़िटरी" और "वर्कस्पेस" के कॉन्सेप्ट को एक ही माना जाता था. "वर्कस्पेस" शब्द का इस्तेमाल अक्सर मुख्य रिपॉज़िटरी के लिए किया जाता था. कभी-कभी इसे "रिपॉज़िटरी" के पर्यायवाची के तौर पर भी इस्तेमाल किया जाता था. आसान शब्दों में समझने के लिए, इस तरह के इस्तेमाल से बचना चाहिए.