इस पेज में, Basel की मदद से प्रोग्राम बनाने, कमांड सिंटैक्स बनाने, और टारगेट पैटर्न सिंटैक्स.
क्विकस्टार्ट
Basel का इस्तेमाल करने के लिए, अपने बुनियादी फ़ाइल फ़ोल्डर की डायरेक्ट्री पर जाएं
या इसकी किसी भी सबडायरेक्ट्री और टाइप bazel को शामिल करें. बिल्ड देखें अगर
नया फ़ाइल फ़ोल्डर बनाना होगा.
bazel help
[Bazel release bazel version]
Usage: bazel command options ...
उपलब्ध निर्देश
analyze-profile: यह बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करता है.aquery: विश्लेषण के बाद के ऐक्शन ग्राफ़ पर क्वेरी लागू करता है.build: तय किए गए टारगेट बनाता है.canonicalize-flags: 'बेज़ल' फ़्लैग को कैननिकल के तौर पर मंज़ूरी दें.clean: यह आउटपुट फ़ाइलों को हटाता है और सर्वर को बंद करता है.cquery: विश्लेषण के बाद डिपेंडेंसी ग्राफ़ क्वेरी लागू करता है.dump: Basel सर्वर की प्रोसेस की अंदरूनी स्थिति को डंप करता है.help: निर्देशों या इंडेक्स के लिए प्रिंट मददगार होते हैं.info: यह बैज सर्वर के बारे में रनटाइम की जानकारी दिखाता है.fetch: किसी टारगेट की सभी बाहरी डिपेंडेंसी फ़ेच करता है.mobile-install: मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल करता है.query: यह एक डिपेंडेंसी ग्राफ़ क्वेरी लागू करता है.run: तय किए गए टारगेट को चलाता है.shutdown: Basel सर्वर को रोकता है.test: यह तय किए गए टेस्ट टारगेट बनाता और चलाता है.version: Basel के वर्शन की जानकारी प्रिंट करता है.
सहायता पाना
bazel help command: प्रिंट सहायता और इसके लिए विकल्पcommand.bazel helpstartup_options: JVM को होस्ट करने वाले Basel के विकल्प.bazel helptarget-syntax: टारगेट तय करने के सिंटैक्स के बारे में बताता है.bazel help info-keys: यह जानकारी कमांड में इस्तेमाल की गई कुंजियों की सूची दिखाता है.
bazel टूल कई काम करता है, जिन्हें कमांड कहा जाता है. सबसे ज़्यादा
इनमें से bazel build और bazel test इस्तेमाल किए गए. आप ऑनलाइन सहायता ब्राउज़ कर सकते हैं
bazel help का इस्तेमाल करके मैसेज भेजने की अनुमति दें.
एक टारगेट बनाया जा रहा है
बिल्ड बनाने से पहले, आपको वर्कस्पेस की ज़रूरत होगी. वर्कस्पेस डायरेक्ट्री ट्री जिसमें वे सभी सोर्स फ़ाइलें शामिल होती हैं जो आपके का इस्तेमाल करें. Basel आपको पूरी तरह से रीड-ओनली मोड से बिल्ड करने की सुविधा देता है वॉल्यूम.
Basel का इस्तेमाल करके कोई प्रोग्राम बनाने के लिए, bazel build टाइप करें. इसके बाद, पहले
वह टारगेट जिसे आपको बनाना है.
bazel build //foo
//foo बनाने का निर्देश देने के बाद, आपको इससे मिलता-जुलता आउटपुट दिखेगा:
INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions
सबसे पहले, Basel आपके टारगेट के डिपेंडेंसी ग्राफ़ में मौजूद सभी पैकेज को लोड करता है. यह
इसमें बताई गई डिपेंडेंसी शामिल हैं, जो टारगेट के BUILD में सीधे तौर पर लिस्ट की गई फ़ाइलें हैं
फ़ाइल, और ट्रांज़िव डिपेंडेंसी, आपकी BUILD फ़ाइलों की
टारगेट की डिपेंडेंसी. सभी डिपेंडेंसी की पहचान करने के बाद, Basel का विश्लेषण
उन्हें सही करने के लिए और बिल्ड ऐक्शन बनाता है. आख़िर में, बेज़ल चलाती हैं
बिल्ड के कंपाइलर और अन्य टूल.
बिल्ड को एक्ज़ीक्यूट करने के दौरान, Basel, प्रोग्रेस मैसेज को प्रिंट करता है. प्रोग्रेस मैसेज में मौजूदा बिल्ड चरण (जैसे कि कंपाइलर या लिंकर) शामिल होता है शुरू होता है और बिल्ड ऐक्शन की कुल संख्या में पूरा हुआ नंबर. जिस तरह बिल्ड शुरू करते हैं, तो गेम की कुल गतिविधियों की संख्या अक्सर बढ़ती जाती है, क्योंकि बेज़ल को पता चलता है कि पूरा ऐक्शन ग्राफ़ देख सकते हैं, लेकिन संख्या कुछ ही सेकंड में स्थिर हो जाती है.
बिल्ड के आखिर में, Basel के जिन टारगेट का अनुरोध किया गया था उन्हें प्रिंट करने का अनुरोध किया गया था, चाहे या
नहीं बनाए गए थे और अगर ऐसा है, तो आउटपुट फ़ाइलें
मिल गया. बिल्ड चलाने वाली स्क्रिप्ट इस आउटपुट को सही तरीके से पार्स कर सकती हैं; देखें
ज़्यादा जानकारी के लिए, --show_result.
अगर आप वही निर्देश फिर से टाइप करते हैं, तो बिल्ड ज़्यादा तेज़ी से काम करता है.
bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action
यह शून्य बिल्ड है. कोई भी बदलाव नहीं हुआ है. इसलिए, फिर से लोड करने के लिए कोई पैकेज उपलब्ध नहीं है और बिल्ड स्टेप को पूरा करने की ज़रूरत नहीं होती. अगर 'foo' में कुछ बदला गया है या इसके डिपेंडेंसी के हिसाब से, Basel की कुछ बिल्ड ऐक्शन को फिर से लागू किया जाएगा या इंक्रीमेंटल बिल्ड.
कई लक्ष्य बनाना
Baज़ल, लक्ष्यों को तय करने के कई तरीके देते हैं. सामूहिक रूप से,
इन्हें टारगेट पैटर्न कहा जाता है. इस सिंटैक्स का इस्तेमाल इन कमांड में किया जाता है
build, test या query.
हालांकि, लेबल का इस्तेमाल व्यक्तिगत पहचान बताने के लिए किया जाता है
टारगेट के लिए, जैसे कि BUILD फ़ाइलों में डिपेंडेंसी की जानकारी देने के लिए, बेज़ल का टारगेट
पैटर्न कई टारगेट को तय करते हैं. टारगेट पैटर्न,
वाइल्डकार्ड का इस्तेमाल करके, टारगेट के सेट के लिए लेबल सिंटैक्स. सबसे आसान मामले में, कोई भी
मान्य लेबल एक मान्य टारगेट पैटर्न भी है. इससे सटीक तौर पर एक के सेट की पहचान होती है
टारगेट.
// से शुरू होने वाले सभी टारगेट पैटर्न को मौजूदा पैटर्न के आधार पर हल किया जाता है
name@yourcompany.com जैसा कोई प्रोफ़ेशनल ईमेल पता बनाएं. इससे आपका कारोबार ज़्यादा भरोसेमंद बनेगा.
//foo/bar:wiz |
सिर्फ़ एक टारगेट //foo/bar:wiz. |
//foo/bar |
//foo/bar:bar के बराबर. |
//foo/bar:all |
पैकेज foo/bar में मौजूद सभी नियम टारगेट. |
//foo/... |
foo डायरेक्ट्री के नीचे मौजूद सभी पैकेज में, सभी नियम टारगेट किए जाते हैं. |
//foo/...:all |
foo डायरेक्ट्री के नीचे मौजूद सभी पैकेज में, सभी नियम टारगेट किए जाते हैं. |
//foo/...:* |
foo डायरेक्ट्री के नीचे मौजूद सभी पैकेज में सभी टारगेट (नियम और फ़ाइलें). |
//foo/...:all-targets |
foo डायरेक्ट्री के नीचे मौजूद सभी पैकेज में सभी टारगेट (नियम और फ़ाइलें). |
//... |
फ़ाइल फ़ोल्डर में मौजूद पैकेज में मौजूद सभी टारगेट. इसमें टारगेट शामिल नहीं हैं बाहरी डेटा स्टोर करने की जगहों से. |
//:all |
टॉप-लेवल पैकेज में सभी टारगेट, अगर मूल फ़ाइल फ़ोल्डर है. |
जो टारगेट पैटर्न // से शुरू नहीं होते उन्हें
मौजूदा वर्किंग डायरेक्ट्री. इन उदाहरणों में, foo की ऐक्टिव डायरेक्ट्री के बारे में बताया गया है:
:foo |
//foo:foo की तरह काम करता है. |
bar:wiz |
//foo/bar:wiz के बराबर. |
bar/wiz |
इसके बराबर:
|
bar:all |
//foo/bar:all की तरह काम करता है. |
:all |
//foo:all की तरह काम करता है. |
...:all |
//foo/...:all की तरह काम करता है. |
... |
//foo/...:all की तरह काम करता है. |
bar/...:all |
//foo/bar/...:all की तरह काम करता है. |
डिफ़ॉल्ट रूप से, बार-बार होने वाले टारगेट पैटर्न के लिए, डायरेक्ट्री सिमलिंक को फ़ॉलो किया जाता है, यह आउटपुट बेस के नीचे मौजूद होती है, जैसे कि सुविधा ऐसे सिमलिंक जो वर्कस्पेस की रूट डायरेक्ट्री में बनाए जाते हैं.
इसके अलावा, बार-बार लागू होने वाले टारगेट का आकलन करते समय, Basel ने सिमलिंक को फ़ॉलो नहीं किया
पैटर्न, जिसमें इस तरह की फ़ाइल होती है:
DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
foo/..., पैकेज पर एक वाइल्डकार्ड है. यह सभी पैकेज को बार-बार दिखाता है
foo डायरेक्ट्री के नीचे (पैकेज पाथ के सभी रूट के लिए). :all
टारगेट पर वाइल्डकार्ड, जो पैकेज में मौजूद सभी नियमों से मेल खाता है. ये दोनों
मिलाना, जैसा कि foo/...:all में है और जब दोनों वाइल्डकार्ड का इस्तेमाल किया जाता है, तो यह
foo/... का छोटा रूप होता है.
इसके अलावा, :* (या :all-targets) एक वाइल्डकार्ड है, जो हर टारगेट से मेल खाता है
मैच होने वाले पैकेज में, ऐसी फ़ाइलें भी शामिल होती हैं जिन्हें आम तौर पर किसी नियम के तहत नहीं बनाया जाता.
जैसे, java_binary नियमों से जुड़ी _deploy.jar फ़ाइलें.
इसका मतलब है कि :*, :all का सुपरसेट दिखाता है; हो सकता है
भ्रम की स्थिति पैदा करने वाला सिंटैक्स है. यह सिंटैक्स :all वाइल्डकार्ड के इस्तेमाल की अनुमति देता है
सामान्य बिल्ड, जिनमें _deploy.jar जैसे बिल्डिंग टारगेट की ज़रूरत नहीं होती.
इसके अलावा, Basel, उसके लिए ज़रूरी कोलन के बजाय एक स्लैश का इस्तेमाल करने की अनुमति देता है
लेबल सिंटैक्स; Bash फ़ाइल नाम एक्सपैंशन का इस्तेमाल करते समय, यह तरीका अक्सर आसान होता है.
उदाहरण के लिए, foo/bar/wiz, //foo/bar:wiz के बराबर है (अगर कोई हो
पैकेज foo/bar) या //foo:bar/wiz तक (अगर पैकेज foo हो).
कई Basel कमांड में टारगेट पैटर्न की सूची को आर्ग्युमेंट के तौर पर इस्तेमाल किया जाता है. ये सभी कमांड, टारगेट पैटर्न की सूची को आर्ग्युमेंट के तौर पर इस्तेमाल करते हैं
प्रीफ़िक्स निगेशन ऑपरेटर - को लागू करें. इसका इस्तेमाल, वैल्यू के सेट को घटाने के लिए किया जा सकता है
पिछले आर्ग्युमेंट के ज़रिए तय किए गए सेट से टारगेट. ध्यान दें कि इसका मतलब
ऑर्डर मायने रखता है. उदाहरण के लिए,
bazel build foo/... bar/...
इसका मतलब है, "सभी टारगेट foo से कम बनाएं और सभी टारगेट bar से कम बनाएं", जबकि
bazel build -- foo/... -foo/bar/...
इसका मतलब है, "foo/bar से नीचे वाले टारगेट को छोड़कर foo से नीचे के सभी टारगेट बनाएं". (
- से शुरू होने वाले बाद के आर्ग्युमेंट को रोकने के लिए, -- आर्ग्युमेंट की ज़रूरत होती है
अतिरिक्त विकल्पों के तौर पर न देखा जा सके.)
हालांकि, यह बताना ज़रूरी है कि इस तरीके से टारगेट घटाने से
इसकी गारंटी नहीं है कि इन्हें बनाया नहीं गया है, क्योंकि हो सकता है कि ये टारगेट पर निर्भर हों
जिन्हें कम नहीं किया गया. उदाहरण के लिए, अगर टारगेट //foo:all-apis होता
जो अन्य संगठनों के लिए //foo/bar:api पर निर्भर करती हैं. बाद वाले मॉडल को इस तरह बनाया जाएगा
एक हिस्सा है.
tags = ["manual"] वाले टारगेट, वाइल्डकार्ड टारगेट पैटर्न में शामिल नहीं किए गए हैं
(..., :*, :all वगैरह) जब इस तरह के निर्देशों में तय किया गया हो
bazel build और bazel test (लेकिन वे
नेगेटिव वाइल्डकार्ड टारगेट पैटर्न, यानी उन्हें घटा दिया जाएगा). आपको ऐसा करना चाहिए
कमांड लाइन पर ऐसे टेस्ट टारगेट के बारे में साफ़ तौर पर बताएं जो
तो आपको बेज़ेल को उनका निर्माण/जांच कराना होगा. इसके उलट, bazel query काम नहीं करता
ऐसी किसी भी प्रकार की फ़िल्टरिंग अपने आप (जिससे
bazel query).
बाहरी डिपेंडेंसी फ़ेच की जा रही है
डिफ़ॉल्ट रूप से, Basel,
बिल्ड. हालांकि, ऐसा कुछ इसलिए हो सकता है, क्योंकि आपके समाचार संगठन के पास
नई बाहरी डिपेंडेंसी जोड़े जाते हैं या आपको
"प्रीफ़ेच" डिपेंडेंसी (जैसे, उस फ़्लाइट से पहले जिसमें आप ऑफ़लाइन होंगे). अगर आपको
चाहते हैं कि बिल्ड के दौरान नई डिपेंडेंसी न जोड़ी जाएं, तो
--fetch=false फ़्लैग की जानकारी दे सकता है. ध्यान दें कि सिर्फ़ इस फ़्लैग
ऐसे डेटा स्टोर करने की जगह के नियमों पर लागू होता है जो स्थानीय
फ़ाइल सिस्टम. उदाहरण के लिए, local_repository में किए गए बदलाव,
new_local_repository और Android SDK और NDK रिपॉज़िटरी के नियम
--fetch वैल्यू पर ध्यान दिए बिना, हमेशा लागू होगी .
अगर बिल्ड के दौरान फ़ेच करने की अनुमति नहीं दी जाती है और Basel को नए बाहरी सोर्स के बारे में पता चलता है, तो निर्भर नहीं करता है, तो आपका बिल्ड विफल हो जाएगा.
bazel fetch चलाकर, डिपेंडेंसी को मैन्युअल तरीके से फ़ेच किया जा सकता है. अगर आपने
आप बिल्ड- फ़ेच करने के दौरान अनुमति नहीं देते हैं, तो आपको bazel fetch चलाना होगा:
- पहली बार बनाने से पहले.
- नई बाहरी डिपेंडेंसी जोड़ने के बाद.
एक बार चलाने के बाद, आपको इसे तब तक फिर से चलाने की ज़रूरत नहीं पड़ेगी जब तक workspace फ़ाइल में किए गए बदलाव.
fetch उन टारगेट की सूची लेता है जिनके लिए डिपेंडेंसी फ़ेच करनी है. इसके लिए
उदाहरण के लिए, इससे //foo:bar बनाने के लिए ज़रूरी डिपेंडेंसी फ़ेच हो जाएगी
और //bar:baz:
bazel fetch //foo:bar //bar:baz
किसी वर्कस्पेस की सभी बाहरी डिपेंडेंसी फ़ेच करने के लिए, इसे चलाएं:
bazel fetch //...
Basel 7.1 या बाद के वर्शन के साथ, अगर आपने Bzlmod मोड को चालू किया हुआ है, तो आप सभी को फ़ेच भी कर सकते हैं बाहरी डिपेंडेंसी को चलाकर देखें
bazel fetch
अगर आपके पास अपने सभी टूल हैं, तो आपको बेज़ल फ़ेच चलाने की कोई ज़रूरत नहीं है
इस्तेमाल करें (लाइब्रेरी जार से लेकर JDK तक).
हालांकि, अगर Workspace डायरेक्ट्री के बाहर का कुछ भी इस्तेमाल किया जा रहा है, तो Bagel का इस्तेमाल करें
चलने से पहले, bazel fetch अपने-आप चलेगा
bazel build.
डेटा स्टोर करने की जगह की कैश मेमोरी
Baज़ल एक ही फ़ाइल को कई बार फ़ेच करने से बचने की कोशिश करता है, भले ही
फ़ाइल की ज़रूरत अलग-अलग फ़ाइल फ़ोल्डर में हो या फिर बाहरी
डेटा स्टोर करने की जगह बदल गई है, लेकिन डाउनलोड करने के लिए अब भी उसी फ़ाइल की ज़रूरत है. ऐसा करने के लिए,
बेज़ल, रिपॉज़िटरी कैश मेमोरी में डाउनलोड की गई सभी फ़ाइलों को कैश मेमोरी में सेव करता है. इसमें डिफ़ॉल्ट रूप से,
~/.cache/bazel/_bazel_$USER/cache/repos/v1/ पर है. कॉन्टेंट बनाने
--repository_cache विकल्प का इस्तेमाल करके, जगह की जानकारी बदली जा सकती है. कॉन्टेंट बनाने
कैश मेमोरी को सभी फ़ाइल फ़ोल्डर और बेज़ल के इंस्टॉल किए गए वर्शन के बीच शेयर किया जाता है.
कैश मेमोरी से एंट्री ली जाती है, अगर
बेज़ल यह पक्का जानते हैं कि उसके पास सही फ़ाइल की कॉपी है, यानी कि अगर
डाउनलोड अनुरोध में बताई गई फ़ाइल का SHA256 योग है और उसके साथ एक फ़ाइल
हैश कैश मेमोरी में मौजूद है. इसलिए, हर बाहरी फ़ाइल के लिए हैश तय करना
सुरक्षा के लिहाज़ से यह एक अच्छा आइडिया है. साथ ही, आपको अपने डेटा को
ग़ैर-ज़रूरी डाउनलोड.
कैश मेमोरी में सेव होने वाले हर हिट पर, कैश मेमोरी में फ़ाइल में बदलाव का समय होता है अपडेट किया गया. इस तरह, कैश डायरेक्ट्री में किसी फ़ाइल का आखिरी बार इस्तेमाल करने पर, तय किया जा सकता है, जैसे कि कैश मेमोरी को मैन्युअल तरीके से हटाने के लिए. कैश मेमोरी कभी भी अपने-आप साफ़ हो जाता है, क्योंकि इसमें ऐसी फ़ाइल की कॉपी हो सकती है जो ज़्यादा देर तक उपलब्ध रहेगा.
डिस्ट्रिब्यूशन फ़ाइल डायरेक्ट्री
डिस्ट्रिब्यूशन डायरेक्ट्री की मदद से, किसी भी तरह की डाउनलोड. Baज़र, डेटा स्टोर करने की जगह की कैश मेमोरी से पहले, डिस्ट्रिब्यूशन डायरेक्ट्री खोजता है. मुख्य अंतर यह है कि डिस्ट्रिब्यूशन डायरेक्ट्री को इस्तेमाल करने के लिए, मैन्युअल तैयारी करने के लिए किया जा सकता है.
इसका उपयोग करके
--distdir=/path/to-directory
विकल्प है, तो आप फ़ाइलों को खोजने के लिए अतिरिक्त रीड-ओनली निर्देशिकाएं
का इस्तेमाल करने के लिए प्रेरित किया जा सकता है. ऐसी डायरेक्ट्री से फ़ाइल ली जाती है, अगर फ़ाइल का नाम
यूआरएल के मूल नाम के बराबर है और इसके अलावा फ़ाइल का हैश भी है
जो डाउनलोड के अनुरोध में बताई गई वैल्यू के बराबर होती है. यह केवल तब काम करता है जब
फ़ाइल हैश की जानकारी वर्कस्पेस की जानकारी में दी गई है.
फ़ाइल के नाम में दी गई शर्त सही होने के लिए ज़रूरी नहीं है, लेकिन हर बताई गई डायरेक्ट्री के लिए, उम्मीदवार फ़ाइलों की संख्या को एक कर देता है. इसमें इस तरीके से, डिस्ट्रिब्यूशन फ़ाइल डायरेक्ट्री तय करना कुशल रहता है, भले ही फ़ाइलों की संख्या बहुत ज़्यादा बढ़ जाती है.
एयरगेप्ड माहौल में बेज़ल दौड़ते हुए
Basel की बाइनरी साइज़ को छोटा रखने के लिए, Basel की इंप्लिसिट डिपेंडेंसी फ़ेच की जाती हैं को पूरी तरह से बंद करें. ये इंप्लिसिट डिपेंडेंसी ऐसे टूलचेन और नियम शामिल होने चाहिए जो सभी के लिए ज़रूरी न हों. इसके लिए उदाहरण के लिए, Android के टूल सिर्फ़ Android बनाते समय ही इकट्ठा नहीं किए जाते और फ़ेच किए जाते हैं प्रोजेक्ट.
हालांकि, ये इंप्लिसिट डिपेंडेंसी, रन करते समय समस्या पैदा कर सकती हैं एयरगेप वाले एनवायरमेंट में बेज़ल, भले ही आपने अपने पूरे वेंडर वर्कस्पेस डिपेंडेंसी. इसे हल करने के लिए, एक डिस्ट्रिब्यूशन डायरेक्ट्री तैयार करें नेटवर्क ऐक्सेस वाली मशीन पर इन डिपेंडेंसी को शामिल करना चाहिए, और फिर ये ऐप्लिकेशन उन्हें ऑफ़लाइन तरीके से एयरगेप किए गए एनवायरमेंट में ट्रांसफ़र कर सकते हैं.
डिस्ट्रिब्यूशन डायरेक्ट्री तैयार करने के लिए,
--distdir
फ़्लैग करें. आपको हर नए Basel बाइनरी वर्शन के लिए ऐसा एक बार करना होगा, क्योंकि
इंप्लिसिट डिपेंडेंसी हर रिलीज़ के लिए अलग-अलग हो सकती है.
अपने एयरगेप किए गए एनवायरमेंट के बाहर इन डिपेंडेंसी को बनाने के लिए, सबसे पहले सही वर्शन में बेज़ल सोर्स ट्री की चेकआउट करें:
git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"cd "$BAZEL_DIR"git checkout "$BAZEL_VERSION"
इसके बाद, ऐसी टारबॉल बनाएं जिसमें उसके लिए इंप्लिसिट रनटाइम डिपेंडेंसी मौजूद हों खास तौर पर Basel का वर्शन:
bazel build @additional_distfiles//:archives.tar
इस टारबॉल को किसी ऐसी डायरेक्ट्री में एक्सपोर्ट करें जिसे आपके एयरगेप में कॉपी किया जा सके
पर्यावरण को ध्यान में रखते हुए काम करना. --strip-components फ़्लैग को नोट करें, क्योंकि --distdir
डायरेक्ट्री नेस्टिंग स्तर के साथ काफ़ी जटिल:
tar xvf bazel-bin/external/additional_distfiles/archives.tar \
-C "$NEW_DIRECTORY" --strip-components=3
आखिर में, अपने एयरगेप किए गए एनवायरमेंट में Basel का इस्तेमाल करते समय, --distdir को पास करें
फ़्लैग जो डायरेक्ट्री की ओर इशारा करता है. सुविधा के लिए, इसे .bazelrc के तौर पर जोड़ा जा सकता है
एंट्री:
build --distdir=path/to/directory
कॉन्फ़िगरेशन और क्रॉस-कंपाइलेशन बनाएं
किसी बिल्ड के व्यवहार और उसके नतीजे के बारे में बताने वाले सभी इनपुट ऐसे हो सकते हैं
ये दो अलग-अलग कैटगरी में बंटे होते हैं. पहला टाइप इंट्रिनसिक है
आपके प्रोजेक्ट की BUILD फ़ाइलों में सेव की गई जानकारी: बिल्ड रूल,
इसके एट्रिब्यूट की वैल्यू और इसकी ट्रांज़िटिव डिपेंडेंसी का पूरा सेट.
दूसरा प्रकार बाहरी या पर्यावरण संबंधी डेटा है, जिसे उपयोगकर्ता या
बिल्ड टूल की मदद से: टारगेट आर्किटेक्चर, कंपाइलेशन, और लिंकिंग
और अन्य टूलचेन कॉन्फ़िगरेशन विकल्पों की जानकारी मिल सकती है. हम एक पूरे सेट से
पर्यावरण से जुड़े डेटा को कॉन्फ़िगरेशन के तौर पर शामिल करना.
किसी भी बिल्ड में, एक से ज़्यादा कॉन्फ़िगरेशन हो सकते हैं. इसके लिए,
क्रॉस-कंपाइल, जिसमें 64-बिट के लिए //foo:bin एक्ज़ीक्यूटेबल बनाया जाता है
जबकि आपका वर्कस्टेशन एक 32-बिट मशीन है. साफ़ तौर पर, इस बिल्ड में
//foo:bin बनाने के लिए ऐसे टूलचेन का इस्तेमाल करना ज़रूरी है जो 64-बिट बनाने में सक्षम हो
एक्ज़ीक्यूटेबल, लेकिन बिल्ड सिस्टम को
से बना है—उदाहरण के लिए, वे टूल जो सोर्स से बने हैं और बाद में
का इस्तेमाल सामान्य मशीन में किया जाता है—और इन्हें आपके वर्कस्टेशन पर चलाने के लिए बनाया जाना चाहिए. इस प्रकार
हम दो कॉन्फ़िगरेशन की पहचान कर सकते हैं: exec कॉन्फ़िगरेशन, जिसका इस्तेमाल किया जाता है
बिल्ड के दौरान चलने वाले टूल बनाने और टारगेट कॉन्फ़िगरेशन की
(या कॉन्फ़िगरेशन का अनुरोध करें, लेकिन हम "टारगेट कॉन्फ़िगरेशन" को अक्सर
हालांकि, उस शब्द के पहले से ही कई मतलब हैं), जिसका इस्तेमाल
आपके अनुरोध पर बाइनरी का अनुरोध किया गया.
आम तौर पर, ऐसी कई लाइब्रेरी होती हैं जिन पर अनुरोध करने के लिए, पहले से ज़रूरी शर्तें पूरी की जाती हैं
बिल्ड टारगेट (//foo:bin) और एक या उससे ज़्यादा exec टूल, जैसे कि कुछ
बेस लाइब्रेरी. ऐसी लाइब्रेरी दो बार बनाई जानी चाहिए, एक बार exec के लिए
एक बार इस्तेमाल किया जा सकता है. बेज़ल इस बात का ध्यान रखते हैं
पक्का करना कि दोनों वैरिएंट बनाए गए हैं और जो फ़ाइलें बनाई गई हैं उन्हें सेव रखा गया है
किसी भी तरह की रुकावट से बचने के लिए, आम तौर पर, ऐसे टारगेट एक ही समय पर बनाए जा सकते हैं.
क्योंकि वे एक-दूसरे से अलग हैं. अगर आपको प्रोग्रेस से जुड़े मैसेज दिखते हैं
यह दिखाता है कि टारगेट को दो बार बनाया जा रहा है. ऐसे में,
करें.
निष्पादन कॉन्फ़िगरेशन को लक्ष्य कॉन्फ़िगरेशन से इस प्रकार प्राप्त किया जाता है:
- क्रॉसटूल (
--crosstool_top) के उसी वर्शन का इस्तेमाल करें जो इसमें बताया गया है कॉन्फ़िगरेशन का अनुरोध करता है, जब तक कि--host_crosstool_topतय न किया गया हो. --cpuके लिए--host_cpuके मान का इस्तेमाल करें (डिफ़ॉल्ट:k8).- इन विकल्पों की उन ही वैल्यू का इस्तेमाल करें जो अनुरोध में बताई गई हैं
कॉन्फ़िगरेशन:
--compiler,--use_ijars, और अगर--host_crosstool_topहै का इस्तेमाल किया है, तो--host_cpuके मान का उपयोग एक्ज़िक्यूटिव के लिए क्रॉसटूल मेंdefault_toolchain(--compilerको अनदेखा करते हुए) कॉन्फ़िगरेशन. --javabaseके लिए--host_javabaseवैल्यू का इस्तेमाल करें--java_toolchainके लिए--host_java_toolchainवैल्यू का इस्तेमाल करें- C++ कोड (
-c opt) के लिए ऑप्टिमाइज़ किए गए बिल्ड का इस्तेमाल करें. - डीबग करने की कोई जानकारी जनरेट नहीं करें (
--copt=-g0). - एक्ज़ीक्यूटेबल और शेयर की गई लाइब्रेरी से डीबग करने की जानकारी को निकालें
(
--strip=always). - सभी व्युत्पन्न फ़ाइलों को एक खास जगह पर रखें, जो यहां इस्तेमाल की गई फ़ाइलों से अलग हो अनुरोध को कॉन्फ़िगर कर सकते हैं.
- बिल्ड डेटा वाली बाइनरी पर स्टैंप लगाने की प्रोसेस बंद करें (
--embed_*विकल्प देखें). - अन्य सभी वैल्यू अपनी डिफ़ॉल्ट वैल्यू पर सेट रहती हैं.
किसी दूसरे एक्ज़िक्यूटिव को चुनना बेहतर होने की कई वजहें हो सकती हैं अनुरोध के कॉन्फ़िगरेशन से मिला कॉन्फ़िगरेशन. सबसे ज़रूरी चीज़ें:
सबसे पहले, स्ट्रिप्ड, ऑप्टिमाइज़ की गई बाइनरी का इस्तेमाल करके, विज्ञापन देखने में लगने वाले समय को कम किया जाता है टूल को लिंक करने और एक्ज़ीक्यूट करने से जुड़ा डेटा, टूल से लिए गए डिस्क स्पेस, और डिस्ट्रिब्यूट किए गए बिल्ड में नेटवर्क I/O टाइम.
दूसरे, exec को अलग करके और सभी बिल्ड में कॉन्फ़िगरेशन का अनुरोध करके, आपको बहुत महंगे रीबिल्ड से बचना होगा, जिसकी वजह से कॉन्फ़िगरेशन का अनुरोध करता है (जैसे लिंकर के विकल्प को बदलना), जैसा बताया गया है. .
सही इंक्रीमेंटल रीबिल्ड
बेज़ल प्रोजेक्ट का एक मुख्य लक्ष्य यह पक्का करना है कि सही तरीके से बढ़ोतरी हो कारोबार में बढ़ोतरी होती है. पहले से बनाए गए बिल्ड टूल, खास तौर पर वे टूल जो बना रहे हैं. हमारे प्लैटफ़ॉर्म पर पहले से इंंक्रीमेंटल बिल्ड को लागू करने में गलत अनुमानों के बारे में बताया गया है.
सबसे पहले, फ़ाइलों के टाइमस्टैंप एक ही तरह से बढ़ जाते हैं. हालांकि, यह आम तौर पर, इस आकलन से दूर रहना बहुत आसान है; एक फ़ाइल में पहले के संशोधन से फ़ाइल के संशोधन का समय कम हो जाता है; मेक-आधारित सिस्टम फिर से नहीं बनाए जाएंगे.
आम तौर पर, जब Create फ़ाइलों में हुए बदलावों का पता लगाता है, तो यह बदलावों का पता नहीं लगाता
भी शामिल कर देते हैं. अगर किसी दिए गए बिल्ड में कंपाइलर को दिए गए विकल्पों में बदलाव किया जाता है
चरण पूरा न करें, तो बनाएं, कंपाइलर को फिर से नहीं चलाएगा और इसे मैन्युअल रूप से खारिज करना ज़रूरी है
make clean का इस्तेमाल करने वाले पिछले बिल्ड के अमान्य आउटपुट.
साथ ही, किसी एक तरह के प्लैटफ़ॉर्म के बंद होने पर, Make की टीम मज़बूत नहीं है सबप्रोसेस शुरू होने के बाद, आउटपुट फ़ाइल पर लिखना शुरू हो जाता है. हालांकि फ़िलहाल, Make की प्रोसेस पूरी नहीं हो पाएगी और इसके बाद, Make की सुविधा को इस्तेमाल किया जा सकेगा आंख बंद करके मान लें कि छोटी की गई आउटपुट फ़ाइल मान्य है (क्योंकि यह इससे नई है इसके इनपुट शामिल हैं और उन्हें फिर से नहीं बनाया जाएगा. इसी तरह, अगर बनाएं प्रोसेस नहीं रहे हैं, तो ऐसी ही स्थिति हो सकती है.
बेज़ल इन अनुमानों और अन्य अनुमानों से बचते हैं. बेज़ल सभी का एक डेटाबेस रखते हैं काम पहले ही कर लिया है और बिल्ड चरण को सिर्फ़ तभी छोड़ देगा, जब उसे पता चल जाएगा कि इनपुट फ़ाइलों (और उनके टाइमस्टैंप) से उस चरण को पूरा करने में मदद मिलेगी. कमांड देता है, डेटाबेस में मौजूद किसी एक से एग्ज़ैक्ट मैच करता है, और यह कि डेटाबेस एंट्री के लिए आउटपुट फ़ाइलों का सेट (और उनके टाइमस्टैंप) पूरी तरह मेल खाते हैं डिस्क पर फ़ाइलों के टाइमस्टैंप. इनपुट फ़ाइलों या आउटपुट में किया जाने वाला कोई भी बदलाव फ़ाइलों या कमांड के लिए, बिल्ड चरण को फिर से लागू करेगा.
सही इंक्रीमेंटल बिल्ड के इस्तेमाल से लोगों को यह फ़ायदा मिलेगा: नीचे दी गई वजहों से कम समय बर्बाद होता है
भ्रम है. (साथ ही, make
clean के इस्तेमाल की वजह से इमारत को फिर से बनाने में लगने वाले इंतज़ार में कम समय लगता है, चाहे वह ज़रूरी हो या पहले से.)
एक जैसा अनुभव देकर, अपने कॉन्टेंट को लगातार बेहतर बनाएं
औपचारिक तौर पर, हम बिल्ड की स्थिति को एक जैसा के तौर पर तब परिभाषित करते हैं, जब आउटपुट फ़ाइलें मौजूद हों और उनकी सामग्री सही हो, जैसा कि उन्हें बनाने के लिए ज़रूरी नियम हैं. जब आप कोई स्रोत फ़ाइल संपादित करते हैं, तो बिल्ड को अनियमित कहा जाता है और जब तक अगली बार नहीं चलाया जाता, तब तक यह असंगत रहता है बिल्ड टूल को सही तरीके से पूरा करने में मदद करता है. हम इस स्थिति को अस्तबल: में बदलाव नहीं होता, क्योंकि यह सिर्फ़ कुछ समय के लिए होता है. साथ ही, बनाने वाले टूल का इस्तेमाल करने के बारे में ज़्यादा जानें.
हालांकि, एक और तरह की गड़बड़ी है जो नुकसान पहुंचाने वाली है: स्टेबल
जानकारी अलग-अलग हो सकती है. अगर बिल्ड लगातार अलग-अलग स्थिति तक पहुंच जाता है, तो फिर यह प्रक्रिया दोहराई जाती है
बिल्ड टूल को सही तरीके से शुरू करने पर, एक जैसी क्वालिटी का डेटा वापस नहीं आता: बिल्ड
"अटक" गया हो और आउटपुट गलत हो. स्थिर और अलग-अलग स्थितियां
इसकी मुख्य वजह है कि लोग, Make (और अन्य बिल्ड टूल) make clean टाइप का इस्तेमाल करते हैं.
यह पता लगाना कि बिल्ड टूल इस तरीके से काम नहीं कर रहा है और फिर से ठीक हो रहा है
होने में समय लग सकता है और इससे बहुत परेशानी हो सकती है.
सैद्धांतिक तौर पर, एक जैसी बनावट पाने का सबसे आसान तरीका है, कुछ समय के लिए प्रोजेक्ट को छोड़ना सभी पिछले बिल्ड आउटपुट चुनकर फिर से शुरू करें: हर बिल्ड को एक क्लीन बिल्ड बनाएं. व्यावहारिक तौर पर यह तरीका अपनाने में बहुत समय लगता है. हालांकि, इसमें सिर्फ़ रिलीज़ इंजीनियर के लिए है), और इसलिए उपयोगी होने के लिए, बिल्ड टूल का इस्तेमाल करें.
इंक्रीमेंटल डिपेंडेंसी का विश्लेषण करना मुश्किल होता है. जैसा कि ऊपर बताया गया है, कई और अन्य बिल्ड टूल, गड़बड़ी की वजह से लगातार एक जैसी स्थिति से बचने में मदद करते हैं इंक्रीमेंटल बिल्ड वहीं, Basel की टीम को यह गारंटी मिलती है: बिल्ड टूल को शुरू किया हो जिसके दौरान आपने कोई बदलाव न किया हो, बिल्ड एक जैसी स्थिति में होगा. (अगर आप बनाने के लिए करते हैं, तो Ba हटाना, मौजूदा बिल्ड. हालांकि, इससे यह गारंटी मिलती है कि अगले बिल्ड के नतीजे मिलेंगे एक जैसा अनुभव पाएं.)
जैसा कि सभी गारंटी के साथ होता है, उसके कुछ अच्छे प्रिंट भी होते हैं: ऐसे कुछ तरीके ज्ञात तरीके हैं बेज़ल के साथ एक स्थिर रूप से अलग स्थिति में आने से. हम इस बात की गारंटी नहीं देते कि ऐसी समस्याओं की जांच कर सकते हैं जो इंक्रीमेंटल डिपेंडेंसी का विश्लेषण किया जाएगा, लेकिन हम इसकी जांच करेंगे और उसे ठीक करने की पूरी कोशिश करेंगे सामान्य या "सही" स्थिति से पैदा होने वाली गड़बड़ियों की लगातार स्थिति का इस्तेमाल बिल्ड टूल.
अगर आपको कभी Babel के साथ स्थिर और असंगत स्थिति का पता चलता है, तो कृपया एक बग की रिपोर्ट करें.
सैंडबॉक्स किया गया एक्ज़ीक्यूशन
बेज़ल, सैंडबॉक्स का इस्तेमाल करके यह गारंटी देते हैं कि हर गतिविधि हरमेटिक तरीके से हो और
सही तरीके से. Basel ने सैंडबॉक्स में स्पॉन्स (कम शब्दों में जानकारी देना: कार्रवाइयां) चलाया
इसमें सिर्फ़ उन फ़ाइलों का सेट शामिल होता है जिनकी ज़रूरत टूल को काम करने के लिए होती है. इस समय
सैंडबॉक्स, CONFIG_USER_NS विकल्प के साथ Linux 3.12 या इसके बाद के वर्शन पर काम करता है
चालू है और macOS 10.11 या इसके बाद के वर्शन पर भी काम करता है.
अगर चेतावनी देने के लिए, आपके सिस्टम पर सैंडबॉक्सिंग की सुविधा काम नहीं करती, तो Bagel एक चेतावनी प्रिंट करेगा
आपको इस बात की गारंटी नहीं है कि बिल्ड हर्मेटिक होगी और
होस्ट सिस्टम को अज्ञात तरीकों से करता है. इस चेतावनी को बंद करने के लिए,
बेज़ल के लिए --ignore_unsupported_sandboxing फ़्लैग.
Google Kubernetes जैसे कुछ प्लैटफ़ॉर्म पर
इंजन क्लस्टर नोड या Debian,
सुरक्षा की वजह से, उपयोगकर्ता नेमस्पेस को डिफ़ॉल्ट रूप से बंद कर दिया जाता है
समस्याएं हल करें. फ़ाइल को देखकर इसकी जांच की जा सकती है
/proc/sys/kernel/unprivileged_userns_clone: अगर यह मौजूद है और इसमें 0 है, तो
तो उपयोगकर्ता नेमस्पेस को इनके साथ चालू किया जा सकता है:
sudo sysctl kernel.unprivileged_userns_clone=1.
कुछ मामलों में, सिस्टम की वजह से Baज़ल सैंडबॉक्स, नियमों को लागू नहीं कर पाता
सेटअप. आम तौर पर, लक्षण की वजह से ऐसा मैसेज नहीं दिखता है जो
namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory.
ऐसे मामले में, जेन रूल के लिए सैंडबॉक्स को बंद करने की कोशिश करें
--strategy=Genrule=standalone और इसके साथ अन्य नियमों के लिए
--spawn_strategy=standalone. साथ ही, कृपया इस गड़बड़ी की शिकायत करें
समस्या को ट्रैक करने वाला टूल सेट करें और बताएं कि आपका कौनसा Linux डिस्ट्रिब्यूशन इस्तेमाल किया जा रहा है. इससे हम
जांच करें और आने वाली रिलीज़ में समाधान उपलब्ध कराएं.
बिल्ड के चरण
Basel में, बिल्ड तीन अलग-अलग फ़ेज़ में होता है; आने वाले समय में, इनके बीच के अंतर से उन विकल्पों की अहम जानकारी मिलती है जो बिल्ड को कंट्रोल करते हैं (नीचे देखें).
लोड होने का चरण
पहली फ़ाइल लोड हो रही है, जिसमें फ़ाइल फ़ोल्डर के लिए सभी ज़रूरी बिल्ड फ़ाइलें शामिल होती हैं लोड होते हैं और उनकी डिपेंडेंसी के ट्रांज़िशन की प्रोसेस पूरी होती है. पार्स, मूल्यांकन किया गया, और कैश मेमोरी में सेव किया गया.
Basel सर्वर के चालू होने के बाद पहले बिल्ड के लिए, आम तौर पर लोडिंग का चरण फ़ाइल सिस्टम से कई BUILD फ़ाइलें लोड होने में कई सेकंड लगते हैं. तय सीमा में बाद के बिल्ड, खासकर अगर BUILD फ़ाइलों में बदलाव नहीं होता है, तो लोड होता है तुरंत मिल जाता है.
इस चरण के दौरान रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: पैकेज नहीं मिला, टारगेट नहीं मिला, BUILD फ़ाइल में लेक्सिकल और व्याकरण से जुड़ी गड़बड़ियां, और इवैलुएशन से जुड़ी गड़बड़ियां.
विश्लेषण का चरण
दूसरे चरण, विश्लेषण में सिमैंटिक विश्लेषण और पुष्टि की प्रोसेस शामिल होती है हर बिल्ड नियम, बिल्ड डिपेंडेंसी ग्राफ़ बनाने, और यह तय किया जा सकता है कि बिल्ड के हर चरण में क्या काम करना है.
लोड होने की तरह ही, विश्लेषण में भी पूरी प्रोसेस लगने में कुछ सेकंड लगते हैं. हालांकि, Baze, डिपेंडेंसी ग्राफ़ को एक बिल्ड से दूसरे में सिर्फ़ कैश मेमोरी में सेव करता है अपनी मौजूदा ज़रूरतों का फिर से विश्लेषण करता है. इससे इंक्रीमेंटल बिल्ड बहुत तेज़ी से यह ऐसा मामला है जिसमें पिछले बिल्ड के बाद से पैकेज में कोई बदलाव नहीं हुआ है.
इस चरण में रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: डिपेंडेंसी गलत है और अमान्य है किसी नियम के इनपुट और नियम में खास तौर पर हुई गड़बड़ी के सभी मैसेज शामिल हैं.
लोड होने और विश्लेषण करने के चरण तेज़ होते हैं, क्योंकि Basel की वजह से गै़र-ज़रूरी फ़ाइल डाउनलोड नहीं होती इस चरण पर I/O, सिर्फ़ बिल्ड फ़ाइलों को पढ़ रहा है, ताकि यह तय किया जा सके कि किस काम को हो गया. यह डिज़ाइन को ध्यान में रखकर बनाया गया है. इसी वजह से, बैजल विश्लेषण करने में मदद करने वाले टूल के लिए एक अच्छा आधार बन गया है. जैसे कि बेज़ल का query कमांड, जो लोडिंग पेज के ऊपर लागू होता है फ़ेज़.
प्लान लागू करने का चरण
बिल्ड का तीसरा और आखिरी चरण लागू करना है. इस चरण में यह पक्का होता है कि बिल्ड के हर चरण के आउटपुट, इनपुट के हिसाब से होते हैं. इसलिए, इन्हें फिर से चलाना कंपाइलेशन/लिंकिंग/वगैरह. टूल का इस्तेमाल किया जा सकता है. इस चरण में, बिल्ड पर खर्च होता है आम तौर पर, यह समय कुछ सेकंड से लेकर एक घंटे से ज़्यादा समय में बिल्ड. इस चरण के दौरान रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: सोर्स फ़ाइलें मौजूद नहीं हैं और गड़बड़ियां किसी टूल की मदद से एक्ज़ीक्यूट किया जाता है. आउटपुट का अपेक्षित सेट.