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

समस्या की शिकायत करें सोर्स देखें

ऐक्शन

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

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

ऐक्शन कैश

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

ऐक्शन ग्राफ़

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

कार्रवाई ग्राफ़ क्वेरी (क्वेरी)

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

कार्रवाई कुंजी

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

विश्लेषण का चरण

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

सह-प्रॉडक्ट

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

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

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

आसपेक्ट

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

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

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

एक कंपोज़िशन तकनीक जिससे पहलुओं को दूसरे पहलुओं के नतीजों पर लागू किया जा सकता है. उदाहरण के लिए, आईडीई के इस्तेमाल के लिए जानकारी जनरेट करने वाला पहलू, उस पहलू के ऊपर लागू किया जा सकता है जो प्रोटो से .java फ़ाइलें जनरेट करता है.

B आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) A के ऊपर लागू करने के लिए, जो सेवा देने वाली कंपनियां B अपनी provides एट्रिब्यूट में विज्ञापन देती हैं उन्हें A अपने required_aspect_providers एट्रिब्यूट में दिए गए एलान से मेल खाना चाहिए.

एट्रिब्यूट

नियम के लिए पैरामीटर, जिसका इस्तेमाल हर टारगेट बिल्ड की जानकारी दिखाने के लिए किया जाता है. उदाहरणों में srcs, deps, और copts शामिल हैं. ये टारगेट की सोर्स फ़ाइलों, डिपेंडेंसी, और कस्टम कंपाइलर के विकल्पों का एलान करते हैं. किसी टारगेट के लिए उपलब्ध एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.

.baज़ेनrc

Baज़ल की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल, स्टार्टअप फ़्लैग और कमांड फ़्लैग की डिफ़ॉल्ट वैल्यू बदलने और विकल्पों के सामान्य ग्रुप को तय करने के लिए किया जाता है. इसके बाद, --config फ़्लैग का इस्तेमाल करके, बेज़ल कमांड लाइन पर एक साथ सेट किया जा सकता है. Baज़ल, अलग-अलग baselrc फ़ाइलों से सेटिंग को एक साथ मिला सकता है (systemwide, per-workspace, हर-उपयोगकर्ता के हिसाब से या पसंद के मुताबिक बनाई गई जगह से) और bazelrc फ़ाइल, अन्य bazelrc फ़ाइलों से सेटिंग इंपोर्ट कर सकती है.

Blaze

Basel का Google-आंतरिक वर्शन. Google के मोनो रिपॉज़िटरी के लिए मुख्य बिल्ड सिस्टम है.

फ़ाइल बनाएं

BUILD फ़ाइल मुख्य कॉन्फ़िगरेशन फ़ाइल होती है, जो Basel को बताती है कि कौनसे सॉफ़्टवेयर आउटपुट बनाए जाने हैं, उनकी डिपेंडेंसी क्या है, और उन्हें कैसे बनाया जा सकता है. Baज़ल, इनपुट के तौर पर BUILD फ़ाइल लेता है और डिपेंडेंसी का ग्राफ़ बनाने के लिए, इस फ़ाइल का इस्तेमाल करता है. साथ ही, इससे इंटरमीडिएट और फ़ाइनल सॉफ़्टवेयर आउटपुट बनाने के लिए, पूरी की जाने वाली कार्रवाइयों का पता चलता है. BUILD फ़ाइल, किसी डायरेक्ट्री और ऐसी सब-डायरेक्ट्री को मार्क करती है जिसमें BUILD फ़ाइल, पैकेज के तौर पर शामिल नहीं है. साथ ही, इसमें नियमों के ज़रिए बनाए गए टारगेट भी शामिल हो सकते हैं. फ़ाइल का नाम BUILD.bazel भी रखा जा सकता है.

BUILD.baकोई फ़ाइल

BUILD फ़ाइल देखें. एक ही डायरेक्ट्री में मौजूद BUILD फ़ाइल के मुकाबले, इसे प्राथमिकता दी जाती है.

.bzl फ़ाइल

ऐसी फ़ाइल जो Starlark में लिखे गए नियमों, मैक्रो, और कॉन्सटेंट के बारे में बताती है. इसके बाद, load() फ़ंक्शन का इस्तेमाल करके इन्हें BUILD फ़ाइलों में इंपोर्ट किया जा सकता है.

