कार्रवाई
बिल्ड के दौरान चलाने के लिए कोई निर्देश. उदाहरण के लिए, ऐसे कंपाइलर को कॉल किया जा सकता है जो आर्टफ़ैक्ट को इनपुट के तौर पर इस्तेमाल करता है और आउटपुट के तौर पर अन्य आर्टफ़ैक्ट तैयार करता है. इसमें कमांड लाइन आर्ग्युमेंट, ऐक्शन बटन, और एनवायरमेंट जैसा मेटाडेटा शामिल होता है और इनपुट/आउटपुट आर्टफ़ैक्ट शामिल किए जा सकते हैं.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
ऐक्शन कैश
डिस्क में मौजूद कैश मेमोरी, जो लागू की गई कार्रवाइयों की मैपिंग को सेव करती है आउटपुट के बारे में बताएँगे. कैश मेमोरी को ऐक्शन बटन के नाम से जाना जाता है. ऐप्लिकेशन बेज़ल के इंंक्रीमेंटलिटी मॉडल के लिए मुख्य कॉम्पोनेंट. कैश मेमोरी यहां सेव की जाती है: आउटपुट बेस डायरेक्ट्री मौजूद होती है और इस वजह से, Basel सर्वर के रीस्टार्ट होने से बचा जा सकता है.
ऐक्शन ग्राफ़
कार्रवाइयों और आर्टफ़ैक्ट का इन-मेमोरी ग्राफ़
इन कार्रवाइयों से जनरेट होती है. ग्राफ़ में ऐसे आर्टफ़ैक्ट शामिल हो सकते हैं जो
सोर्स फ़ाइलें (उदाहरण के लिए, फ़ाइल सिस्टम में) और जनरेट की गईं
इंटरमीडिएट/फ़ाइनल आर्टफ़ैक्ट जिनका BUILD फ़ाइलों में ज़िक्र नहीं किया गया है. बनाए जाने की तारीख
विश्लेषण फ़ेज़ के दौरान और का पालन करने के दौरान इस्तेमाल किया गया
फ़ेज़ के लिए चुनें.
कार्रवाई ग्राफ़ क्वेरी (क्वेरी)
एक ऐसा क्वेरी टूल जो बिल्ड कार्रवाइयों के बारे में क्वेरी कर सकता है. इससे यह विश्लेषण करने में मदद मिलती है कि बिल बनाने के नियम असल वर्क बिल्ड के लिए किया जा सकता है.
ऐक्शन बटन
किसी कार्रवाई की कैश मेमोरी. इसका हिसाब, कार्रवाई के मेटाडेटा के आधार पर लगाया जाता है, जो इसमें कार्रवाई, कंपाइलर फ़्लैग, लाइब्रेरी में एक्ज़ीक्यूट किया जाने वाला कमांड शामिल हो सकता है जगहें या सिस्टम हेडर. Basel को कैश मेमोरी में सेव करता है या अमान्य व्यक्तिगत क्रियाओं को अमान्य कर सकते हैं.
विश्लेषण का चरण
बिल्ड का दूसरा चरण. टारगेट ग्राफ़ को प्रोसेस करता है
BUILD फ़ाइलों में बताया गया है, ताकि मेमोरी में कार्रवाई बनाई जा सके
ग्राफ़ जो इस अवधि के दौरान चलने वाली कार्रवाइयों का क्रम तय करता है
लागू करने का चरण. यह वह चरण है जिसमें नियम
लागू करने के तरीके का आकलन किया जाता है.
सह-प्रॉडक्ट
सोर्स फ़ाइल या जनरेट की गई फ़ाइल. यह फ़ाइलों की एक डायरेक्ट्री भी हो सकती है, जिसे पेड़ से जुड़े आर्टफ़ैक्ट.
आर्टफ़ैक्ट कई कार्रवाइयों के लिए इनपुट हो सकता है, लेकिन इसे सिर्फ़ सिर्फ़ एक कार्रवाई कर सकते हैं.
फ़ाइल टारगेट से जुड़े आर्टफ़ैक्ट को, लेबल.
पक्ष
नियमों का एक ऐसा तरीका जिसकी मदद से अतिरिक्त कार्रवाइयां तय की जा सकती हैं
निर्भरता. उदाहरण के लिए, अगर टारगेट A, B पर निर्भर है, तो कोई भी पहलू लागू किया जा सकता है
A, जो B पर डिपेंडेंसी एज को ऊपर ले जाता है और B में अतिरिक्त कार्रवाइयां करता है
का इस्तेमाल करें. ये अतिरिक्त कार्रवाइयां
एक ही पहलू की ज़रूरत वाले टारगेट के बीच कैश मेमोरी और फिर से इस्तेमाल किया गया हो. इसके साथ बनाया गया
aspect() Starlark Build API फ़ंक्शन. उदाहरण के लिए, इसका इस्तेमाल करके
IDE के लिए मेटाडेटा और लिंटिंग के लिए कार्रवाइयां बनाएं.
यह भी देखें: अलग-अलग पहलुओं से जुड़ा दस्तावेज़
आसपेक्ट-ऑन-आसपेक्ट
कंपोज़िशन एक ऐसी प्रोसेस है जिससे नतीजों पर चीज़ों को लागू किया जा सकता है
जानकारी मिलती है. उदाहरण के लिए, एक ऐसा पहलू जो
IDEs उस पहलू पर लागू किए जा सकते हैं जो फ़ाइल फ़ोल्डर से .java फ़ाइलें जनरेट करता है
प्रोटो.
B आसपेक्ट रेशियो के ऊपर लागू करने के लिए, सेवा देने वाली कंपनियांA
B अपनी provides एट्रिब्यूट में विज्ञापन देता है
यह ज़रूरी है कि A, अपने required_aspect_providers में एलान किए गए एलान से मेल खाए
एट्रिब्यूट की वैल्यू सबमिट करें.
एट्रिब्यूट
नियम के लिए पैरामीटर, जिसका इस्तेमाल हर टारगेट बिल्ड की जानकारी दिखाने के लिए किया जाता है.
उदाहरण के लिए, srcs, deps, और copts
टारगेट की सोर्स फ़ाइलें, डिपेंडेंसी, और कस्टम कंपाइलर विकल्प. विशेष
किसी टारगेट के लिए उपलब्ध एट्रिब्यूट, उसके नियम के टाइप पर निर्भर करते हैं.
.bazelrc
बैज की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करके, स्टार्टअप की डिफ़ॉल्ट वैल्यू में बदलाव किया जाता है
फ़्लैग और कमांड फ़्लैग का इस्तेमाल करते हैं.
विकल्पों के समूह का उपयोग करके उन्हें बेज़ल कमांड लाइन पर एक साथ सेट किया जा सकता है
--config फ़्लैग. Basel की एक से ज़्यादा फ़ाइलों से सेटिंग को मर्ज की जा सकती है
(सिस्टम के हिसाब से, हर वर्कस्पेस में, हर उपयोगकर्ता के लिए या पसंद के मुताबिक बनाई गई जगह से), और
bazelrc फ़ाइल, अन्य bazelrc फ़ाइलों से भी सेटिंग इंपोर्ट कर सकती है.
ब्लेज़
Basel का Google-आंतरिक वर्शन. Google का मुख्य बिल्ड सिस्टम मोनो रिपॉज़िटरी.
फ़ाइल बनाएं
BUILD फ़ाइल मुख्य कॉन्फ़िगरेशन फ़ाइल होती है, जो Basel को किस सॉफ़्टवेयर के बारे में बताती है
आउटपुट, उनकी डिपेंडेंसी क्या है, और उन्हें कैसे बनाया जाए. बेज़ल
इनपुट के तौर पर BUILD फ़ाइल लेता है और डिपेंडेंसी का ग्राफ़ बनाने के लिए, फ़ाइल का इस्तेमाल करता है
साथ ही, ऐसे कार्रवाइयों का सुझाव भी दिया जा सकता है जो इंटरमीडिएट और फ़ाइनल में होने की वजह से पूरी तरह से सही हों
सॉफ़्टवेयर आउटपुट के तौर पर मिले. BUILD फ़ाइल, डायरेक्ट्री और उन सब-डायरेक्ट्री को मार्क करती है जो
BUILD फ़ाइल को पैकेज के तौर पर शामिल किया गया है. साथ ही, इसमें
नियमों के हिसाब से बनाए गए टारगेट. फ़ाइल का नाम भी दिया जा सकता है
BUILD.bazel.
BUILD.baकोई फ़ाइल
BUILD फ़ाइल देखें. उसी फ़ाइल में मौजूद BUILD फ़ाइल के मुकाबले इसे प्राथमिकता दी जाती है
डायरेक्ट्री.
.bzl फ़ाइल
ऐसी फ़ाइल जिसमें नियमों, मैक्रो, और कॉन्सटेंट को परिभाषित किया जाता है
स्टारलार्क. इसके बाद, इन्हें BUILD में इंपोर्ट किया जा सकता है
फ़ाइलें पाने के लिए load() फ़ंक्शन का इस्तेमाल करें.
ग्राफ़ बनाएं
बेज़ल, बिल्ड करने के लिए डिपेंडेंसी ग्राफ़ बनाता है और उसे पार करता है. इसमें टारगेट जैसे नोड शामिल हैं, जिन्हें कॉन्फ़िगर किया गया है टारगेट, कार्रवाई, और आर्टफ़ैक्ट. ऐप्लिकेशन बिल्ड को तब पूरा माना जाता है, जब ऐसी सभी आर्टफ़ैक्ट अनुरोध किए गए टारगेट, अप-टू-डेट के तौर पर पुष्टि किए हुए हैं.
बिल्ड की सेटिंग
कॉन्फ़िगरेशन का एक Starlark तय हिस्सा. ट्रांज़िशन, किसी सबग्राफ़ की सेटिंग में बदलाव करने के लिए बिल्ड सेटिंग को सेट कर सकता है कॉन्फ़िगरेशन. अगर उपयोगकर्ता को कमांड-लाइन फ़्लैग के तौर पर दिखाया जाता है, इसे बिल्ड फ़्लैग भी कहा जाता है.
क्लीन बिल्ड
ऐसा बिल्ड जो पिछले बिल्ड के नतीजों का इस्तेमाल नहीं करता है. आम तौर पर, यह तरीका धीमा होता है इंक्रीमेंटल बिल्ड से ज़्यादा, लेकिन आम तौर पर ज़्यादा सही. बेज़ल, बिना किसी रुकावट के बनाए गए और बेहतर तरीके से बिल्ड करने की गारंटी देता है हमेशा सही होते हैं.
क्लाइंट-सर्वर मॉडल
bazel कमांड-लाइन क्लाइंट,
local मशीन का इस्तेमाल करके कमांड का पालन किया. सर्वर सभी जगहों पर बना रहता है
लेकिन कुछ समय तक निष्क्रिय रहने पर (या स्पष्ट रूप से
बेज़ल शटडाउन). Basel को सर्वर और क्लाइंट में बांटने से, JVM को कम करने में मदद मिलती है
स्टार्टअप समय सेट करता है और ज़्यादा तेज़ इंक्रीमेंटल बिल्ड के साथ काम करता है
ऐसा इसलिए, क्योंकि ऐक्शन ग्राफ़ सभी कमांड में मेमोरी में बना रहता है.
आदेश
bazel
build, bazel test, bazel run, और bazel query जैसे अलग-अलग बेज़ल फ़ंक्शन शुरू करने के लिए, कमांड लाइन पर इस्तेमाल किया जाता है.
कमांड फ़्लैग
कमांड के लिए खास तौर पर फ़्लैग का सेट. कमांड फ़्लैग की जानकारी दी गई है
निर्देश (bazel build <command flags>) के बाद. फ़्लैग इन पर लागू हो सकते हैं
एक या एक से ज़्यादा निर्देश दिए जा सकते हैं. उदाहरण के लिए, --configure खास तौर पर
bazel sync आदेश है, लेकिन --keep_going sync, build पर लागू होता है,
test और अन्य. फ़्लैग का इस्तेमाल अक्सर कॉन्फ़िगरेशन के लिए किया जाता है
का मकसद तय करना है, इसलिए फ़्लैग की वैल्यू में बदलाव की वजह से Basel की मेमोरी अमान्य हो सकती है
ग्राफ़ बनाएं और विश्लेषण का चरण फिर से शुरू करें.
कॉन्फ़िगरेशन
नियम की परिभाषाओं से बाहर की जानकारी, जो नियमों के जनरेट करने के तरीके पर असर डालती है कार्रवाइयां. हर बिल्ड में कम से कम एक कॉन्फ़िगरेशन होता है, जो टारगेट प्लैटफ़ॉर्म, ऐक्शन एनवायरमेंट वैरिएबल, और कमांड-लाइन build फ़्लैग के तौर पर मार्क करें. ट्रांज़िशन की वजह से अतिरिक्त कॉन्फ़िगरेशन, जैसे कि होस्ट टूल या क्रॉस-कंपाइलेशन.
यह भी देखें: कॉन्फ़िगरेशन
कॉन्फ़िगरेशन को ट्रिम करना
सिर्फ़ उन हिस्सों को शामिल करने की प्रोसेस जिनसे कॉन्फ़िगरेशन
टारगेट के लिए कितनी ज़रूरत थी. उदाहरण के लिए, अगर C++ के साथ Java बाइनरी //:j बनाया जाता है
निर्भरता //:c, में --javacopt का मान शामिल करना बेकार है
//:c का कॉन्फ़िगरेशन, क्योंकि --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 से ऐक्सेस किया जा सकता है.
फ़ाइल
Artifact देखें.
Hermeticity
अगर बिल्ड और टेस्ट पर कोई बाहरी असर न हो, तो बिल्ड हर्मेटिक होता है ऑपरेशन, जिससे यह पक्का करने में मदद मिलती है कि नतीजे तय करने वाले और सही. उदाहरण के लिए, हर्मेटिक बिल्ड आम तौर पर नेटवर्क की अनुमति नहीं देता है कार्रवाइयों का ऐक्सेस देना, एलान किए गए इनपुट के ऐक्सेस पर पाबंदी लगाना, तय किए गए टाइमस्टैंप का इस्तेमाल करना, और टाइमज़ोन, एनवायरमेंट वैरिएबल का ऐक्सेस प्रतिबंधित करें, और इनके लिए तय सीड का इस्तेमाल करें रैंडम नंबर जनरेटर
इंक्रीमेंटल बिल्ड
बिल्ड टाइम को कम करने के लिए, इंक्रीमेंटल बिल्ड पिछले बिल्ड के नतीजों का फिर से इस्तेमाल करता है और संसाधन के इस्तेमाल की जानकारी देता है. डिपेंडेंसी की जांच और कैश मेमोरी का मकसद, सही नतीजे जनरेट करना है इस तरह के बिल्ड के लिए नतीजे मिलते हैं. इंक्रीमेंटल बिल्ड, क्लीन से उलट होता है बिल्ड.
लेबल
टारगेट के लिए आइडेंटिफ़ायर. आम तौर पर, यह फ़ॉर्म
@repo//path/to/package:target, जहां repo
डेटा स्टोर करने की जगह में टारगेट है. path/to/package पाथ है
उस डायरेक्ट्री में जोड़ दी जाएगी जिसमें BUILD फ़ाइल शामिल होगी. यह फ़ाइल,
target (इस डायरेक्ट्री को पैकेज भी कहा जाता है), और target
लक्ष्य का ही नाम है. स्थिति के आधार पर, इसके कुछ हिस्से
शायद इस्तेमाल न किया गया हो.
यह भी देखें: लेबल
लोड होने का चरण
बिल्ड का पहला फ़ेज़, जहां Basel ने BUILD फ़ाइलों को एक्ज़ीक्यूट करके
पैकेज बनाएं. मैक्रो और कुछ खास फ़ंक्शन, जैसे कि
इस चरण में glob() का आकलन किया जाता है. इसके दूसरे चरण में शामिल
बिल्ड, टारगेट बनाने के लिए विश्लेषण का फ़ेज़
ग्राफ़ देखें.
मैक्रो
इसके तहत, टारगेट के लिए कई नियम तय करने का तरीका
एक Starlark फ़ंक्शन. सामान्य नियम के एलान का फिर से इस्तेमाल करने की सुविधा चालू करता है
BUILD फ़ाइलों में पैटर्न. नियम के टारगेट तक बढ़ाया गया
लोडिंग चरण के दौरान एलान.
यह भी देखें: मैक्रो दस्तावेज़
याद रखने का तरीका
यह एक छोटी स्ट्रिंग होती है, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस स्ट्रिंग को नियम बनाने वाले व्यक्ति की ओर से चुना जाता है, ताकि उसे तुरंत समझा जा सके
नियम में किसी कार्रवाई का इस्तेमाल किया जा रहा है. याद रखने का तरीका इस तरह इस्तेमाल किया जा सकता है
स्पॉन्स रणनीति चुनने के लिए आइडेंटिफ़ायर. गतिविधियों की याद दिलाने के कुछ उदाहरण
ये हैं Java के नियमों से Javac, C++ के नियमों से CppCompile, और
Android के नियमों से AndroidManifestMerger.
मॉड्यूल
Basel प्रोजेक्ट के कई वर्शन हो सकते हैं. हर वर्शन में दूसरे मॉड्यूल पर निर्भरता. यह दूसरे सिद्धांतों के जाने-पहचाने कॉन्सेप्ट से मिलता-जुलता है डिपेंडेंसी मैनेजमेंट सिस्टम, जैसे कि Maven आर्टफ़ैक्ट, एक एनपीएम पैकेज, मॉड्यूल या कार्गो क्रेट का इस्तेमाल करें. मॉड्यूल बेज़ेल के बाहरी हिस्से का आधार बनाते हैं डिपेंडेंसी मैनेजमेंट सिस्टम.
हर मॉड्यूल के लिए एक रेपो का इस्तेमाल होता है. इसमें MODULE.bazel फ़ाइल होती है
रूट डालें. इस फ़ाइल में मॉड्यूल के बारे में मेटाडेटा (जैसे कि इसका नाम और
वर्शन), इसकी डायरेक्ट डिपेंडेंसी, और कई अन्य डेटा. जैसे, टूलचेन
रजिस्ट्रेशन और मॉड्यूल एक्सटेंशन इनपुट का इस्तेमाल करना चाहिए.
मॉड्यूल मेटाडेटा, Basel रजिस्ट्रियों में होस्ट किया गया है.
यह भी देखें: बेज़ल मॉड्यूल
मॉड्यूल एक्सटेंशन
एक लॉजिक, जिसे पढ़ा जा सकता है और डेटा स्टोर करने की जगह जनरेट करने के लिए इस्तेमाल किया जा सकता है मॉड्यूल डिपेंडेंसी ग्राफ़ में इनपुट और रेपो को शुरू करना नियम. मॉड्यूल एक्सटेंशन में, रेपो जैसी सुविधाएं हैं नियम बनाकर उन्हें इंटरनेट ऐक्सेस करने, फ़ाइल I/O चलाने वगैरह की अनुमति दी जा सकती है.
यह भी देखें: मॉड्यूल एक्सटेंशन
निजी नियम
ऐसे नियम जो Basel में बनाए गए हैं और Java में लागू किए गए हैं. ऐसे नियम
.bzl फ़ाइलों में नेटिव मॉड्यूल में फ़ंक्शन के तौर पर दिखता है (इसके लिए
उदाहरण के लिए, native.cc_library या native.java_library). उपयोगकर्ता के तय किए गए नियम
(नॉन-नेटिव) को Starlark का इस्तेमाल करके बनाया जाता है.
आउटपुट बेस
Basel आउटपुट फ़ाइलों को सेव करने के लिए, workspace की खास डायरेक्ट्री. उपयोग किया गया आउटपुट को workspace के सोर्स ट्री से अलग करने के लिए (मुख्य रेपो). यह आउटपुट उपयोगकर्ता रूट में मौजूद होता है.
आउटपुट ग्रुप
उन फ़ाइलों का एक समूह जो बाद में
टारगेट. नियम अपने सामान्य आउटपुट को "डिफ़ॉल्ट आउटपुट ग्रुप" में रखते हैं
(जैसे, cc_library के लिए java_library, .a और .so की .jar फ़ाइल
लक्ष्य). डिफ़ॉल्ट आउटपुट ग्रुप वह आउटपुट ग्रुप होता है जिसका
आर्टफ़ैक्ट तब बनाए जाते हैं, जब कमांड लाइन पर टारगेट का अनुरोध किया जाता है.
नियम, नाम वाले ऐसे और आउटपुट ग्रुप तय कर सकते हैं जिनकी जानकारी साफ़ तौर पर दी जा सकती है
BUILD फ़ाइलें (filegroup नियम) या कमांड लाइन
(--output_groups फ़्लैग).
आउटपुट उपयोगकर्ता रूट
बेज़ल के आउटपुट सेव करने के लिए, खास तौर पर उपयोगकर्ता की बनाई गई डायरेक्ट्री. डायरेक्ट्री का नाम यह है जो उपयोगकर्ता के सिस्टम उपयोगकर्ता नाम से ली जाती है. आउटपुट फ़ाइल को बीच में आने से रोकता है, अगर कई उपयोगकर्ता सिस्टम पर एक ही समय में एक प्रोजेक्ट बना रहे हों. इसमें अलग-अलग वर्कस्पेस के आउटपुट बनाने से जुड़ी सबडायरेक्ट्री शामिल हैं, इन्हें आउटपुट बेस भी कहा जाता है.
पैकेज
किसी BUILD फ़ाइल से तय किए गए टारगेट का सेट. ऐप्लिकेशन
पैकेज का नाम, रेपो से जुड़ी BUILD फ़ाइल का पाथ है
रूट डालें. पैकेज में BUILD वाले सबपैकेज या सबडायरेक्ट्री शामिल हो सकते हैं
फ़ाइलें इस तरह बनाई जाती हैं, जिससे पैकेज हैरारकी बन जाती है.
पैकेज ग्रुप
पैकेज के सेट को दिखाने वाला टारगेट. आम तौर पर, visibility में इस्तेमाल किया जाता है
एट्रिब्यूट की वैल्यू सबमिट करें.
प्लैटफ़ॉर्म
"मशीन टाइप" एक बिल्ड में शामिल हैं. इसमें वे मशीन भी शामिल हैं जिन पर Basel चल रहा है ("होस्ट" प्लैटफ़ॉर्म), मशीनें बनाने वाले टूल ("exec" प्लैटफ़ॉर्म) पर एक्ज़ीक्यूट किए जाते हैं, और मशीन टारगेट ("टारगेट प्लैटफ़ॉर्म") के लिए बनाए गए हैं.
सेवा देने वाली कंपनी
स्कीमा जो जानकारी की एक यूनिट के बारे में बताती है
नियम टारगेट का डिपेंडेंसी रिलेशनशिप के साथ. आम तौर पर यह
इसमें कंपाइलर विकल्प, ट्रांज़िटिव सोर्स या आउटपुट फ़ाइलों जैसी जानकारी होती है,
और बिल्ड मेटाडेटा शामिल है. इसे अक्सर डिपसेट के साथ इस्तेमाल किया जाता है,
इकट्ठा किए गए ट्रांज़िटिव डेटा को बेहतर तरीके से सेव किया जाता है. पहले से मौजूद, सेवा देने वाली कंपनी का उदाहरण
DefaultInfo है.
यह भी देखें: सेवा देने वाले के दस्तावेज़
क्वेरी (सिद्धांत)
बिल्ड ग्राफ़ को समझने के लिए, उसके विश्लेषण की प्रोसेस target प्रॉपर्टी और डिपेंडेंसी स्ट्रक्चर. Basel तीन का समर्थन करता है क्वेरी के वैरिएंट: query, cquery, और क्वेरी.
क्वेरी (कमांड)
एक क्वेरी टूल, जो बिल्ड की पोस्ट-लोडिंग (लोडिंग) पर काम करता है
फ़ेज़ टारगेट ग्राफ़. यह बाकी सिस्टम के मुकाबले तेज़ी से काम करता है.
हालांकि, select() के असर का विश्लेषण नहीं कर सकता, फ़्लैग बनाएं,
आर्टफ़ैक्ट या कार्रवाइयां बनाना.
यह भी देखें: क्वेरी का तरीका, क्वेरी का रेफ़रंस
रिपॉज़िटरी
एक डायरेक्ट्री ट्री, जिसके रूट में सीमा मार्कर फ़ाइल मौजूद है. इसमें सोर्स शामिल है ऐसी फ़ाइलें जिनका इस्तेमाल बेज़ल बिल्ड में किया जा सकता है. आम तौर पर, इसे छोटा करके सिर्फ़ रेपो कर दिया जाता है.
रेपो बाउंड्री मार्कर की फ़ाइल, MODULE.bazel हो सकती है. इससे पता चलता है कि यह रेपो
बेज़ल मॉड्यूल, REPO.bazel या लेगसी कॉन्टेक्स्ट में WORKSPACE या
WORKSPACE.bazel. कोई भी रेपो सीमा मार्कर फ़ाइल,
repo; ऐसी कई फ़ाइलें एक डायरेक्ट्री में मौजूद हो सकती हैं.
मुख्य रेपो, वह रेपो होता है जिसमें मौजूदा बेज़ल कमांड चलाया जा रहा होता है.
MODULE.bazel में मॉड्यूल तय करके, बाहरी रिपो तय किए जाते हैं
या मॉड्यूल में रेपो नियमों को लागू करना
एक्सटेंशन. इन्हें पहले से तय किए गए समय पर, मांग पर फ़ेच किया जा सकता है
"जादुई" डिस्क पर स्थान.
हर रेपो का एक खास, लगातार कैननिकल नाम होता है और वह अलग-अलग हो सकता है किसी दूसरे डेटा स्टोर करने की जगह से देखने पर मुख्य नाम.
यह भी देखें: बाहरी डिपेंडेंसी के बारे में खास जानकारी
डेटा स्टोर करने की जगह की कैश मेमोरी
बिल्ड के लिए Basel की ओर से डाउनलोड की गई फ़ाइलों की ऐसी कैश मेमोरी, जिसे शेयर किया जा सकता है और जिसमें शामिल कॉन्टेंट को डाउनलोड किया जा सकता है,
फ़ाइल फ़ोल्डर में शेयर किया जा सकेगा. इस तारीख के बाद ऑफ़लाइन बिल्ड चालू करता है:
शुरुआती डाउनलोड. आम तौर पर, इसका इस्तेमाल डेटा स्टोर करने की जगह के ज़रिए डाउनलोड की गई फ़ाइलों को कैश मेमोरी में सेव करने के लिए किया जाता है
नियम जैसे http_archive और रिपॉज़िटरी नियम एपीआई
repository_ctx.download. फ़ाइलों को सिर्फ़ तब कैश मेमोरी में सेव किया जाता है, जब उनके SHA-256 चेकसम
डाउनलोड के लिए तय किया गया है.
डेटा स्टोर करने की जगह का नियम
रिपॉज़िटरी की परिभाषाओं के लिए स्कीमा, जो बेज़ल को मटेरियलाइज़ करने का तरीका बताता है (या
"फ़ेच") डेटा स्टोर करने की जगह होनी चाहिए. आम तौर पर, इसे छोटा करके सिर्फ़ रेपो नियम कर दिया जाता है.
Repo के नियमों का पालन करने के लिए, Basel ने सिस्टम का इस्तेमाल किया
मॉड्यूल या मॉड्यूल एक्सटेंशन की मदद से इन्हें शुरू किया जा सकता है.
रेपो के नियम, इंटरनेट को ऐक्सेस कर सकते हैं या फ़ाइल I/O कर सकते हैं; डेटा स्टोर करने की सबसे आम इन्वेंट्री
नियम http_archive है
इंटरनेट.
यह भी देखें: रिपो नियम के दस्तावेज़
दोबारा जनरेट करने की क्षमता
बिल्ड या टेस्ट की ऐसी प्रॉपर्टी जिसे बिल्ड या टेस्ट के इनपुट का सेट हर बार आउटपुट का एक ही सेट बनाते हैं, चाहे समय कुछ भी हो, तरीका कुछ भी हो, या एनवायरमेंट के हिसाब से. ध्यान दें कि इसका यह मतलब नहीं है कि आउटपुट सही या मनचाहे आउटपुट का इस्तेमाल करें.
नियम
BUILD फ़ाइल में नियम टारगेट तय करने के लिए स्कीमा
cc_library. BUILD फ़ाइल के लेखक के हिसाब से, नियम में ये शामिल होते हैं
इसमें एट्रिब्यूट और ब्लैक बॉक्स लॉजिक का सेट शामिल है. तर्क यह बताता है कि
नियम के हिसाब से टारगेट करता है कि आउटपुट आर्टफ़ैक्ट कैसे बनाए जाएं और जानकारी कैसे भेजी जाए
दूसरे नियम के टारगेट. .bzl लेखकों के हिसाब से, नियम
का इस्तेमाल करने का एक मुख्य तरीका है.
का इस्तेमाल करें.
नियमों को इस तरह इंस्टैंशिएट करके नियम के टारगेट बनाए जाते हैं लोड होने का चरण. विश्लेषण के चरण के नियम में टारगेट अपनी डाउनस्ट्रीम डिपेंडेंसी को इस तरह जानकारी देते हैं उपलब्ध कराने वालों और कार्रवाइयों को रजिस्टर करने का तरीका वे अपने आउटपुट आर्टफ़ैक्ट जनरेट करते हैं. ये कार्रवाइयां निष्पादति में की जाती हैं फ़ेज़ के बारे में जानें.
यह भी देखें: नियमों से जुड़ा दस्तावेज़
नियम का टारगेट
टारगेट, जो किसी नियम का इंस्टेंस होता है. फ़ाइल टारगेट के कंट्रास्ट में अंतर शामिल हैं. नियम न समझें.
रनफ़ाइल
एक्ज़ीक्यूटेबल टारगेट की रनटाइम डिपेंडेंसी. आम तौर पर, एक्ज़ीक्यूटेबल, किसी जाँच नियम का एक्ज़ीक्यूटेबल आउटपुट होता है और रनफ़ाइल रनटाइम होती है टेस्ट की डेटा डिपेंडेंसी. एक्ज़ीक्यूटेबल के शुरू होने से पहले (इस दौरान बेज़ल टेस्ट), Basel टेस्ट के एक्ज़ीक्यूटेबल टेस्ट के साथ-साथ रनफ़ाइल का ट्री तैयार करता है सोर्स डायरेक्ट्री के हिसाब से तय किया जाता है.
यह भी देखें: Runfiles से जुड़े दस्तावेज़
सैंडबॉक्सिंग
किसी प्रतिबंधित कार्रवाई में चल रही कार्रवाई को अलग करने की तकनीक और कुछ समय के लिए एक्ज़िक्यूशन रूट जोड़ें. इससे यह पक्का किया जाता है कि कोई गड़बड़ी न हो ऐसे इनपुट पढ़ने के लिए जिनका एलान नहीं किया गया है या ऐसे आउटपुट लिखें जो एलान न किए गए हों. सैंडबॉक्सिंग से काफ़ी बेहतर नतीजे मिलते हैं हर्मेटिकी होती है, लेकिन आम तौर पर इसमें परफ़ॉर्मेंस की लागत होती है और इसके लिए ज़रूरी है ऑपरेटिंग सिस्टम से सहायता मिलती है. परफ़ॉर्मेंस की लागत, प्लैटफ़ॉर्म के हिसाब से तय होती है. Linux पर, यह अहम नहीं है, लेकिन macOS पर इससे सैंडबॉक्सिंग काम नहीं कर सकती.
स्काईफ़्रेम
Skyframe, Bagel का मुख्य पैरलल, फ़ंक्शनल, और इंक्रीमेंटल इवैलुएशन फ़्रेमवर्क है.
छपाई का काम
Basel के बनाए गए टूल में ज़्यादा जानकारी एम्बेड करने की सुविधा
आर्टफ़ैक्ट. उदाहरण के लिए, इसका इस्तेमाल सोर्स कंट्रोल, बिल्ड
रिलीज़ के बिल्ड के लिए फ़ाइल फ़ोल्डर या पर्यावरण से जुड़ी अन्य जानकारी शामिल होती है.
--workspace_status_command फ़्लैग और नियमों के ज़रिए चालू करें
के लिए, स्टैंप एट्रिब्यूट का इस्तेमाल किया जा सकता है.
स्टारलार्क
नियम और मैक्रो लिखने के लिए एक्सटेंशन की भाषा. ऐप्लिकेशन
Python का प्रतिबंधित सबसेट (वाक्य या व्याकरण के हिसाब से), खास तौर पर
कॉन्फ़िगरेशन के लिए और बेहतर प्रदर्शन के लिए किया जा सके. .bzl का इस्तेमाल करता है
फ़ाइल एक्सटेंशन का इस्तेमाल किया जाता है. BUILD फ़ाइलें और
Starlark का प्रतिबंधित वर्शन (जैसे कि def फ़ंक्शन की कोई परिभाषा नहीं), पहले
स्काइलार्क नाम से जाना जाता है.
यह भी देखें: Starlark भाषा के दस्तावेज़
स्टार्टअप फ़्लैग
bazel और कमांड के बीच तय किए गए फ़्लैग का सेट,
उदाहरण के लिए, बेज़ल --host_jvm_debug बिल्ड. ये फ़्लैग,
कॉन्फ़िगरेशन, ताकि ज़रूरत के हिसाब से कोई भी बदलाव किया जा सके
स्टार्टअप फ़्लैग की वजह से सर्वर रीस्टार्ट होता है. स्टार्टअप फ़्लैग किसी भी चीज़ के लिए खास नहीं हैं
आदेश.
टारगेट
एक ऐसा ऑब्जेक्ट जिसकी पहचान BUILD फ़ाइल में की गई हो और जिसकी पहचान
लेबल पर टैप करें. टारगेट, वर्कस्पेस की बनाई जा सकने वाली इकाइयां दिखाते हैं
असली उपयोगकर्ता के नज़रिए से देखना.
जब किसी टारगेट को नियम को इंस्टैंशिएट करके बताया जाता है, तो उसे नियम कहा जाता है
टारगेट. नियम के आधार पर, इन्हें चलाया जा सकता है (जैसे
cc_binary) या टेस्ट करने लायक (जैसे, cc_test). नियम के टारगेट आम तौर पर इन चीज़ों पर निर्भर करते हैं
अन्य टारगेट के लिए, उनके एट्रिब्यूट (जैसे कि deps); यह
डिपेंडेंसी, टारगेट ग्राफ़ का आधार बनती है.
नियम के टारगेट के अलावा, उसमें फ़ाइल टारगेट और पैकेज ग्रुप भी हैं
टारगेट के लिए. फ़ाइल टारगेट, उन आर्टफ़ैक्ट से जुड़ा है जिनका रेफ़रंस दिया गया है
BUILD फ़ाइल में सेव हो. खास स्थिति में, किसी भी पैकेज की BUILD फ़ाइल
उस पैकेज में हमेशा सोर्स फ़ाइल का टारगेट माना जाता है.
लोड होने के चरण के दौरान टारगेट खोजे जाते हैं. इस दौरान विश्लेषण का चरण, टारगेट बिल्ड से जुड़े हैं कॉन्फ़िगरेशन बनाने के लिए कॉन्फ़िगर किया गया टारगेट तय करें.
टारगेट ग्राफ़
टारगेट और उनकी डिपेंडेंसी का इन-मेमोरी ग्राफ़. इस दौरान बनाया गया लोडिंग का चरण और इसका इस्तेमाल विश्लेषण के लिए इनपुट के तौर पर किया जाता है फ़ेज़ के लिए चुनें.
टारगेट पैटर्न
कमांड लाइन पर टारगेट का ग्रुप तय करने का तरीका. आम तौर पर
इस्तेमाल किए गए पैटर्न :all (सभी नियम टारगेट), :* (सभी नियम + फ़ाइल टारगेट) हैं
... (मौजूदा पैकेज और सभी सबपैकेज). इस्तेमाल किया जा सकता है
उदाहरण के लिए, //...:* का मतलब है, सभी नियमों और फ़ाइल टारगेट में
फ़ाइल फ़ोल्डर के रूट से बार-बार पैकेज भी लिए जाते हैं.
जांच
टेस्ट के नियमों से इंस्टैंशिएट किए गए नियम टारगेट. इसलिए, इसमें एक्ज़ीक्यूट किया जा सकता है. एक्ज़ीक्यूटेबल के पूरा होने के बाद शून्य का रिटर्न कोड टेस्ट की सफलता को दिखाता है. बेज़ल और टेस्ट के बीच का सटीक अनुबंध (जैसे कि टेस्ट एनवायरमेंट वैरिएबल, टेस्ट नतीजे इकट्ठा करने के तरीके) के बारे में जांच विश्वकोश.
टूलचेन
किसी भाषा के लिए आउटपुट बनाने वाले टूल का सेट. आम तौर पर, एक टूलचेन में कंपाइलर, लिंकर, इंटरप्रेटर या/और लिंटर. टूलचेन हर चीज़ के हिसाब से अलग-अलग हो सकती है प्लैटफ़ॉर्म का इस्तेमाल करते हैं, यानी यूनिक्स कंपाइलर टूलचेन के कॉम्पोनेंट, Windows का वैरिएंट, भले ही टूलचेन उसी भाषा के लिए हो. चुना जा रहा है इस प्लैटफ़ॉर्म के लिए सबसे सही टूलचेन को टूलचेन रिज़ॉल्यूशन कहा जाता है.
टॉप लेवल टारगेट
अगर बिल्ड टारगेट का अनुरोध Baze कमांड पर किया जाता है, तो वह टॉप-लेवल होता है
लाइन. उदाहरण के लिए, अगर //:foo, //:bar पर निर्भर है और bazel build //:foo है, तो
कॉल किया जाता है, तो इस बिल्ड के लिए //:foo टॉप-लेवल है और //:bar नहीं है
टॉप-लेवल पर सेट किया जा सकता है. हालांकि, दोनों टारगेट को बनाने की ज़रूरत होगी. एक अहम अंतर
शीर्ष-स्तरीय और गैर-शीर्ष-स्तरीय लक्ष्यों के बीच वह कमांड
फ़्लैग को बेज़ल कमांड लाइन पर (या इसके ज़रिए) सेट करें
.bazelrc), टॉप-लेवल के लिए कॉन्फ़िगरेशन सेट करेगा
टारगेट किया जाता है, लेकिन नॉन-टॉप लेवल के लिए ट्रांज़िशन की मदद से इसमें बदलाव किया जा सकता है
टारगेट के लिए.
ट्रांज़िशन
कॉन्फ़िगरेशन की स्थिति को एक वैल्यू से दूसरी वैल्यू पर मैप करना. यह बिल्ड ग्राफ़ में टारगेट को चालू करता है, ताकि कॉन्फ़िगरेशन, भले ही उन्हें एक ही नियम से इंस्टैंशिएट किया गया हो. ऐप्लिकेशन ट्रांज़िशन का सामान्य इस्तेमाल स्प्लिट ट्रांज़िशन के साथ होता है, जिसमें टारगेट ग्राफ़ को हर एक फ़ोर्क. उदाहरण के लिए, कोई व्यक्ति स्थानीय बाइनरी वाला Android APK बना सकता है जिसे ARM और x86 के लिए कंपाइल किया गया है. इसके लिए, एक बिल्ड में स्प्लिट ट्रांज़िशन का इस्तेमाल किया गया है.
यह भी देखें: उपयोगकर्ता के तय किए गए ट्रांज़िशन
पेड़ का आर्टफ़ैक्ट
एक आर्टफ़ैक्ट, जो फ़ाइलों का कलेक्शन दिखाता है. क्योंकि फ़ाइलें आर्टफ़ैक्ट नहीं होतीं, बल्कि इन पर काम करने वाली कार्रवाई होती है इसके बजाय, ट्री आर्टफ़ैक्ट को उसके इनपुट या आउटपुट के तौर पर रजिस्टर करें.
किसको दिखाई दे
बिल्ड सिस्टम में अनचाही डिपेंडेंसी को रोकने के लिए इनमें से कोई एक तरीका:
टारगेट विज़िबिलिटी, ताकि यह कंट्रोल किया जा सके कि किसी टारगेट पर भरोसा किया जा सकता है या नहीं
अन्य टारगेट के हिसाब से हो; और यह तय करने के लिए कि लोड विज़िबिलिटी कर दी गई है, क्या एक BUILD
या .bzl फ़ाइल दी गई .bzl फ़ाइल को लोड कर सकती है. आम तौर पर, बिना किसी संदर्भ के
"किसको दिखे" टारगेट विज़िबिलिटी से जुड़ी जानकारी देता है.
यह भी देखें: 'किसको दिखे' सेटिंग से जुड़ा दस्तावेज़
फ़ाइल फ़ोल्डर
सभी Basel कमांड का शेयर किया जाने वाला एनवायरमेंट, एक ही मुख्य सेवा से चलता है डेटा स्टोर करने की जगह के लिए.
ध्यान दें कि ऐतिहासिक रूप से "डेटा स्टोर करने की जगह" की अवधारणाएं और "वर्कस्पेस" जा चुके हैं मिश्रित; "workspace" शब्द इसका इस्तेमाल अक्सर मुख्य और कभी-कभी इसका इस्तेमाल "डेटा स्टोर करने की जगह" के समानार्थी के रूप में भी किया जाता है. इस तरह का इस्तेमाल साफ़ शब्दों में जानकारी देने से बचना चाहिए.