बेज़ेल ग्लॉसरी

कार्रवाई

बिल्ड के दौरान चलाने के लिए कोई कमांड. उदाहरण के लिए, कंपाइलर को कॉल करना. यह artifacts को इनपुट के तौर पर लेता है और अन्य आर्टफ़ैक्ट को आउटपुट के तौर पर जनरेट करता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन की, एनवायरमेंट वैरिएबल, और एलान किए गए इनपुट/आउटपुट आर्टफ़ैक्ट जैसे मेटाडेटा शामिल होते हैं.

यह भी देखें: नियमों से जुड़ा दस्तावेज़

ऐक्शन कैश

यह डिस्क पर मौजूद एक कैश मेमोरी होती है. इसमें, पूरी की गई कार्रवाइयों को उनके बनाए गए आउटपुट से मैप करने की जानकारी सेव होती है. कैश मेमोरी की कुकी को ऐक्शन कुकी कहा जाता है. Bazel के इंक्रीमेंटैलिटी मॉडल के लिए एक मुख्य कॉम्पोनेंट. कैश को आउटपुट बेस डायरेक्ट्री में सेव किया जाता है. इसलिए, Bazel सर्वर को फिर से चालू करने पर भी यह मौजूद रहती है.

ऐक्शन ग्राफ़

यह कार्रवाइयों और उन आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़ होता है जिन्हें ये कार्रवाइयां पढ़ती हैं और जनरेट करती हैं. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो सोर्स फ़ाइलों के तौर पर मौजूद हैं. उदाहरण के लिए, फ़ाइल सिस्टम में. साथ ही, इसमें जनरेट किए गए इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनका ज़िक्र BUILD फ़ाइलों में नहीं किया गया है. इन्हें विश्लेषण के चरण के दौरान बनाया जाता है और लागू करने के चरण के दौरान इस्तेमाल किया जाता है.

ऐक्शन ग्राफ़ क्वेरी (aquery)

यह एक क्वेरी टूल है, जो बिल्ड कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण किया जा सकता है कि बिल्ड के नियम, असल में बिल्ड के काम में कैसे बदलते हैं.

ऐक्शन बटन

किसी कार्रवाई की कैश मेमोरी की कुंजी. यह कार्रवाई के मेटाडेटा के आधार पर कैलकुलेट किया जाता है. इसमें कार्रवाई में लागू की जाने वाली कमांड, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. यह कार्रवाई के हिसाब से तय होता है. इस कुकी की मदद से, Bazel अलग-अलग कार्रवाइयों को कैश मेमोरी में सेव कर पाता है या उन्हें अमान्य कर पाता है.

विश्लेषण का फ़ेज़

बिल्ड का दूसरा फ़ेज़. यह BUILD फ़ाइलों में बताए गए टारगेट ग्राफ़ को प्रोसेस करता है, ताकि मेमोरी में मौजूद ऐक्शन ग्राफ़ बनाया जा सके. इससे यह तय होता है कि एक्ज़ीक्यूशन फ़ेज़ के दौरान, कार्रवाइयों को किस क्रम में चलाया जाएगा. इस फ़ेज़ में, नियमों को लागू करने का आकलन किया जाता है.

सह-प्रॉडक्ट

सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है. इसे ट्री आर्टफ़ैक्ट कहा जाता है.

कोई आर्टफ़ैक्ट, कई कार्रवाइयों के लिए इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक कार्रवाई से जनरेट किया जाना चाहिए.

फ़ाइल टारगेट से जुड़े किसी आर्टफ़ैक्ट को लेबल किया जा सकता है.

पक्ष

नियमों के लिए एक ऐसा तरीका जिससे वे अपनी डिपेंडेंसी में अतिरिक्त कार्रवाइयां कर सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर करता है, तो A पर एक ऐसा पहलू लागू किया जा सकता है जो निर्भरता वाले एज को ऊपर की ओर ले जाता है. साथ ही, अतिरिक्त आउटपुट फ़ाइलें जनरेट और इकट्ठा करने के लिए, B में अतिरिक्त कार्रवाइयां करता है. ये अतिरिक्त कार्रवाइयां कैश मेमोरी में सेव की जाती हैं. साथ ही, इनका इस्तेमाल उन टारगेट के बीच फिर से किया जाता है जिनके लिए एक ही पहलू की ज़रूरत होती है. इसे aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. इसका इस्तेमाल, उदाहरण के लिए, आईडीई के लिए मेटाडेटा जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने के लिए किया जा सकता है.