ग्राफ़ बनाएं

बेज़ल, बिल्ड करने के लिए डिपेंडेंसी ग्राफ़ बनाता है और उसे पार करता है. इसमें टारगेट, कॉन्फ़िगर किए गए टारगेट, ऐक्शन, और आर्टफ़ैक्ट जैसे नोड शामिल होते हैं. बिल्ड को तब पूरा माना जाता है, जब वे सभी आर्टफ़ैक्ट, जिन पर अनुरोध किए गए टारगेट पर निर्भर करते हैं, की पुष्टि अप-टू-डेट हो जाती है.

बिल्ड की सेटिंग

कॉन्फ़िगरेशन का एक Starlark तय हिस्सा. ट्रांज़िशन, किसी सबग्राफ़ का कॉन्फ़िगरेशन बदलने के लिए बिल्ड सेटिंग को सेट कर सकता है. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, तो इसे बिल्ड फ़्लैग भी कहा जाता है.

क्लीन बिल्ड

ऐसा बिल्ड जो पिछले बिल्ड के नतीजों का इस्तेमाल नहीं करता है. आम तौर पर, यह इंक्रीमेंटल बिल्ड से धीमा होता है, लेकिन आम तौर पर इसे ज़्यादा सही माना जाता है. Basel की गारंटी के साथ यह साफ़ और बेहतर बिल्ड हमेशा सही होता है.

क्लाइंट-सर्वर मॉडल

bazel कमांड-लाइन क्लाइंट, लोकल मशीन पर बेज़ल कमांड लागू करने के लिए, अपने-आप बैकग्राउंड सर्वर चालू कर देता है. सर्वर सभी कमांड में बना रहता है, लेकिन कुछ समय तक कोई गतिविधि न होने पर (या बेज़ल शटडाउन के ज़रिए) अपने-आप रुक जाता है. Basel को सर्वर और क्लाइंट में बांटने से, JVM स्टार्टअप समय को कम करने में मदद मिलती है. साथ ही, तेज़ी से इंक्रीमेंटल बिल्ड होता है, क्योंकि ऐक्शन ग्राफ़ सभी कमांड की मेमोरी में बना रहता है.

आदेश

bazel build, bazel test, bazel run, और bazel query जैसे अलग-अलग बेज़ल फ़ंक्शन शुरू करने के लिए, कमांड लाइन पर इस्तेमाल किया जाता है.

कमांड फ़्लैग

कमांड के लिए खास तौर पर फ़्लैग का सेट. कमांड फ़्लैग, कमांड (bazel build <command flags>) के बाद दिए जाते हैं. फ़्लैग एक या एक से ज़्यादा कमांड पर लागू किए जा सकते हैं. उदाहरण के लिए, --configure खास तौर पर bazel sync कमांड के लिए एक फ़्लैग है. हालांकि, --keep_going sync, build, test वगैरह पर लागू होता है. फ़्लैग का इस्तेमाल अक्सर कॉन्फ़िगरेशन के लिए किया जाता है. इसलिए, अगर फ़्लैग की वैल्यू में बदलाव किया जाता है, तो हो सकता है कि Basel, मेमोरी में मौजूद ग्राफ़ को अमान्य कर दे. साथ ही, विश्लेषण का चरण फिर से शुरू हो सके.

कॉन्फ़िगरेशन

नियम की परिभाषाओं से बाहर की जानकारी, जो इस बात पर असर डालती है कि नियम किस तरह कार्रवाइयां जनरेट करते हैं. हर बिल्ड में कम से कम एक कॉन्फ़िगरेशन होता है, जिसमें टारगेट प्लैटफ़ॉर्म, ऐक्शन एनवायरमेंट वैरिएबल, और कमांड लाइन बिल्ड फ़्लैग शामिल होते हैं. ट्रांज़िशन से अतिरिक्त कॉन्फ़िगरेशन बन सकते हैं, जैसे कि होस्ट टूल या क्रॉस-कंपाइलेशन.

यह भी देखें: कॉन्फ़िगरेशन

कॉन्फ़िगरेशन को ट्रिम करना

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

डिस्क की कैश मेमोरी

