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