कार्रवाई
बिल्ड के दौरान चलाया जाने वाला निर्देश. उदाहरण के लिए, किसी ऐसे कंपाइलर को कॉल करना जो इनपुट के तौर पर आर्टफ़ैक्ट लेता है और अन्य आर्टफ़ैक्ट को आउटपुट के तौर पर बनाता है. इसमें मेटाडेटा शामिल होता है, जैसे कि कमांड लाइन आर्ग्युमेंट, ऐक्शन बटन, एनवायरमेंट वैरिएबल, और एलान किए गए इनपुट/आउटपुट आर्टफ़ैक्ट.
यह भी देखें: नियमों का दस्तावेज़
ऐक्शन कैश
डिस्क पर मौजूद कैश मेमोरी, जो पूरी की गई कार्रवाइयों और उनके बनाए गए आउटपुट की मैपिंग को सेव करती है. कैश मेमोरी को ऐक्शन बटन के नाम से जाना जाता है. Bazel के इंक्रीमेंटल मॉडल के लिए मुख्य कॉम्पोनेंट. कैश मेमोरी, आउटपुट बेस डायरेक्ट्री में सेव होती है. इसलिए, यह Basel सर्वर के रीस्टार्ट होने पर भी काम करती है.
ऐक्शन ग्राफ़
कार्रवाइयों और ऐसे आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़ जिन्हें पढ़कर और जनरेट किया जाता है. ग्राफ़ में, सोर्स फ़ाइलों के तौर पर मौजूद आर्टफ़ैक्ट (उदाहरण के लिए, फ़ाइल सिस्टम में) के साथ-साथ, जनरेट किए गए ऐसे इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट भी शामिल हो सकते हैं जिनके बारे में BUILD फ़ाइलों में नहीं बताया गया है. विश्लेषण के चरण के दौरान जनरेट किया जाता है और कार्रवाई के चरण के दौरान इस्तेमाल किया जाता है.
ऐक्शन ग्राफ़ क्वेरी (aquery)
क्वेरी टूल, जो बिल्ट इन कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण करने में मदद मिलती है कि बिल्ड नियम कैसे असल काम के बिल्ड में बदलते हैं.
ऐक्शन बटन
किसी कार्रवाई की कैश मेमोरी. यह वैल्यू, ऐक्शन मेटाडेटा के आधार पर कैलकुलेट की जाती है. इसमें ऐक्शन के आधार पर, ऐक्शन में लागू किए जाने वाले निर्देश, कंपाइलर फ़्लैग, लाइब्रेरी की जगहें या सिस्टम हेडर शामिल हो सकते हैं. बेज़ल को अलग-अलग कार्रवाइयों को तय करने के लिए कैश मेमोरी में सेव करने या अमान्य करने में मदद करता है.
विश्लेषण का चरण
बिल्ड का दूसरा चरण. BUILD फ़ाइलों में बताए गए टारगेट ग्राफ़ को प्रोसेस करता है, ताकि इन-मेमोरी ऐक्शन ग्राफ़ बनाया जा सके. यह ग्राफ़, एक्सीक्यूशन फ़ेज़ के दौरान चलने वाली कार्रवाइयों का क्रम तय करता है. इस चरण में नियम के लागू होने का आकलन किया जाता है.
सह-प्रॉडक्ट
सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की डायरेक्ट्री भी हो सकती है, जिसे ट्री आर्टफ़ैक्ट कहा जाता है.
आर्टफ़ैक्ट, एक से ज़्यादा कार्रवाइयों का इनपुट हो सकता है. हालांकि, इसे ज़्यादा से ज़्यादा एक ही कार्रवाई से जनरेट किया जाना चाहिए.
फ़ाइल टारगेट से जुड़े आर्टफ़ैक्ट को लेबल से ऐक्सेस किया जा सकता है.
पक्ष
नियमों के लिए एक ऐसा तरीका जिससे उनकी डिपेंडेंसी में अतिरिक्त कार्रवाइयां बनाई जा सकें. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर है, तो A पर कोई ऐसा पहलू लागू किया जा सकता है जो डिपेंडेंसी के किनारे से B तक ऊपर जाता है. साथ ही, B में अतिरिक्त कार्रवाइयां करता है, ताकि अतिरिक्त आउटपुट फ़ाइलें जनरेट की जा सकें और उन्हें इकट्ठा किया जा सके. इन अतिरिक्त कार्रवाइयों को कैश मेमोरी में सेव किया जाता है और एक ही आसपेक्ट रेशियो की ज़रूरत वाले टारगेट के बीच फिर से इस्तेमाल किया जाता है. इसे
aspect() Starlark Build API फ़ंक्शन की मदद से बनाया गया है. उदाहरण के लिए, इसका इस्तेमाल IDE के लिए मेटाडेटा
जनरेट करने और लिंटिंग के लिए कार्रवाइयां बनाने में किया जा सकता है.
यह भी देखें: अलग-अलग पहलुओं से जुड़ा दस्तावेज़
आसपेक्ट-ऑन-आसपेक्ट
एक कंपोज़िशन तकनीक जिससे पहलुओं को दूसरे पहलुओं के नतीजों पर लागू किया जा सकता है. उदाहरण के लिए, किसी प्रोटो से .java फ़ाइलें जनरेट करने वाले ऐस्पेक्ट के ऊपर, IDEs के इस्तेमाल के लिए जानकारी जनरेट करने वाले ऐस्पेक्ट को लागू किया जा सकता है.
किसी पहलू A को पहलू B के ऊपर लागू करने के लिए, B के provides एट्रिब्यूट में विज्ञापन देने वाले प्रोवाइडर, A के required_aspect_providers एट्रिब्यूट में बताए गए एट्रिब्यूट से मेल खाने चाहिए.
एट्रिब्यूट
नियम का पैरामीटर, जिसका इस्तेमाल हर टारगेट के लिए बिल्ड की जानकारी देने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts, जो टारगेट की सोर्स फ़ाइलों, डिपेंडेंसी, और कस्टम कंपाइलर के विकल्पों के बारे में बताते हैं. किसी टारगेट के लिए उपलब्ध एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
Bazel की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, स्टार्टअप
फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने के लिए किया जाता है. साथ ही, इसकी मदद से विकल्पों के सामान्य ग्रुप तय किए जा सकते हैं. इसके बाद, --config फ़्लैग का इस्तेमाल करके, Bazel कमांड लाइन पर एक साथ सेट किए जा सकते हैं. Bazel, कई bazelrc फ़ाइलों (सिस्टमवाइड, हर वर्कस्पेस के लिए, हर उपयोगकर्ता के लिए या पसंद के मुताबिक जगह से) की सेटिंग को जोड़ सकता है. साथ ही, bazelrc फ़ाइल, अन्य bazelrc फ़ाइलों से सेटिंग इंपोर्ट भी कर सकती है.
Blaze
Basel का Google-आंतरिक वर्शन. Google के मुख्य बिल्ड सिस्टम का इस्तेमाल, एक ही जगह पर मौजूद कई रिपॉज़िटरी के लिए किया जाता है.
फ़ाइल बनाएं
BUILD फ़ाइल मुख्य कॉन्फ़िगरेशन फ़ाइल होती है, जो Basel को बताती है कि कौनसे सॉफ़्टवेयर
आउटपुट बनाने हैं, उनकी डिपेंडेंसी क्या है, और उन्हें कैसे बनाया जा सकता है. Baज़ल, इनपुट के तौर पर BUILD फ़ाइल लेता है और डिपेंडेंसी का ग्राफ़ बनाने के लिए, फ़ाइल का इस्तेमाल करता है. साथ ही, इससे इंटरमीडिएट और फ़ाइनल सॉफ़्टवेयर आउटपुट बनाने के लिए, पूरी की जाने वाली कार्रवाइयों का पता चलता है. BUILD फ़ाइल, डायरेक्ट्री और ऐसी सभी सब-डायरेक्ट्री को पैकेज के तौर पर मार्क करती है जिसमें BUILD फ़ाइल शामिल नहीं होती. साथ ही, इसमें नियमों के ज़रिए बनाए गए टारगेट शामिल हो सकते हैं. फ़ाइल का नाम BUILD.bazel भी हो सकता है.
BUILD.baकोई फ़ाइल
BUILD फ़ाइल देखें. एक ही डायरेक्ट्री में मौजूद BUILD फ़ाइल पर प्राथमिकता दी जाती है.
.bzl फ़ाइल
यह एक ऐसी फ़ाइल है जिसमें Starlark में लिखे गए नियम, मैक्रो, और कॉन्स्टेंट की जानकारी होती है. इसके बाद, load() फ़ंक्शन का इस्तेमाल करके, इन्हें BUILD
फ़ाइलों में इंपोर्ट किया जा सकता है.
ग्राफ़ बनाएं
डिपेंडेंसी ग्राफ़, जिसे Bazel बनाता है और बिल्ड करने के लिए ट्रैवर्स करता है. इसमें टारगेट, कॉन्फ़िगर किए गए टारगेट, ऐक्शन, और आर्टफ़ैक्ट जैसे नोड शामिल होते हैं. किसी बिल्ड को तब पूरा माना जाता है, जब उन सभी आर्टफ़ैक्ट की पुष्टि हो जाती है जिन पर अनुरोध किए गए टारगेट का सेट निर्भर करता है.
बिल्ड की सेटिंग
Starlark से तय किया गया कॉन्फ़िगरेशन. ट्रांज़िशन, किसी सबग्राफ़ के कॉन्फ़िगरेशन को बदलने के लिए, बिल्ड सेटिंग सेट कर सकते हैं. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.
क्लीन बिल्ड
ऐसा बिल्ड जो पिछले बिल्ड के नतीजों का इस्तेमाल नहीं करता. आम तौर पर, यह इंक्रीमेंटल बिल्ड से धीमा होता है, लेकिन आम तौर पर इसे ज़्यादा सही माना जाता है. Basel की गारंटी के साथ, यह साफ़ और इंक्रीमेंटल बिल्ड हमेशा सही होता है.
क्लाइंट-सर्वर मॉडल
bazel कमांड-लाइन क्लाइंट, Bazel कमांड को लागू करने के लिए, स्थानीय मशीन पर बैकग्राउंड सर्वर को अपने-आप शुरू करता है. सर्वर सभी निर्देशों के लिए काम करता है. हालांकि, कुछ समय तक कोई गतिविधि न होने पर या साफ़ तौर पर bazel shutdown का इस्तेमाल करके, यह अपने-आप बंद हो जाता है. Bazel को सर्वर और क्लाइंट में बांटने से, JVM के शुरू होने में लगने वाले समय को कम करने में मदद मिलती है. साथ ही, इंक्रीमेंटल बिल्ड तेज़ी से होते हैं, क्योंकि ऐक्शन ग्राफ़ सभी निर्देशों में मेमोरी में रहता है.
कमांड
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>.
सही जानकारी
कोई बिल्ड तब सही होता है, जब उसका आउटपुट, ट्रांज़िटिव इनपुट की स्थिति को सही तरीके से दिखाता हो. सही बिल्ड हासिल करने के लिए, Basel की कोशिश होती है कि वे हर्मेटिक हों, दोबारा जनरेट कर सकें, और बिल्ड ऐनलिसिस और ऐक्शन को एक्ज़ीक्यूट करना तय करने लगें.
निर्भर है
दो टारगेट के बीच डायरेक्ट किया गया एज. अगर //:foo के एट्रिब्यूट वैल्यू में //:bar का रेफ़रंस शामिल है, तो टारगेट //:foo में टारगेट //:bar पर टारगेट डिपेंडेंसी होती है. अगर //:foo में मौजूद कोई कार्रवाई, //:bar में मौजूद किसी कार्रवाई से बनाए गए इनपुट आर्टफ़ैक्ट पर निर्भर करती है, तो //:foo में //:bar पर कार्रवाई की डिपेंडेंसी होती है.
कुछ मामलों में, इसका मतलब बाहरी डिपेंडेंसी से भी हो सकता है. मॉड्यूल देखें.
Depset
ट्रांज़िटिव डिपेंडेंसी पर डेटा इकट्ठा करने के लिए डेटा स्ट्रक्चर. इसे इस तरह ऑप्टिमाइज़ किया गया है कि डिपसेट मर्ज करने से, समय और जगह की बचत होती है, क्योंकि आम तौर पर बहुत सारे कई सारे डेटा मौजूद होते हैं. जगह की बचत करने की वजहों से, इस तरह के कोड को बार-बार दूसरे डिपार्टमेंट के बारे में बताने के लिए इस्तेमाल किया गया. नियम को लागू करने के लिए, डिप्सेट को सूचियों में बदलकर उन्हें "फ़्लैट" नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि नियम, बिल्ड ग्राफ़ के सबसे ऊपरी लेवल पर न हो. भारी गिरावट की वजह से मेमोरी की बहुत ज़्यादा खपत होती है. बेज़ल के अंदरूनी इस्तेमाल में, इसे नेस्ट किए गए सेट भी कहा जाता है.
यह भी देखें: Depset से जुड़ा दस्तावेज़
डिस्क की कैश मेमोरी
रिमोट कैश मेमोरी की सुविधा के लिए, डिस्क पर मौजूद लोकल ब्लॉब स्टोर. इसका इस्तेमाल, किसी असल रिमोट ब्लॉब स्टोर के साथ किया जा सकता है.
Distdir
एक रीड-ओनली डायरेक्ट्री, जिसमें ऐसी फ़ाइलें होती हैं जिन्हें बेज़ल, रिपॉज़िटरी के नियमों का इस्तेमाल करके इंटरनेट से फ़ेच कर सकते थे. इससे बिल्ड पूरी तरह से ऑफ़लाइन चल पाते हैं.
डाइनैमिक तरीके से लागू करना
एक ऐसी एक्ज़ीक्यूशन रणनीति जो अलग-अलग अनुभव के आधार पर, लोकल और रिमोट एक्ज़ीक्यूशन के बीच चुनाव करती है. साथ ही, इसमें एक्ज़ीक्यूशन के ऐसे नतीजों का इस्तेमाल किया जाता है जो तेज़ी से कामयाब होते हैं. कुछ कार्रवाइयां स्थानीय तौर पर तेज़ी से पूरी की जाती हैं. जैसे, लिंक करना. वहीं, कुछ कार्रवाइयां रिमोट तौर पर तेज़ी से पूरी की जाती हैं. जैसे, एक साथ कई प्रोसेस करने की सुविधा वाला कंपाइलेशन. डाइनैमिक तरीके से लागू करने की रणनीति से, बेहतरीन और साफ़ तरीके से इंक्रीमेंटल और क्लीन बिल्ड का समय मिल सकता है.
लागू करने का फ़ेज़
बिल्ड का तीसरा चरण. विश्लेषण के चरण के दौरान बनाए गए ऐक्शन ग्राफ़ में ऐक्शन को लागू करता है. ये कार्रवाइयां, आर्टफ़ैक्ट को पढ़ने और लिखने के लिए, एक्सीक्यूटेबल (कंपाइलर, स्क्रिप्ट) को शुरू करती हैं. स्पॉन्सर रणनीतियां ये कंट्रोल करती हैं कि इन कार्रवाइयों को कैसे किया जाए: स्थानीय तौर पर, रिमोट तरीके से, डाइनैमिक तरीके से, सैंडबॉक्स की गई, डॉकर की वगैरह.
एक्ज़ीक्यूशन रूट
वर्कस्पेस की आउटपुट बेस डायरेक्ट्री में मौजूद एक डायरेक्ट्री, जहां सैंडबॉक्स किए गए बिल्ड में लोकल ऐक्शन लागू किए जाते हैं. डायरेक्ट्री में मौजूद कॉन्टेंट, ज़्यादातर वर्कस्पेस के इनपुट आर्टफ़ैक्ट के सिंबललिंक होते हैं. एक्ज़ीक्यूशन रूट में, अन्य इनपुट के तौर पर एक्सटर्नल डेटा स्टोर करने की जगहों के सिमलिंक और आउटपुट को सेव करने के लिए bazel-out डायरेक्ट्री शामिल होते हैं. लोडिंग फ़ेज़ के दौरान, डायरेक्ट्री के सिमलिंक फ़ॉरेस्ट बनाए जाते हैं. ये डायरेक्ट्री, उन पैकेज की ट्रांज़िट स्थिति के बारे में बताती हैं जिन पर बिल्ड निर्भर है. कमांड लाइन पर bazel info
execution_root का इस्तेमाल करके ऐक्सेस किया जा सकता है.
फ़ाइल
आर्टफ़ैक्ट देखें.
हर्मेटिकिटी
अगर बिल्ड और टेस्ट ऑपरेशन पर कोई बाहरी असर न हो, तो बिल्ड हर्मेटिक होता है. इससे यह पक्का करने में मदद मिलती है कि नतीजे डिटरमिनिस्टिक और सही हों. उदाहरण के लिए, हर्मेटिक बिल्ड आम तौर पर ऐक्शन को ऐक्सेस करने की अनुमति नहीं देता है, एलान किए गए इनपुट के ऐक्सेस पर पाबंदी लगाता है, तय टाइमस्टैंप और टाइमज़ोन का इस्तेमाल करता है, एनवायरमेंट वैरिएबल के ऐक्सेस पर पाबंदी लगाता है, और रैंडम नंबर जनरेटर के लिए तय सीड का इस्तेमाल करता है
इंक्रीमेंटल बिल्ड
बिल्ड में लगने वाले समय और रिसॉर्स के इस्तेमाल को कम करने के लिए, इंक्रीमेंटल बिल्ड पिछले बिल्ड के नतीजों का फिर से इस्तेमाल करता है. डिपेंडेंसी की जांच करने और कैश मेमोरी में डेटा सेव करने का मकसद, इस तरह के बिल्ड के लिए सही नतीजे देना है. इंक्रीमेंटल बिल्ड, क्लीन बिल्ड से बिलकुल उलट होता है.
लेबल
टारगेट के लिए आइडेंटिफ़ायर. आम तौर पर, @repo//path/to/package:target फ़ॉर्म होता है. इसमें repo, टारगेट वाली डेटा स्टोर करने की जगह का पाथ होता है. path/to/package उस डायरेक्ट्री का पाथ होता है जिसमें टारगेट के बारे में जानकारी देने वाली BUILD फ़ाइल होती है (इस डायरेक्ट्री को पैकेज भी कहा जाता है) और target टारगेट का नाम होता है. स्थिति के आधार पर, इस
सिंटैक्स के कुछ हिस्सों को हटाया जा सकता है.
यह भी देखें: लेबल
लोड होने का चरण
बिल्ड का पहला चरण, जिसमें पैकेज बनाने के लिए, Bazel BUILD फ़ाइलों को लागू करता है. इस चरण में, मैक्रो और glob() जैसे कुछ फ़ंक्शन का आकलन किया जाता है. टारगेट ग्राफ़ बनाने के लिए, बिल्ड के दूसरे फ़ेज़ यानी विश्लेषण का फ़ेज़ में शामिल किया गया.
मैक्रो
किसी एक Starlark फ़ंक्शन के तहत, टारगेट के लिए कई नियम बनाने का तरीका. BUILD फ़ाइलों में, नियम के एलान के सामान्य पैटर्न का फिर से इस्तेमाल करने की सुविधा देता है. लोड करने के चरण के दौरान, नियम के टारगेट से जुड़ी सूचनाओं तक बढ़ाया गया.
यह भी देखें: मैक्रो दस्तावेज़
Mnemonic
नियम बनाने वाले व्यक्ति की चुनी हुई एक छोटी स्ट्रिंग, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इससे यह तुरंत समझा जा सकता है कि नियम में मौजूद कार्रवाई क्या कर रही है. याद रखने का तरीका स्पॉन्सर रणनीति चुनने के लिए आइडेंटिफ़ायर के तौर पर इस्तेमाल किया जा सकता है. कार्रवाई याद रखने की तकनीक के कुछ उदाहरण
Java के नियमों से Javac, C++ के नियमों से CppCompile, और Android के नियमों से AndroidManifestMerger हैं.
मॉड्यूल
एक Basel प्रोजेक्ट जिसमें कई वर्शन हो सकते हैं और हर एक वर्शन दूसरे मॉड्यूल पर निर्भर हो सकता है. यह दूसरे डिपेंडेंसी मैनेजमेंट सिस्टम के जाने-पहचाने कॉन्सेप्ट से मिलता-जुलता है. जैसे, Maven आर्टफ़ैक्ट, एनपीएम पैकेज, Go मॉड्यूल या कार्गो क्रेट. मॉड्यूल, Bazel के बाहरी डिपेंडेंसी मैनेजमेंट सिस्टम का मुख्य हिस्सा होते हैं.
हर मॉड्यूल के लिए एक रेपो का इस्तेमाल होता है, जिसके रूट में MODULE.bazel फ़ाइल होती है. इस फ़ाइल में, मॉड्यूल के बारे में मेटाडेटा (जैसे, उसका नाम और वर्शन), उसकी डायरेक्ट डिपेंडेंसी, और टूलचेन रजिस्टरेशन और मॉड्यूल एक्सटेंशन इनपुट जैसे कई अन्य डेटा शामिल होते हैं.
मॉड्यूल मेटाडेटा, Basel रजिस्ट्रियों में होस्ट किया गया है.
यह भी देखें: Bazel मॉड्यूल
मॉड्यूल एक्सटेंशन
यह एक लॉजिक है, जिसे रिपॉज़िटरी जनरेट करने के लिए चलाया जा सकता है. इसके लिए, मॉड्यूल के डिपेंडेंसी ग्राफ़ से इनपुट पढ़े जाते हैं और रिपॉज़िटरी के नियम लागू किए जाते हैं. मॉड्यूल एक्सटेंशन में, repo के नियमों जैसी सुविधाएं होती हैं. इनकी मदद से, इंटरनेट को ऐक्सेस किया जा सकता है, फ़ाइल I/O किया जा सकता है वगैरह.
यह भी देखें: मॉड्यूल एक्सटेंशन
निजी नियम
ऐसे नियम जो Basel में बनाए गए हैं और 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" प्लैटफ़ॉर्म) पर चलने वाले टूल, और मशीन के टारगेट ("टारगेट प्लैटफ़ॉर्म") के लिए बनाए गए टूल शामिल हैं.
सेवा देने वाली कंपनी
यह एक स्कीमा है, जिसमें जानकारी की एक इकाई के बारे में बताया गया है. इस इकाई को डिपेंडेंसी रिलेशनशिप के साथ, नियम के टारगेट के बीच पास किया जाता है. आम तौर पर, इसमें कंपाइलर विकल्प, ट्रांज़िटिव सोर्स या आउटपुट फ़ाइलें, और बिल्ड मेटाडेटा जैसी जानकारी होती है. इकट्ठा किए गए ट्रांज़िटिव डेटा को बेहतर तरीके से सेव करने के लिए, इसे अक्सर डिपसेट के साथ इस्तेमाल किया जाता है. पहले से मौजूद, सेवा देने वाली कंपनियों का एक उदाहरण DefaultInfo है.
यह भी देखें: सेवा देने वाली कंपनी का दस्तावेज़
क्वेरी (सिद्धांत)
टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझने के लिए, बिल्ड ग्राफ़ का विश्लेषण करने की प्रोसेस. Bazel में क्वेरी के तीन वैरिएंट इस्तेमाल किए जा सकते हैं: query, cquery, और aquery.
क्वेरी (कमांड)
एक क्वेरी टूल, जो बिल्ड के लोड होने के बाद के चरण टारगेट ग्राफ़ पर काम करता है. यह प्रोसेस तेज़ी से काम करती है. हालांकि, इसके ज़रिए select(), फ़्लैग बनाने, आर्टफ़ैक्ट बनाने या कार्रवाइयां बनाने के असर का विश्लेषण नहीं किया जा सकता.
यह भी देखें: क्वेरी का तरीका, क्वेरी का रेफ़रंस
रिपॉज़िटरी
रूट में बाउंड्री मार्कर फ़ाइल वाला डायरेक्ट्री ट्री, जिसमें ऐसी सोर्स फ़ाइलें होती हैं जिनका इस्तेमाल Bazel बिल्ड में किया जा सकता है. इसे अक्सर repo के तौर पर छोटा किया जाता है.
रेपो बाउंड्री मार्कर की फ़ाइल, MODULE.bazel हो सकती है. इससे पता चलता है कि यह रेपो, Baze मॉड्यूल को दिखाता है. REPO.bazel या लेगसी कॉन्टेक्स्ट में, WORKSPACE या WORKSPACE.bazel भी हो सकता है. कोई भी रेपो बाउंड्री मार्कर फ़ाइल, रेपो की सीमा दिखाती है. इस तरह की कई फ़ाइलें, एक डायरेक्ट्री में एक साथ मौजूद हो सकती हैं.
मुख्य रेपो, वह रेपो होता है जिसमें मौजूदा बेज़ल कमांड चलाया जा रहा होता है.
एक्सटर्नल रिपो को MODULE.bazel फ़ाइलों में मॉड्यूल तय करके या मॉड्यूल एक्सटेंशन में रेपो के नियमों को लागू करके तय किया जाता है. इन्हें डिस्क पर पहले से तय की गई "जादुई" जगह पर मांग पर फ़ेच किया जा सकता है.
हर रेपो का एक खास और लगातार कैननिकल नाम होता है. साथ ही, दूसरे डेटा स्टोर से देखने पर एक अलग पैरंट नाम होता है.
यह भी देखें: बाहरी डिपेंडेंसी के बारे में खास जानकारी
डेटा स्टोर करने की जगह की कैश मेमोरी
यह, कॉन्टेंट के पते के हिसाब से कैश मेमोरी होती है. इसमें, Bazel के ज़रिए बिल्ड के लिए डाउनलोड की गई फ़ाइलें होती हैं. इन्हें वर्कस्पेस में शेयर किया जा सकता है. शुरुआती डाउनलोड के बाद, ऑफ़लाइन बिल्ड की सुविधा चालू करता है. आम तौर पर, इसका इस्तेमाल http_archive जैसे डेटा स्टोर करने की जगहों के नियमों और रिपॉज़िटरी नियम एपीआई जैसे repository_ctx.download के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए किया जाता है. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब उनके SHA-256 चेकसम
डाउनलोड के लिए तय किए गए हों.
रिपॉज़िटरी का नियम
रिपॉज़िटरी डेफ़िनिशन के लिए स्कीमा, जो Bazel को रिपॉज़िटरी को मैटीरियलाइज़ (या "फ़ेच") करने का तरीका बताता है. इसे अक्सर रिपो नियम कहा जाता है.
Repo के नियमों को Basel ने अंदरूनी तौर पर शुरू किया है, ताकि मॉड्यूल पर आधारित रेपो तय किए जा सकें. इसके अलावा, मॉड्यूल एक्सटेंशन की मदद से भी रेपो को शुरू करने की सुविधा इस्तेमाल की जा सकती है.
रिपॉज़िटरी के नियम, इंटरनेट को ऐक्सेस कर सकते हैं या फ़ाइल I/O कर सकते हैं. रिपॉज़िटरी का सबसे सामान्य नियम, इंटरनेट से सोर्स फ़ाइलों वाला संग्रह डाउनलोड करने के लिए http_archive है.
यह भी देखें: रिपो के नियमों का दस्तावेज़
फिर से बनाया जा सकने वाला
बिल्ड या टेस्ट की ऐसी प्रॉपर्टी जिसे बनाने या टेस्ट करने के लिए इनपुट का एक सेट, हर बार आउटपुट का एक ही सेट देगा. भले ही, समय, तरीका या एनवायरमेंट कुछ भी हो. ध्यान दें कि इसका यह मतलब नहीं है कि आउटपुट सही हैं या वे आपके काम के हैं.
नियम
BUILD फ़ाइल में नियम के टारगेट तय करने के लिए स्कीमा, जैसे कि
cc_library. BUILD फ़ाइल के लेखक के हिसाब से, नियम में एट्रिब्यूट का एक सेट और ब्लैक बॉक्स लॉजिक शामिल होता है. लॉजिक, नियम के टारगेट को बताता है कि आउटपुट आर्टफ़ैक्ट कैसे बनाएं और अन्य नियम के टारगेट को जानकारी कैसे दें. .bzl के लेखकों के हिसाब से, नियम नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने के लिए, Basel का इस्तेमाल करने का मुख्य तरीका हैं.
लोडिंग के चरण में, नियम के टारगेट बनाने के लिए नियम इंस्टैंशिएट हो जाते हैं. विश्लेषण फ़ेज़ में नियम टारगेट, अपनी डाउनस्ट्रीम डिपेंडेंसी को सेवा देने वालों के रूप में जानकारी देते हैं और उन कार्रवाइयों को रजिस्टर करते हैं जो आउटपुट आर्टफ़ैक्ट जनरेट करने का तरीका बताते हैं. ये कार्रवाइयां कार्रवाई करने के चरण में की जाती हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
नियम का टारगेट
ऐसा टारगेट जो किसी नियम का इंस्टेंस है. फ़ाइल टारगेट और पैकेज ग्रुप के मुकाबले, यह अलग होता है. इसे नियम से न जोड़ें.
रनफ़ाइल
किसी एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, रनफ़ाइलें, जांच के रनटाइम डेटा की डिपेंडेंसी होती हैं और रनफ़ाइलें, जांच के नियम का रनटाइम आउटपुट होती हैं. बज़ल टेस्ट के दौरान, प्रोग्राम को शुरू करने से पहले Bazel, सोर्स डायरेक्ट्री के स्ट्रक्चर के हिसाब से, टेस्ट प्रोग्राम के साथ-साथ रनफ़ाइलों का ट्री तैयार करता है.
यह भी देखें: रनफ़ाइलों का दस्तावेज़
सैंडबॉक्सिंग
यह तकनीक, सीमित और कुछ समय के लिए लागू एक्ज़िक्यूशन रूट में चल रही कार्रवाई को अलग करने की तकनीक है. इससे यह पक्का करने में मदद मिलती है कि यह बिना एलान वाले इनपुट या ऐसे आउटपुट नहीं लिखेगा जिनका एलान नहीं किया गया है. सैंडबॉक्सिंग से हर्मेटिकिटी काफ़ी बेहतर हो जाती है. हालांकि, आम तौर पर इसमें परफ़ॉर्मेंस की लागत आती है और इसके लिए ऑपरेटिंग सिस्टम से मदद की ज़रूरत होती है. परफ़ॉर्मेंस की लागत, प्लैटफ़ॉर्म के हिसाब से तय होती है. Linux पर, यह अहम नहीं है, लेकिन macOS पर इससे सैंडबॉक्सिंग काम नहीं कर सकती.
Skyframe
Skyframe, Basel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैलुएशन फ़्रेमवर्क है.
छपाई का काम
Bazel से बनाए गए आर्टफ़ैक्ट में ज़्यादा जानकारी जोड़ने की सुविधा. उदाहरण के लिए, इसका इस्तेमाल सोर्स कंट्रोल, बिल्ड टाइम, और अन्य फ़ाइल फ़ोल्डर या रिलीज़ बिल्ड के लिए एनवायरमेंट से जुड़ी जानकारी देने के लिए किया जा सकता है.
स्टैंप एट्रिब्यूट के साथ काम करने वाले --workspace_status_command फ़्लैग और नियमों की मदद से चालू करें.
Starlark
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. Python का सीमित सबसेट (वाक्य और व्याकरण के हिसाब से), जिसे कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के लिए बनाया गया है. .bzl फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें, Starlark के ज़्यादा पाबंदी वाले वर्शन का इस्तेमाल करती हैं. जैसे, def फ़ंक्शन की परिभाषाएं नहीं. इसे पहले Skylark कहा जाता था.
यह भी देखें: Starlark भाषा का दस्तावेज़
स्टार्टअप फ़्लैग
bazel और कमांड के बीच दिए गए फ़्लैग का सेट. उदाहरण के लिए, bazel --host_jvm_debug build. ये फ़्लैग, Basel सर्वर के कॉन्फ़िगरेशन में बदलाव करते हैं. इसलिए, स्टार्टअप फ़्लैग में कोई भी बदलाव करने पर, सर्वर रीस्टार्ट होता है. स्टार्टअप फ़्लैग किसी भी निर्देश के लिए खास नहीं होते हैं.
टारगेट
यह ऐसा ऑब्जेक्ट है जिसे BUILD फ़ाइल में तय किया गया है और लेबल से पहचाना गया है. टारगेट, असली उपयोगकर्ता के नज़रिए से, वर्कस्पेस की ऐसी यूनिट दिखाते हैं जिन्हें बनाया जा सकता है.
नियम को इंस्टैंशिएट करके बताए गए टारगेट को नियम टारगेट कहा जाता है. नियम के आधार पर, ये टारगेट cc_binary की तरह चलाए जा सकते हैं या cc_test की तरह जांचे जा सकते हैं. आम तौर पर, नियम के टारगेट अपने एट्रिब्यूट (जैसे, deps) के ज़रिए दूसरे टारगेट पर निर्भर होते हैं. ये डिपेंडेंसी, टारगेट ग्राफ़ का आधार होती हैं.
नियम के टारगेट के अलावा, इसमें फ़ाइल टारगेट और पैकेज ग्रुप के टारगेट भी होते हैं. फ़ाइल टारगेट उन आर्टफ़ैक्ट से जुड़े हैं जिनका रेफ़रंस BUILD फ़ाइल में दिया गया है. खास मामले में, किसी भी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल का टारगेट माना जाता है.
टारगेट, लोडिंग फ़ेज़ के दौरान खोजे जाते हैं. विश्लेषण के चरण के दौरान, कॉन्फ़िगर किए गए टारगेट बनाने के लिए, टारगेट बिल्ड कॉन्फ़िगरेशन से जुड़े होते हैं.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. इन्हें लोड करने के चरण के दौरान बनाया जाता है. साथ ही, इसे विश्लेषण के चरण के लिए इनपुट के तौर पर इस्तेमाल किया जाता है.
टारगेट पैटर्न
कमांड लाइन पर टारगेट का ग्रुप तय करने का तरीका. आम तौर पर,
इस्तेमाल होने वाले पैटर्न :all (सभी नियम टारगेट), :* (सभी नियम + फ़ाइल टारगेट),
... (मौजूदा पैकेज और बार-बार होने वाले सभी सबपैकेज हैं). इनका इस्तेमाल एक साथ किया जा सकता है. उदाहरण के लिए, //...:* का मतलब है कि वर्कस्पेस के रूट से, सभी पैकेज में मौजूद सभी नियम और फ़ाइल टारगेट को बार-बार लागू किया जाएगा.
जांच
नियम टारगेट, टेस्ट नियमों से इंस्टैंशिएट किए जाते हैं. इसलिए, इनमें टेस्ट को लागू करने वाला कोड होता है. एक्ज़ीक्यूटेबल के पूरा होने के बाद शून्य का रिटर्न कोड, टेस्ट की सफलता को दिखाता है. बेज़ल और टेस्ट के बीच का सटीक अनुबंध (जैसे कि टेस्ट एनवायरमेंट वैरिएबल, टेस्ट नतीजे इकट्ठा करने के तरीके) टेस्ट एन्साइक्लोपीडिया में बताया गया है.
टूलचेन
किसी भाषा के लिए आउटपुट बनाने के टूल का सेट. आम तौर पर, टूलचेन में कंपाइलर, लिंकर, इंटरप्रेटर या/और लिंटर शामिल होते हैं. टूलचेन में प्लैटफ़ॉर्म के हिसाब से भी फ़र्क़ हो सकता है. इसका मतलब है कि Windows के वैरिएंट के लिए, Unix कंपाइलर टूलचेन के कॉम्पोनेंट अलग-अलग हो सकते हैं. भले ही, टूलचेन एक ही भाषा के लिए हो. प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप लेवल टारगेट
अगर बिल्ड टारगेट का अनुरोध बेज़ल कमांड लाइन पर किया जाता है, तो वह टॉप-लेवल होता है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर करता है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए, //:foo टॉप-लेवल है और //:bar टॉप-लेवल नहीं है. हालांकि, दोनों टारगेट को बिल्ड करना होगा. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच एक अहम अंतर यह है कि Bazel कमांड लाइन पर सेट किए गए कमांड फ़्लैग (या .bazelrc के ज़रिए), टॉप-लेवल टारगेट के लिए कॉन्फ़िगरेशन सेट करेंगे. हालांकि, नॉन-टॉप-लेवल टारगेट के लिए, ट्रांज़िशन की मदद से इनमें बदलाव किया जा सकता है.
ट्रांज़िशन
कॉन्फ़िगरेशन की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. बिल्ड ग्राफ़ में टारगेट को अलग-अलग कॉन्फ़िगरेशन के लिए चालू करता है, भले ही उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. आम तौर पर, ट्रांज़िशन का इस्तेमाल स्प्लिट ट्रांज़िशन के साथ किया जाता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को हर फ़ोर्क के लिए अलग-अलग कॉन्फ़िगरेशन के साथ फ़ोर्क किया जाता है. उदाहरण के लिए, किसी एक बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल करके ARM और x86 के लिए कंपाइल किए गए नेटिव बाइनरी वाला Android APK बनाया जा सकता है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
पेड़ का आर्टफ़ैक्ट
एक आर्टफ़ैक्ट, जो फ़ाइलों का कलेक्शन दिखाता है. ये फ़ाइलें खुद आर्टफ़ैक्ट नहीं होतीं. इसलिए, इन पर काम करने वाली कार्रवाई को ट्री आर्टफ़ैक्ट को अपने इनपुट या आउटपुट के तौर पर रजिस्टर करना होगा.
किसको दिखे
बिल्ड सिस्टम में अनचाही डिपेंडेंसी को रोकने के लिए, दो में से कोई एक तरीका अपनाया जा सकता है: टारगेट की विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि किसी टारगेट पर दूसरे टारगेट डिपेंड कर सकते हैं या नहीं; और लोड की विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि कोई BUILD या .bzl फ़ाइल, किसी .bzl फ़ाइल को लोड कर सकती है या नहीं. संदर्भ के बिना, आम तौर पर
"विज़िबिलिटी" का मतलब, 'किसको दिखे' सेटिंग से है.
यह भी देखें: 'किसको दिखे' सेटिंग के बारे में दस्तावेज़
Workspace
Bazel के सभी कमांड के साथ शेयर किया गया एनवायरमेंट, एक ही मुख्य रिपॉज़िटरी से चलता है.
ध्यान दें कि ऐतिहासिक तौर पर, "डेटा स्टोर करने की जगह" और "वर्कस्पेस" के सिद्धांतों का एक साथ इस्तेमाल किया जाता रहा है. अक्सर "वर्कस्पेस" शब्द का इस्तेमाल, मुख्य डेटा स्टोर करने की जगह के बारे में बताने के लिए किया जाता है. कभी-कभी इसका इस्तेमाल "डेटा स्टोर करने की जगह" के समानार्थी के तौर पर भी किया जाता है. साफ़ तौर पर बताने के लिए, इस तरह के इस्तेमाल से बचना चाहिए.