रिमोट कैश मेमोरी में सेव करने की सुविधा के लिए, डिवाइस में मौजूद डिस्क ब्लॉब स्टोर. इसे असल रिमोट BLOB स्टोर के साथ जोड़ने में इस्तेमाल किया जा सकता है.

दिस्तिर

एक रीड-ओनली डायरेक्ट्री, जिसमें ऐसी फ़ाइलें होती हैं जिन्हें बेज़ल, डेटा स्टोर करने की जगह के नियमों का इस्तेमाल करके, इंटरनेट से फ़ेच कर सकते थे. बिल्ड को पूरी तरह से ऑफ़लाइन चलाने में मदद करता है.

डाइनैमिक एक्ज़ीक्यूशन

एक ऐसी एक्ज़ीक्यूशन रणनीति जो अलग-अलग अनुभव के आधार पर, लोकल और रिमोट एक्ज़ीक्यूशन के बीच चुनाव करती है. साथ ही, इसमें एक्ज़ीक्यूशन के ऐसे नतीजों का इस्तेमाल किया जाता है जो तेज़ी से कामयाब होते हैं. कुछ कार्रवाइयां स्थानीय तौर पर तेज़ी से की जाती हैं (उदाहरण के लिए, लिंक करना) और दूसरी कार्रवाइयां दूर से ही तेज़ी से की जाती हैं (उदाहरण के लिए, एक साथ कई काम करने लायक कंपाइलेशन). डाइनैमिक एक्ज़ीक्यूशन की रणनीति का इस्तेमाल करने से, बिल्ड प्रोसेस में लगने वाला सबसे बेहतर समय मिल सकता है.

प्लान लागू करने का चरण

बिल्ड का तीसरा चरण. विश्लेषण के चरण के दौरान बनाए गए कार्रवाई ग्राफ़ में कार्रवाइयां लागू करता है. ये कार्रवाइयां, आर्टफ़ैक्ट पढ़ने और लिखने के लिए एक्ज़ीक्यूटेबल (कंपाइलर, स्क्रिप्ट) को शुरू करती हैं. स्पॉन्ड रणनीतियां यह कंट्रोल करती हैं कि इन कार्रवाइयों को कैसे किया जाए: स्थानीय तौर पर, रिमोट तरीके से, डाइनैमिक तरीके से, सैंडबॉक्स की गई, डॉकर की वगैरह.

एक्ज़ीक्यूशन रूट

Workspace के आउटपुट बेस डायरेक्ट्री में मौजूद ऐसी डायरेक्ट्री, जहां सैंडबॉक्स किए बिना बनाए गए बिल्ड में लोकल कार्रवाइयां शुरू की जाती हैं. डायरेक्ट्री का कॉन्टेंट, ज़्यादातर फ़ाइल फ़ोल्डर से डाले गए आर्टफ़ैक्ट के सिमलिंक होते हैं. एक्ज़ीक्यूशन रूट में, अन्य इनपुट के तौर पर एक्सटर्नल डेटा स्टोर करने की जगहों के सिमलिंक और आउटपुट को सेव करने के लिए bazel-out डायरेक्ट्री शामिल होते हैं. लोडिंग फ़ेज़ के दौरान, डायरेक्ट्री के सिमलिंक फ़ॉरेस्ट बनाए जाते हैं. ये डायरेक्ट्री, उन पैकेज की ट्रांज़िट स्थिति के बारे में बताती हैं जिन पर बिल्ड निर्भर है. कमांड लाइन पर bazel info execution_root से ऐक्सेस किया जा सकता है.

फ़ाइल

आर्टफ़ैक्ट देखें.

हरमैटिसिटी

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

इंक्रीमेंटल बिल्ड

बिल्ड में लगने वाले समय और रिसॉर्स के इस्तेमाल को कम करने के लिए, इंक्रीमेंटल बिल्ड पिछले बिल्ड के नतीजों का फिर से इस्तेमाल करता है. डिपेंडेंसी की जांच और कैश मेमोरी का मकसद, इस तरह के बिल्ड के लिए सही नतीजे देना है. इंक्रीमेंटल बिल्ड, क्लीन बिल्ड से बिलकुल उलट होता है.

लेबल