यह भी देखें: पहलू से जुड़े दस्तावेज़

आसपेक्ट-ऑन-आसपेक्ट

यह एक कंपोज़िशन मैकेनिज़्म है, जिसकी मदद से किसी पहलू के नतीजों पर दूसरे पहलू लागू किए जा सकते हैं. उदाहरण के लिए, आईडीई के इस्तेमाल के लिए जानकारी जनरेट करने वाले पहलू को, प्रोटो से .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 में तय किया गया कॉन्फ़िगरेशन होता है. ट्रांज़िशन, बिल्ड सेटिंग सेट कर सकते हैं, ताकि सबग्राफ़ के कॉन्फ़िगरेशन में बदलाव किया जा सके. अगर इसे उपयोगकर्ता के लिए कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.

क्लीन बिल्ड

ऐसी बिल्ड जो पिछली बिल्ड के नतीजों का इस्तेमाल नहीं करती. यह आम तौर पर, इंक्रीमेंटल बिल्ड से ज़्यादा समय लेता है. हालांकि, इसे आम तौर पर ज़्यादा सही माना जाता है. 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

ट्रांज़िटिव डिपेंडेंसी पर डेटा इकट्ठा करने के लिए डेटा स्ट्रक्चर. इसे इस तरह से ऑप्टिमाइज़ किया गया है कि डिपसेट को मर्ज करने में कम समय लगे और कम जगह इस्तेमाल हो. ऐसा इसलिए, क्योंकि बहुत बड़े डिपसेट (लाखों फ़ाइलें) होना आम बात है. इसे इसलिए लागू किया गया है, ताकि स्पेस को बेहतर तरीके से इस्तेमाल करने के लिए, अन्य डिपसेट को बार-बार रेफ़र किया जा सके. नियम लागू करने के दौरान, डिपसेट को सूचियों में बदलकर उन्हें "फ़्लैट" नहीं किया जाना चाहिए. हालांकि, ऐसा तब किया जा सकता है, जब नियम बिल्ड ग्राफ़ के सबसे ऊपर मौजूद हो. बड़े डिप्सेट को फ़्लैट करने पर, बहुत ज़्यादा मेमोरी खर्च होती है. 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 की आउटपुट फ़ाइलों को सेव करने के लिए, वर्कस्पेस के हिसाब से डायरेक्ट्री. इस कुकी का इस्तेमाल, वर्कस्पेस के सोर्स ट्री (मुख्य रिपो) से आउटपुट को अलग करने के लिए किया जाता है. यह output user root में मौजूद होता है.

आउटपुट ग्रुप

फ़ाइलों का एक ग्रुप, जिसे Bazel के किसी टारगेट को बनाने के बाद बनाया जाता है. नियम, अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं (उदाहरण के लिए, java_library की .jar फ़ाइल, cc_library टारगेट के लिए .a और .so). डिफ़ॉल्ट आउटपुट ग्रुप, वह आउटपुट ग्रुप होता है जिसके आर्टफ़ैक्ट तब बनाए जाते हैं, जब कमांड लाइन पर किसी टारगेट का अनुरोध किया जाता है. नियमों में, नाम वाले ज़्यादा आउटपुट ग्रुप तय किए जा सकते हैं. इन्हें 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 से चलाए जाते हैं.

ध्यान दें कि पहले "रिपॉज़िटरी" और "वर्कस्पेस" के कॉन्सेप्ट को एक ही माना जाता था. "वर्कस्पेस" शब्द का इस्तेमाल अक्सर मुख्य रिपॉज़िटरी के लिए किया जाता था. कभी-कभी इसे "रिपॉज़िटरी" के पर्यायवाची के तौर पर भी इस्तेमाल किया जाता था. आसान शब्दों में समझने के लिए, इस तरह के इस्तेमाल से बचना चाहिए.