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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
समस्या की शिकायत करें स्रोत देखें

कार्रवाई

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

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

कार्रवाई वाली कैश मेमोरी

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

कार्रवाई का ग्राफ़

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

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

एक क्वेरी टूल, जो बिल्ड कार्रवाइयां पर क्वेरी कर सकता है. इससे यह पता चलता है कि बिल्ड के नियमों का काम किस तरह काम करता है.

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

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

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

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

सह-प्रॉडक्ट

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

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

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

पहलू

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

यह भी देखें: आस-पास मौजूद दस्तावेज़

आसपेक्ट रेशियो

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

A की चौड़ाई के हिसाब से A लागू करने के लिए, Bprovides के provides एट्रिब्यूट में विज्ञापन दिखाने वाली सेवा देने वाली कंपनियां, इस बात से मेल खानी चाहिए कि वह अपने required_aspect_providers एट्रिब्यूट में क्या जानकारी दिखाना चाहता है.

एट्रिब्यूट

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

.bazelrc

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

ब्लेज़

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

बिल्ड फ़ाइल

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

BUILD.bazel फ़ाइल

BUILD फ़ाइल देखें. एक ही डायरेक्ट्री में BUILD फ़ाइल को प्राथमिकता दी जाती है.

.bzl फ़ाइल

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

ग्राफ़ बनाएं

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

बिल्ड सेटिंग

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

साफ़ बिल्ड

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

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

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

Command

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

कमांड फ़्लैग

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

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

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

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

कॉन्फ़िगरेशन में काट-छांट करना

असल में, टारगेट के कॉन्फ़िगरेशन के सिर्फ़ हिस्सों को शामिल करने की प्रोसेस. उदाहरण के लिए, अगर आप C++ डिपेंडेंसी //:c के साथ Java बाइनरी //:j बनाते हैं, तो //:c के कॉन्फ़िगरेशन में --javacopt की वैल्यू शामिल करना ज़रूरी नहीं है. ऐसा इसलिए, क्योंकि --javacopt गैर-ज़रूरी चीज़ों के साथ गैर-ज़रूरी ज़रूरत नहीं है

कॉन्फ़िगर की गई क्वेरी (cquery)

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

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

कॉन्फ़िगर किया गया टारगेट

किसी कॉन्फ़िगरेशन के साथ टारगेट का मूल्यांकन करने का नतीजा. विश्लेषण फ़ेज़ में बिल्ड के विकल्पों को उन टारगेट के साथ जोड़ा जाता है जिन्हें बनाया जाना ज़रूरी है. उदाहरण के लिए, अगर //:foo एक ही बिल्ड में दो अलग-अलग आर्किटेक्चर के लिए बिल्ड करता है, तो उसके पास कॉन्फ़िगर किए गए दो टारगेट होते हैं: <//:foo, x86> और <//:foo, arm>.

सुधार

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

निर्भर है

दो टारगेट के बीच का डायरेक्ट किनारे. अगर //:foo के एट्रिब्यूट की वैल्यू में //:bar का रेफ़रंस दिया गया है, तो टारगेट //:foo के लिए टारगेट //:bar पर टारगेट निर्भरता होती है. अगर //:foo में कोई कार्रवाई, //:bar में किसी कार्रवाई की मदद से बनाए गए इनपुट आर्टफ़ैक्ट पर निर्भर करती है, तो //:foo की //:bar पर कार्रवाई डिपेंडेंसी होती है.

डेप्सेट

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

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

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

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

डिस्ट्रियर

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

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

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

एक्ज़ीक्यूशन का फ़ेज़

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

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

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

फ़ाइल

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

हर्मेटिकिटी

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

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

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

लेबल

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

लोडिंग फ़ेज़

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

मैक्रो

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

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

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

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

नेटिव नियम

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

आउटपुट बेस

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

आउटपुट ग्रुप

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

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

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

पैकेज

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

पैकेज ग्रुप

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

प्लैटफ़ॉर्म

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

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

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

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

क्वेरी (कॉन्सेप्ट)

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

क्वेरी (command)

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

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

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

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

रीप्रॉड्यूसिबिलिटी

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

नियम

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

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

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

नियम टारगेट

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

रन फ़ाइलें

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

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

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

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

स्काईफ़्रेम

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

छपाई का काम

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

स्टारलार्क

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

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

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

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

टारगेट

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

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

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

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

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

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

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

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

जांच

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

औज़ार

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

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

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

ट्रांज़िशन

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

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

ट्री आर्टफ़ैक्ट

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

किसको दिखे

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

यह भी देखें: वीडियो किसको दिखे

फ़ाइल फ़ोल्डर

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

WORKSPACE फ़ाइल

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