टारगेट के लिए आइडेंटिफ़ायर. //path/to/package:target जैसे पूरी तरह से क्वालिफ़ाइड लेबल में, फ़ाइल फ़ोल्डर की रूट डायरेक्ट्री को मार्क करने के लिए //, path/to/package को उस डायरेक्ट्री के तौर पर शामिल किया जाता है जिसमें टारगेट की जानकारी देने वाली BUILD फ़ाइल शामिल होती है. इसके अलावा, ऊपर बताई गई BUILD फ़ाइल में बताए गए टारगेट के नाम के तौर पर :target को शामिल किया जाता है. इसे @my_repository//<..> के साथ भी जोड़ा जा सकता है, ताकि यह बताया जा सके कि टारगेट को my_repository नाम की ]बाहरी डेटा स्टोर करने की जगह] में बताया गया है.

लोड होने का चरण

बिल्ड का पहला फ़ेज़, जहां Basel, पैकेज बनाने के लिए WORKSPACE, BUILD, और .bzl फ़ाइलों को पार्स करता है. इस चरण में, मैक्रो और glob() जैसे कुछ फ़ंक्शन का आकलन किया जाता है. टारगेट ग्राफ़ बनाने के लिए, इसे बिल्ड के दूसरे फ़ेज़ यानी विश्लेषण का फ़ेज़ में शामिल किया गया है.

मैक्रो

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

यह भी देखें: मैक्रो दस्तावेज़

याद रखने का तरीका

यह एक छोटी और ऐसी स्ट्रिंग होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस स्ट्रिंग को नियम बनाने वाले व्यक्ति की ओर से चुना जाता है, ताकि यह तुरंत समझा जा सके कि नियम में कौनसी कार्रवाई की जा रही है. याद रखने का तरीका स्पॉन्सर रणनीति चुनने के लिए आइडेंटिफ़ायर के तौर पर इस्तेमाल किया जा सकता है. कार्रवाई याद रखने की तकनीक के कुछ उदाहरण Java के नियमों से Javac, C++ के नियमों से CppCompile, और Android के नियमों से AndroidManifestMerger हैं.

निजी नियम

ऐसे नियम जो Basel में बनाए गए हैं और Java में लागू किए गए हैं. ऐसे नियम .bzl फ़ाइलों में, नेटिव मॉड्यूल (जैसे, native.cc_library या native.java_library) में फ़ंक्शन के तौर पर दिखते हैं. उपयोगकर्ता के तय किए गए नियम (नॉन-नेटिव), Starlark का इस्तेमाल करके बनाए जाते हैं.

आउटपुट बेस

Basel आउटपुट फ़ाइलों को सेव करने के लिए, workspace की खास डायरेक्ट्री. इसका इस्तेमाल, आउटपुट को वर्कस्पेस के सोर्स ट्री से अलग करने के लिए किया जाता है. यह आउटपुट उपयोगकर्ता रूट में मौजूद होता है.

आउटपुट ग्रुप

बेज़ल टारगेट पूरे करने के बाद, हो सकता है कि फ़ाइलों का एक ग्रुप बन जाए. नियम अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं (जैसे, cc_library टारगेट के लिए java_library, .a और .so की .jar फ़ाइल). डिफ़ॉल्ट आउटपुट ग्रुप वह आउटपुट ग्रुप होता है जिसकी आर्टफ़ैक्ट, कमांड लाइन पर टारगेट का अनुरोध किए जाने पर बनाए जाते हैं. नियम, नाम वाले ऐसे और आउटपुट ग्रुप भी तय कर सकते हैं जिन्हें BUILD फ़ाइलों (filegroup नियम) या कमांड लाइन (--output_groups फ़्लैग) में साफ़ तौर पर बताया जा सकता है.

आउटपुट उपयोगकर्ता रूट

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

पैकेज

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

पैकेज ग्रुप

पैकेज के सेट को दिखाने वाला टारगेट. आम तौर पर, इसे visibility एट्रिब्यूट की वैल्यू में इस्तेमाल किया जाता है.

प्लैटफ़ॉर्म

बिल्ड में शामिल एक "मशीन टाइप". इनमें, "होस्ट" प्लैटफ़ॉर्म पर चलने वाली मशीन, ("होस्ट" प्लैटफ़ॉर्म), और मशीनों पर चलने वाले टूल ("एक्ज़िक" प्लैटफ़ॉर्म), और मशीनों के टारगेट ("टारगेट प्लैटफ़ॉर्म") शामिल हैं.

सेवा देने वाली कंपनी

डिपेंडेंसी संबंधों के साथ नियम टारगेट के बीच पास करने के लिए, जानकारी की यूनिट के बारे में बताने वाला स्कीमा. आम तौर पर, इसमें कंपाइलर विकल्प, ट्रांज़िटिव सोर्स या आउटपुट फ़ाइलें, और बिल्ड मेटाडेटा जैसी जानकारी होती है. इकट्ठा किए गए ट्रांज़िटिव डेटा को बेहतर तरीके से सेव करने के लिए, इसे अक्सर डिपसेट के साथ इस्तेमाल किया जाता है. पहले से मौजूद, सेवा देने वाली कंपनियों का एक उदाहरण DefaultInfo है.

ध्यान दें: किसी नियम के टारगेट के लिए खास डेटा रखने वाले ऑब्जेक्ट को "सेवा देने वाले का इंस्टेंस" कहा जाता है. हालांकि, कभी-कभी इसे "सेवा देने वाली कंपनी" के साथ मिला दिया जाता है.

यह भी देखें: सेवा देने वाले के दस्तावेज़

क्वेरी (सिद्धांत)

टारगेट प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर को समझने के लिए, बिल्ड ग्राफ़ का विश्लेषण करने की प्रोसेस. Basel, क्वेरी के तीन वैरिएंट के साथ काम करता है: query, cquery, और aquery.

क्वेरी (कमांड)

एक क्वेरी टूल, जो बिल्ड के लोड होने के बाद के चरण टारगेट ग्राफ़ पर काम करता है. यह प्रोसेस तेज़ी से काम करती है. हालांकि, इसके ज़रिए select(), फ़्लैग बनाने, आर्टफ़ैक्ट बनाने या कार्रवाइयां बनाने के असर का विश्लेषण नहीं किया जा सकता.

यह भी देखें: क्वेरी का तरीका, क्वेरी का रेफ़रंस

डेटा स्टोर करने की जगह की कैश मेमोरी

बिल्ड के लिए Basel की ओर से डाउनलोड की गई फ़ाइलों की ऐसी कैश मेमोरी जिसमें शेयर किया जा सकने वाला कॉन्टेंट मौजूद है. इसे फ़ाइल फ़ोल्डर में शेयर किया जा सकता है. शुरुआत में डाउनलोड होने के बाद, ऑफ़लाइन बिल्ड चालू करता है. आम तौर पर, इसका इस्तेमाल http_archive जैसे रिपॉज़िटरी नियमों और repository_ctx.download जैसे रिपॉज़िटरी नियम के एपीआई के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए किया जाता है. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब उनके SHA-256 चेकसम डाउनलोड के लिए तय किए गए हों.

दोबारा जनरेट करने की क्षमता

बिल्ड या टेस्ट की ऐसी प्रॉपर्टी जिसे बनाने या टेस्ट करने के लिए इनपुट का एक सेट, हर बार आउटपुट का एक ही सेट देगा. भले ही, समय, तरीका या एनवायरमेंट कुछ भी हो. ध्यान दें, इसका यह मतलब नहीं है कि आउटपुट सही है या यह आपको पसंद है.

नियम

cc_library जैसी BUILD फ़ाइल में, नियम टारगेट तय करने के लिए स्कीमा. BUILD फ़ाइल के लेखक के हिसाब से, नियम में एट्रिब्यूट का एक सेट और ब्लैक बॉक्स लॉजिक शामिल होता है. यह लॉजिक, नियम के टारगेट को आउटपुट आर्टफ़ैक्ट बनाने और नियम के अन्य टारगेट को जानकारी देने का तरीका बताता है. .bzl के लेखकों के हिसाब से, नियम नई प्रोग्रामिंग भाषाओं और एनवायरमेंट के साथ काम करने के लिए, Bagel का इस्तेमाल करने का मुख्य तरीका है.

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

ध्यान दें: अभी तक "नियम" शब्द का इस्तेमाल, टारगेट किए जाने वाले नियम के बारे में बताने के लिए किया जाता था. यह जानकारी, Make जैसे टूल से ली गई है. हालांकि, इससे भ्रम की स्थिति पैदा होती है और Baज़र के लिए इससे बचना चाहिए.

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

नियम का टारगेट

टारगेट, जो किसी नियम का इंस्टेंस होता है. फ़ाइल टारगेट और पैकेज ग्रुप में अंतर होता है. नियम न समझें.

रनफ़ाइल

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

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

सैंडबॉक्सिंग

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

स्काईफ़्रेम

Skyframe, Bagel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैलुएशन फ़्रेमवर्क है.

छपाई का काम

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

स्टारलार्क

नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. Python का सीमित सबसेट (वाक्य और व्याकरण के हिसाब से), जिसे कॉन्फ़िगरेशन और बेहतर परफ़ॉर्मेंस के लिए बनाया गया है. .bzl फ़ाइल एक्सटेंशन का इस्तेमाल करता है. BUILD फ़ाइलें Starlark के ज़्यादा पाबंदी वाले वर्शन का इस्तेमाल करती हैं. जैसे, def फ़ंक्शन की कोई परिभाषा नहीं. इसे पहले Skylark के नाम से जाना जाता था.

यह भी देखें: Starlark भाषा के दस्तावेज़

स्टार्टअप फ़्लैग

bazel और कमांड के बीच तय किए गए फ़्लैग का सेट. उदाहरण के लिए, बैज --host_jvm_debug बिल्ड. ये फ़्लैग, Basel सर्वर के कॉन्फ़िगरेशन में बदलाव करते हैं. इसलिए, स्टार्टअप फ़्लैग में कोई भी बदलाव करने पर, सर्वर रीस्टार्ट होता है. स्टार्टअप फ़्लैग किसी भी निर्देश के लिए खास नहीं होते हैं.

टारगेट

यह ऐसा ऑब्जेक्ट है जिसे BUILD फ़ाइल में तय किया गया है और लेबल से पहचाना गया है. टारगेट, असली उपयोगकर्ता के नज़रिए से वर्कस्पेस की बनाई जा सकने वाली इकाइयां दिखाते हैं.

नियम को इंस्टैंशिएट करके बताए गए टारगेट को नियम टारगेट कहा जाता है. नियम के आधार पर, इन्हें चलाया जा सकता है (जैसे cc_binary) या टेस्ट करने लायक (जैसे cc_test). नियम के टारगेट आम तौर पर अपने एट्रिब्यूट (जैसे कि deps) के ज़रिए दूसरे टारगेट पर निर्भर करते हैं. ये डिपेंडेंसी, टारगेट ग्राफ़ के आधार पर तय होती हैं.

नियम के टारगेट के अलावा, इसमें फ़ाइल टारगेट और पैकेज ग्रुप के टारगेट भी होते हैं. फ़ाइल टारगेट उन आर्टफ़ैक्ट से जुड़े हैं जिनका रेफ़रंस BUILD फ़ाइल में दिया गया है. खास मामले में, किसी भी पैकेज की BUILD फ़ाइल को हमेशा उस पैकेज में सोर्स फ़ाइल का टारगेट माना जाता है.

लोड होने के चरण के दौरान टारगेट खोजे जाते हैं. विश्लेषण के चरण के दौरान, कॉन्फ़िगर किए गए टारगेट बनाने के लिए, टारगेट बिल्ड कॉन्फ़िगरेशन से जुड़े होते हैं.

टारगेट ग्राफ़

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

टारगेट पैटर्न

कमांड लाइन पर टारगेट का ग्रुप तय करने का तरीका. आम तौर पर, इस्तेमाल होने वाले पैटर्न :all (सभी नियम टारगेट), :* (सभी नियम + फ़ाइल टारगेट), ... (मौजूदा पैकेज और बार-बार होने वाले सभी सबपैकेज हैं). इसका इस्तेमाल एक साथ किया जा सकता है. उदाहरण के लिए, //...:* का मतलब है कि सभी पैकेज में मौजूद नियम और फ़ाइल टारगेट, वर्कस्पेस के रूट से बार-बार होते हैं.

जांच

टेस्ट के नियमों से इंस्टैंशिएट किए गए नियम टारगेट. इसलिए, इसमें टेस्ट करने लायक टेस्ट शामिल है. एक्ज़ीक्यूटेबल के पूरा होने के बाद शून्य का रिटर्न कोड, टेस्ट की सफलता को दिखाता है. बेज़ल और टेस्ट के बीच का सटीक अनुबंध (जैसे कि टेस्ट एनवायरमेंट वैरिएबल, टेस्ट नतीजे इकट्ठा करने के तरीके) टेस्ट एन्साइक्लोपीडिया में बताया गया है.

टूलचेन

किसी भाषा के लिए आउटपुट बनाने वाले टूल का सेट. आम तौर पर, टूलचेन में कंपाइलर, लिंकर, इंटरप्रेटर या/और लिंटर शामिल होते हैं. टूलचेन में प्लैटफ़ॉर्म के हिसाब से भी फ़र्क़ हो सकता है. इसका मतलब है कि Windows के वैरिएंट के लिए, Unix कंपाइलर टूलचेन के कॉम्पोनेंट अलग-अलग हो सकते हैं. भले ही, टूलचेन एक ही भाषा के लिए हो. प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने को टूलचेन रिज़ॉल्यूशन कहा जाता है.

टॉप लेवल टारगेट

अगर बिल्ड टारगेट का अनुरोध बेज़ल कमांड लाइन पर किया जाता है, तो वह टॉप-लेवल होता है. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर है और bazel build //:foo को कॉल किया जाता है, तो इस बिल्ड के लिए //:foo टॉप-लेवल है और //:bar टॉप-लेवल नहीं है. हालांकि, दोनों टारगेट बनाने होंगे. टॉप-लेवल और नॉन-टॉप-लेवल टारगेट के बीच एक अहम अंतर यह है कि बेज़ल कमांड लाइन या .baazrc की मदद से, सेट किए गए कमांड फ़्लैग, टॉप लेवल टारगेट के लिए कॉन्फ़िगरेशन सेट करेंगे. हालांकि, नॉन-टॉप लेवल के टारगेट के लिए, ट्रांज़िशन में बदलाव किया जा सकता है.

ट्रांज़िशन

कॉन्फ़िगरेशन की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. बिल्ड ग्राफ़ में टारगेट को अलग-अलग कॉन्फ़िगरेशन के लिए चालू करता है, भले ही उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. आम तौर पर, ट्रांज़िशन का इस्तेमाल स्प्लिट ट्रांज़िशन के साथ किया जाता है. इसमें टारगेट ग्राफ़ के कुछ हिस्सों को हर फ़ोर्क के लिए अलग-अलग कॉन्फ़िगरेशन के साथ फ़ोर्क किया जाता है. उदाहरण के लिए, किसी एक बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल करके ARM और x86 के लिए कंपाइल किए गए नेटिव बाइनरी वाला Android APK बनाया जा सकता है.

यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन

पेड़ का आर्टफ़ैक्ट

एक आर्टफ़ैक्ट, जो फ़ाइलों का कलेक्शन दिखाता है. ये फ़ाइलें खुद आर्टफ़ैक्ट नहीं हैं, इसलिए इन पर काम करने वाली कार्रवाई को, ट्री आर्टफ़ैक्ट को उसके इनपुट या आउटपुट के तौर पर रजिस्टर करना होगा.

किसको दिखे

बिल्ड सिस्टम में अनचाही डिपेंडेंसी से बचने के लिए इन दो तरीकों में से एक है: किसी टारगेट पर दूसरे टारगेट के हिसाब से निर्भर होने या नहीं, इसे कंट्रोल करने के लिए टारगेट विज़िबिलिटी; और लोड विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि BUILD या .bzl फ़ाइल, दी गई .bzl फ़ाइल को लोड कर सकती है या नहीं. संदर्भ के बिना, आम तौर पर "विज़िबिलिटी" का मतलब, 'किसको दिखे' सेटिंग से है.

यह भी देखें: 'किसको दिखे' सेटिंग से जुड़ा दस्तावेज़

Workspace

एक डायरेक्ट्री, जिसमें WORKSPACE फ़ाइल और उस सॉफ़्टवेयर का सोर्स कोड होता है जिसे आपको बनाना है. // से शुरू होने वाले लेबल, फ़ाइल फ़ोल्डर की डायरेक्ट्री से जुड़े होते हैं.

workspace फ़ाइल

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