इस पेज पर, Bazel की मदद से प्रोग्राम बनाने, बिल्ड कमांड सिंटैक्स, और टारगेट पैटर्न सिंटैक्स के बारे में बताया गया है.
क्विकस्टार्ट
Bazel को चलाने के लिए, अपनी बेस workspace डायरेक्ट्री या उसकी किसी भी सब-डायरेक्ट्री पर जाएं और bazel टाइप करें. अगर आपको नया फ़ाइल फ़ोल्डर बनाना है, तो build देखें.
bazel help
[Bazel release bazel version]
Usage: bazel command options ...उपलब्ध निर्देश
analyze-profile: बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करता है.aquery: विश्लेषण के बाद ऐक्शन ग्राफ़ पर क्वेरी लागू करता है.build: तय किए गए टारगेट बनाता है.canonicalize-flags: 'बेज़ल' फ़्लैग को कैननिकल के तौर पर मंज़ूरी दें.clean: आउटपुट फ़ाइलें हटाता है और सर्वर को बंद कर देता है.cquery: डिपेंडेंसी ग्राफ़ की विश्लेषण के बाद की जाने वाली क्वेरी को लागू करता है.dump: Basel सर्वर की प्रोसेस की इंटरनल स्थिति को खारिज करता है.help: निर्देशों या इंडेक्स के लिए सहायता प्रिंट करता है.info: bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है.fetch: किसी टारगेट की सभी बाहरी डिपेंडेंसी फ़ेच करता है.mobile-install: मोबाइल डिवाइसों पर ऐप्लिकेशन इंस्टॉल करता है.query: डिपेंडेंसी ग्राफ़ क्वेरी को लागू करता है.run: तय किए गए टारगेट को चलाता है.shutdown: Basel सर्वर को रोकता है.test: यह टूल, तय किए गए टेस्ट टारगेट को बनाता और चलाता है.version: Basel के वर्शन की जानकारी प्रिंट करता है.
सहायता पाना
bazel help command: प्रिंट सहायता औरcommandके लिए विकल्प.bazel helpstartup_options: Bazel को होस्ट करने वाले JVM के विकल्प.bazel helptarget-syntax: टारगेट तय करने के सिंटैक्स के बारे में बताता है.bazel help info-keys: यह जानकारी कमांड में इस्तेमाल की गई कुंजियों की सूची दिखाता है.
bazel टूल कई फ़ंक्शन करता है. इन्हें निर्देश कहा जाता है. आम तौर पर,
bazel build और bazel test इस्तेमाल होते हैं. bazel help का इस्तेमाल करके, ऑनलाइन सहायता के मैसेज ब्राउज़ किए जा सकते हैं.
एक टारगेट बनाया जा रहा है
बिल्ड बनाने से पहले, आपको वर्कस्पेस की ज़रूरत होगी. वर्कस्पेस एक डायरेक्ट्री ट्री होता है. इसमें आपके ऐप्लिकेशन को बनाने के लिए ज़रूरी सभी सोर्स फ़ाइलें होती हैं. Bazel की मदद से, पूरी तरह रीड-ओनली वाले वॉल्यूम से भी बिल्ड किया जा सकता है.
Bazel की मदद से प्रोग्राम बनाने के लिए, 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
सबसे पहले, Bazel आपके टारगेट के डिपेंडेंसी ग्राफ़ में सभी पैकेज लोड करता है. इसमें एलान की गई डिपेंडेंसी शामिल हैं. ये फ़ाइलें, टारगेट की BUILD फ़ाइल में सीधे तौर पर शामिल होती हैं. साथ ही, इसमें ट्रांज़िशन डिपेंडेंसी भी शामिल हैं. ये फ़ाइलें, टारगेट की डिपेंडेंसी की BUILD फ़ाइलों में शामिल होती हैं. सभी डिपेंडेंसी की पहचान करने के बाद, BaZ चैनल उनका विश्लेषण
करते हैं और उनके सही होने की जांच करते हैं. साथ ही, बिल्ड ऐक्शन बनाते हैं. आखिर में, Bazel, बाइल्ड के कंपाइलर और अन्य टूल इस्तेमाल करता है.
बिल्ड के एक्सीक्यूशन फ़ेज़ के दौरान, Bazel प्रोग्रेस मैसेज प्रिंट करता है. प्रोग्रेस मैसेज में, बने प्रोग्राम के मौजूदा चरण (जैसे, कंपाइलर या लिंकर) के शुरू होने की जानकारी शामिल होती है. साथ ही, बने प्रोग्राम की कुल कार्रवाइयों में से पूरी की गई कार्रवाइयों की संख्या भी शामिल होती है. बिल्ड शुरू होने पर, अक्सर कुल कार्रवाइयों की संख्या बढ़ जाती है. ऐसा इसलिए होता है, क्योंकि Bazel पूरे ऐक्शन ग्राफ़ का पता लगाता है. हालांकि, कुछ सेकंड में यह संख्या स्थिर हो जाती है.
बिल्ड के आखिर में, Bazel यह जानकारी दिखाता है कि किन टारगेट का अनुरोध किया गया था, वे बिल्ड हुए या नहीं, और अगर बिल्ड हुए हैं, तो आउटपुट फ़ाइलें कहां मिल सकती हैं. बिल्ड चलाने वाली स्क्रिप्ट, इस आउटपुट को भरोसेमंद तरीके से पार्स कर सकती हैं. ज़्यादा जानकारी के लिए, --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' या उसकी डिपेंडेंसी में कोई बदलाव होता है, तो Bazel कुछ बिल्ड ऐक्शन फिर से चलाएगा या इंक्रीमेंटल बिल्ड पूरा करेगा.
कई लक्ष्य बनाना
Baज़ल, लक्ष्यों को तय करने के कई तरीके देते हैं. इन्हें एक साथ, टारगेट पैटर्न कहा जाता है. इस सिंटैक्स का इस्तेमाल build, test या query जैसे निर्देशों में किया जाता है.
जहां लेबल का इस्तेमाल अलग-अलग टारगेट की जानकारी देने के लिए किया जाता है, जैसे कि BUILD फ़ाइलों में डिपेंडेंसी का एलान करने के लिए, वहीं बेज़ल के टारगेट पैटर्न एक से ज़्यादा टारगेट के बारे में बताते हैं. टारगेट पैटर्न, वाइल्डकार्ड का इस्तेमाल करके टारगेट के सेट के लिए लेबल सिंटैक्स का सामान्यीकरण है. सबसे सामान्य स्थिति में, कोई भी मान्य लेबल एक मान्य टारगेट पैटर्न होता है. इससे सिर्फ़ एक टारगेट के सेट की पहचान की जाती है.
// से शुरू होने वाले सभी टारगेट पैटर्न का समाधान, मौजूदा फ़ाइल फ़ोल्डर के हिसाब से किया जाता है.
//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 |
अगर वर्कस्पेस के रूट में `BUILD` फ़ाइल मौजूद है, तो टॉप-लेवल पैकेज के सभी टारगेट. |
// से शुरू न होने वाले टारगेट पैटर्न, मौजूदा वर्किंग डायरेक्ट्री के हिसाब से हल किए जाते हैं. इन उदाहरणों में, 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 के बराबर. |
डिफ़ॉल्ट रूप से, बार-बार इस्तेमाल होने वाले टारगेट पैटर्न के लिए, डायरेक्ट्री के सिमलिंक का इस्तेमाल किया जाता है. हालांकि, उन सिमलिंक के लिए ऐसा नहीं किया जाता जो आउटपुट बेस में मौजूद होते हैं. जैसे, Workspace की रूट डायरेक्ट्री में बनाए गए सिमलिंक.
इसके अलावा, ऐसी किसी भी डायरेक्ट्री में बार-बार लागू होने वाले टारगेट पैटर्न का आकलन करते समय, Bagel सिमलिंक को फ़ॉलो नहीं करता है जिसमें इस तरह की फ़ाइल होती है:
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 जैसे टारगेट बनाने की ज़रूरत न हो.
इसके अलावा, लेबल सिंटैक्स के लिए ज़रूरी कोलन के बजाय, स्लैश का इस्तेमाल किया जा सकता है. Bash फ़ाइल नाम को बड़ा करने की सुविधा का इस्तेमाल करते समय, यह अक्सर सुविधाजनक होता है.
उदाहरण के लिए, foo/bar/wiz, //foo/bar:wiz (अगर पैकेज foo/bar है) या //foo:bar/wiz (अगर पैकेज foo है) के बराबर है.
Bazel के कई निर्देश, आर्ग्युमेंट के तौर पर टारगेट पैटर्न की सूची स्वीकार करते हैं. साथ ही, ये सभी निर्देश, प्रीफ़िक्स नेगेटिव ऑपरेटर - का इस्तेमाल करते हैं. इसका इस्तेमाल, पिछले आर्ग्युमेंट से तय किए गए सेट से, टारगेट के किसी सेट को घटाने के लिए किया जा सकता है. ध्यान दें कि इसका मतलब है कि क्रम का ध्यान रखना ज़रूरी है. उदाहरण के लिए,
bazel build foo/... bar/...इसका मतलब है, "सभी टारगेट foo से कम बनाएं और सभी टारगेट bar से कम बनाएं", जबकि
bazel build -- foo/... -foo/bar/...इसका मतलब है, "foo से नीचे दिए गए सभी टारगेट बनाएं. हालांकि, foo/bar से नीचे दिए गए टारगेट को छोड़कर, ऐसा किया जा सकता है. (- से शुरू होने वाले अगले आर्ग्युमेंट को अतिरिक्त विकल्पों के तौर पर शामिल होने से रोकने के लिए, -- आर्ग्युमेंट ज़रूरी है.)
हालांकि, यह बताना ज़रूरी है कि इस तरह से टारगेट घटाने से, यह गारंटी नहीं मिलेगी कि वे बिल्ट नहीं किए गए हैं. ऐसा इसलिए, क्योंकि वे उन टारगेट की डिपेंडेंसी हो सकते हैं जिन्हें घटाया नहीं गया था. उदाहरण के लिए, अगर कोई टारगेट //foo:all-apis था, जो //foo/bar:api पर निर्भर था, तो //foo/bar:api को //foo:all-apis बनाने के हिस्से के तौर पर बनाया जाएगा.
bazel build और bazel test जैसे निर्देशों में बताए गए होने पर, tags = ["manual"] वाले टारगेट वाइल्डकार्ड टारगेट पैटर्न (..., :*, :all वगैरह) में शामिल नहीं किए जाते. अगर आपको Baज़ल को बिल्ड/टेस्ट करना है, तो आपको कमांड लाइन पर साफ़ टारगेट पैटर्न के साथ ऐसे टेस्ट टारगेट तय करने चाहिए. इसके उलट, bazel query अपने-आप ऐसा कोई फ़िल्टर नहीं करता. ऐसा करने से, bazel query का मकसद पूरा नहीं होगा.
बाहरी डिपेंडेंसी फ़ेच करना
डिफ़ॉल्ट रूप से, Bazel, बिल्ड के दौरान बाहरी डिपेंडेंसी डाउनलोड और लिंक करेगा. हालांकि, ऐसा करना ज़रूरी नहीं है. ऐसा इसलिए, क्योंकि आपको यह जानना हो सकता है कि नई बाहरी डिपेंडेंसी कब जोड़ी गईं या आपको डिपेंडेंसी को "प्रीफ़ेच" करना हो. उदाहरण के लिए, किसी ऐसी फ़्लाइट से पहले जो ऑफ़लाइन होगी. अगर आपको
बिल्ड के दौरान नई डिपेंडेंसी को जोड़ना है, तो आपके पास
--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 //...अगर आपके पास अपने वर्कस्पेस रूट में, इस्तेमाल किए जा रहे सभी टूल (लाइब्रेरी के jar से लेकर JDK तक) मौजूद हैं, तो आपको bazel fetch को चलाने की ज़रूरत नहीं है.
हालांकि, अगर Workspace डायरेक्ट्री के बाहर का कुछ इस्तेमाल किया जा रहा है, तो Basel, bazel build चलाने से पहले bazel fetch को अपने-आप चलाएगा.
रिपॉज़िटरी कैश मेमोरी
Bazel, एक ही फ़ाइल को कई बार फ़ेच करने से बचने की कोशिश करता है. भले ही, अलग-अलग वर्कस्पेस में एक ही फ़ाइल की ज़रूरत हो या किसी बाहरी रिपॉज़िटरी की परिभाषा बदल गई हो, लेकिन उसे डाउनलोड करने के लिए अब भी उसी फ़ाइल की ज़रूरत हो. ऐसा करने के लिए,
bazel, डाउनलोड की गई सभी फ़ाइलों को रिपॉज़िटरी कैश में कैश मेमोरी में सेव करता है. यह कैश मेमोरी डिफ़ॉल्ट रूप से ~/.cache/bazel/_bazel_$USER/cache/repos/v1/ में मौजूद होती है. --repository_cache विकल्प की मदद से, जगह बदली जा सकती है. कैश मेमोरी को सभी फ़ाइल फ़ोल्डर और बेज़ल के इंस्टॉल किए गए वर्शन के बीच शेयर किया जाता है.
कैश मेमोरी से कोई एंट्री तब ली जाती है, जब Bazel को पता हो कि उसके पास सही फ़ाइल की कॉपी है. इसका मतलब है कि अगर डाउनलोड अनुरोध में, बताई गई फ़ाइल का SHA256 योग है और उस हैश वाली फ़ाइल कैश मेमोरी में मौजूद है. इसलिए, हर बाहरी फ़ाइल के लिए हैश तय करना, सुरक्षा के लिहाज़ से ही नहीं, बल्कि ग़ैर-ज़रूरी डाउनलोड से बचने के लिए भी एक अच्छा आइडिया है.
कैश मेमोरी में हर बार हिट होने पर, कैश मेमोरी में मौजूद फ़ाइल में किए गए बदलाव का समय अपडेट हो जाता है. इस तरह, कैश मेमोरी की डायरेक्ट्री में मौजूद किसी फ़ाइल के आखिरी इस्तेमाल का पता आसानी से लगाया जा सकता है. उदाहरण के लिए, कैश मेमोरी को मैन्युअल तरीके से खाली करने के लिए. कैश मेमोरी कभी भी अपने-आप नहीं मिटती, क्योंकि इसमें ऐसी फ़ाइल की कॉपी हो सकती है जो अब अपस्ट्रीम में उपलब्ध नहीं है.
डिस्ट्रिब्यूशन फ़ाइलों की डायरेक्ट्री
डिस्ट्रिब्यूशन डायरेक्ट्री, Bazel का एक और तरीका है. इसका इस्तेमाल, ग़ैर-ज़रूरी डाउनलोड से बचने के लिए किया जाता है. Bazel, रिपॉज़िटरी कैश से पहले डिस्ट्रिब्यूशन डायरेक्ट्री खोजता है. मुख्य अंतर यह है कि डिस्ट्रिब्यूशन डायरेक्ट्री को मैन्युअल तरीके से तैयार करना पड़ता है.
--distdir=/path/to-directory विकल्प का इस्तेमाल करके, फ़ाइलों को फ़ेच करने के बजाय, उन्हें देखने के लिए, सिर्फ़ पढ़ने के लिए उपलब्ध अन्य डायरेक्ट्री तय की जा सकती हैं. ऐसी डायरेक्ट्री से किसी फ़ाइल को तब लिया जाता है, जब उसका नाम, यूआरएल के बेस नाम के बराबर होता है. इसके अलावा, फ़ाइल का हैश, डाउनलोड अनुरोध में दिए गए नाम के बराबर होता है. यह सिर्फ़ तब काम करता है, जब WORKSPACE एलान में फ़ाइल हैश की जानकारी दी गई हो.
फ़ाइल के नाम की शर्त को सही बनाने के लिए ज़रूरी नहीं है. हालांकि, इससे हर डायरेक्ट्री के लिए, फ़ाइलों की संख्या एक हो जाती है. इस तरीके से, डिस्ट्रिब्यूशन फ़ाइल डायरेक्ट्री की जानकारी देना असरदार रहता है, भले ही ऐसी डायरेक्ट्री में फ़ाइलों की संख्या बड़ी हो जाए.
एयरगैप वाले एनवायरमेंट में Bazel को चलाना
Bazel के बाइनरी साइज़ को छोटा रखने के लिए, पहली बार चलाने के दौरान, Bazel की लागू डिपेंडेंसी को नेटवर्क से फ़ेच किया जाता है. इन डिपेंडेंसी में ऐसे टूलचेन और नियम शामिल होते हैं जो शायद सभी के लिए ज़रूरी न हों. उदाहरण के लिए, Android टूल सिर्फ़ तब अनबंड किए जाते हैं और फ़ेच किए जाते हैं, जब Android प्रोजेक्ट बनाए जाते हैं.
हालांकि, इन छिपी हुई डिपेंडेंसी की वजह से, एयरगैप वाले एनवायरमेंट में Bazel को चलाने में समस्याएं आ सकती हैं. भले ही, आपने अपनी सभी WORKSPACE डिपेंडेंसी को वेंडर के तौर पर जोड़ लिया हो. इस समस्या को हल करने के लिए, नेटवर्क ऐक्सेस वाली मशीन पर, इन डिपेंडेंसी वाली डिस्ट्रिब्यूशन डायरेक्ट्री तैयार की जा सकती है. इसके बाद, उन्हें ऑफ़लाइन तरीके से एयरगैप वाले एनवायरमेंट में ट्रांसफ़र किया जा सकता है.
डिस्ट्रिब्यूशन डायरेक्ट्री तैयार करने के लिए, --distdir फ़्लैग का इस्तेमाल करें. आपको हर नए Bazel बाइनरी वर्शन के लिए, ऐसा एक बार करना होगा. ऐसा इसलिए, क्योंकि हर रिलीज़ के लिए, इंप्लिसिट डिपेंडेंसी अलग-अलग हो सकती हैं.
अपने एयरगैप किए गए एनवायरमेंट के बाहर इन डिपेंडेंसी को बनाने के लिए, सबसे पहले सही वर्शन में Bazel सोर्स ट्री को चेक आउट करें:
git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"cd "$BAZEL_DIR"git checkout "$BAZEL_VERSION"
इसके बाद, उस खास Bazel वर्शन के लिए, रनटाइम की लागू डिपेंडेंसी वाला टार्बॉल बनाएं:
bazel build @additional_distfiles//:archives.tarइस टार्बॉल को ऐसी डायरेक्ट्री में एक्सपोर्ट करें जिसे आपके एयरगैप किए गए एनवायरमेंट में कॉपी किया जा सके. --strip-components फ़्लैग पर ध्यान दें, क्योंकि --distdir डायरेक्ट्री नेस्टिंग लेवल के साथ काफ़ी मुश्किल हो सकता है:
tar xvf bazel-bin/external/additional_distfiles/archives.tar \
-C "$NEW_DIRECTORY" --strip-components=3आखिर में, अपने एयरगैप किए गए एनवायरमेंट में Bazel का इस्तेमाल करते समय, डायरेक्ट्री पर ले जाने वाला --distdir
फ़्लैग पास करें. आसानी के लिए, इसे .bazelrc
एंट्री के तौर पर जोड़ा जा सकता है:
build --distdir=path/to/directoryबिल्ड कॉन्फ़िगरेशन और क्रॉस-कंपाइलेशन
किसी खास बिल्ड के व्यवहार और नतीजे की जानकारी देने वाले सभी इनपुट को दो अलग-अलग कैटगरी में बांटा जा सकता है. पहली तरह की जानकारी, आपके प्रोजेक्ट की BUILD फ़ाइलों में सेव की गई खास जानकारी होती है: बिल्ड नियम, उसके एट्रिब्यूट की वैल्यू, और ट्रांज़िशन डेपेंडेंसी का पूरा सेट.
दूसरा टाइप, बाहरी या पर्यावरण से जुड़ा डेटा है, जो उपयोगकर्ता या बिल्ड टूल से मिलता है: टारगेट आर्किटेक्चर, कंपाइलेशन और लिंकिंग
के विकल्प, और टूलचेन कॉन्फ़िगरेशन के अन्य विकल्प. हम पर्यावरण से जुड़े डेटा के पूरे सेट को कॉन्फ़िगरेशन कहते हैं.
किसी भी बिल्ड में, एक से ज़्यादा कॉन्फ़िगरेशन हो सकते हैं. क्रॉस-कंपाइल करने के बारे में सोचें. इसमें, 64-बिट आर्किटेक्चर के लिए //foo:bin एक्ज़ीक्यूटेबल बनाया जाता है, लेकिन आपका वर्कस्टेशन 32-बिट मशीन है. साफ़ तौर पर, बिल्ड के लिए //foo:bin को ऐसे टूलचेन का इस्तेमाल करके बनाना होगा जो 64-बिट के रन किए जा सकने वाले प्रोग्राम बना सके. हालांकि, बिल्ड सिस्टम को बिल्ड के दौरान इस्तेमाल किए जाने वाले अलग-अलग टूल भी बनाने होंगे. उदाहरण के लिए, ऐसे टूल जिन्हें सोर्स से बनाया जाता है और फिर किसी genrule में इस्तेमाल किया जाता है. साथ ही, इन्हें आपके वर्कस्टेशन पर चलाने के लिए बनाना होगा. इसलिए, हम दो कॉन्फ़िगरेशन की पहचान कर सकते हैं: exec कॉन्फ़िगरेशन, जिसका इस्तेमाल बिल्ड के दौरान चलने वाले टूल बनाने के लिए किया जाता है और टारगेट कॉन्फ़िगरेशन (या रिक्वेस्ट कॉन्फ़िगरेशन, लेकिन हम अक्सर "टारगेट कॉन्फ़िगरेशन" कहते हैं, भले ही उस शब्द के कई मतलब पहले से ही हों), जिसका इस्तेमाल उस बाइनरी को बनाने के लिए किया जाता है जिसका आपने आखिर में अनुरोध किया था.
आम तौर पर, ऐसी कई लाइब्रेरी होती हैं जो अनुरोध किए गए बाइल्ड टारगेट (//foo:bin) और एक या एक से ज़्यादा टूल, जैसे कि कुछ बेस लाइब्रेरी, दोनों के लिए ज़रूरी होती हैं. ऐसी लाइब्रेरी को एक्ज़ेक्यूटिव और टारगेट कॉन्फ़िगरेशन के लिए कई बार बनाया जाना चाहिए. Bazel यह पक्का करता है कि सभी वैरिएंट बनाए जाएं और इंटरफ़ियरेंस से बचने के लिए, डेरिव्ड फ़ाइलों को अलग रखा जाए. आम तौर पर, ऐसे टारगेट एक साथ बनाए जा सकते हैं, क्योंकि वे एक-दूसरे से अलग होते हैं. अगर आपको प्रोग्रेस से जुड़े मैसेज दिखते हैं, जो बताते हैं कि कोई टारगेट कई बार बनाया जा रहा है, तो हो सकता है कि इसी वजह से यह मैसेज बना हो.
टारगेट कॉन्फ़िगरेशन से, exec कॉन्फ़िगरेशन इस तरह बनाया जाता है:
- अनुरोध टारगेट के लिए इस्तेमाल किया गया प्लैटफ़ॉर्म, टारगेट कॉन्फ़िगरेशन के लिए टारगेट प्लैटफ़ॉर्म बन जाता है.
- जब तक
--host_crosstool_topन बताया गया हो, तब तक क्रॉसटूल (--crosstool_top) के उसी वर्शन का इस्तेमाल करें जिसे अनुरोध के कॉन्फ़िगरेशन में बताया गया है. --cpuके लिए--host_cpuकी वैल्यू का इस्तेमाल करें (डिफ़ॉल्ट:k8).- अनुरोध कॉन्फ़िगरेशन में बताई गई वैल्यू का इस्तेमाल करें:
--compiler,--use_ijars. अगर--host_crosstool_topका इस्तेमाल किया जाता है, तो होस्ट कॉन्फ़िगरेशन के लिए, क्रॉसटूल मेंdefault_toolchainको खोजने के लिए--host_cpuकी वैल्यू का इस्तेमाल किया जाता है (--compilerको अनदेखा किया जाता है). --javabaseके लिए--host_javabaseकी वैल्यू का इस्तेमाल करें--java_toolchainके लिए--host_java_toolchainवैल्यू का इस्तेमाल करें- C++ कोड (
-c opt) के लिए ऑप्टिमाइज़ किए गए बिल्ड का इस्तेमाल करें. - डीबग करने से जुड़ी कोई जानकारी जनरेट न करें (
--copt=-g0). - रन किए जा सकने वाले प्रोग्राम और शेयर की गई लाइब्रेरी से डीबग की जानकारी हटाएं (
--strip=always). - सभी डेरिव्ड फ़ाइलों को किसी खास जगह पर रखें. यह जगह, अनुरोध के किसी भी संभावित कॉन्फ़िगरेशन से अलग होनी चाहिए.
- बिल्डर डेटा के साथ बाइनरी को स्टैंप करने की सुविधा बंद करें (
--embed_*विकल्प देखें). - अन्य सभी वैल्यू अपनी डिफ़ॉल्ट वैल्यू पर सेट रहती हैं.
इंक्रीमेंटल रीबिल्ड को ठीक करना
Bazel प्रोजेक्ट का एक मुख्य लक्ष्य, यह पक्का करना है कि इंक्रीमेंटल रीबिल्ड सही तरीके से हो. पहले के बिल्ड टूल, खास तौर पर वे टूल जो Make पर आधारित होते हैं, इंक्रीमेंटल बिल्ड को लागू करने के बारे में कई गलत अनुमान लगाते हैं.
सबसे पहले, फ़ाइलों के टाइमस्टैंप एक ही तरह से बढ़ जाते हैं. हालांकि, यह आम तौर पर होता है, लेकिन इस धारणा को गलत साबित करना बहुत आसान है. किसी फ़ाइल के पुराने वर्शन के साथ सिंक करने पर, उस फ़ाइल में बदलाव करने में लगने वाला समय कम हो जाता है. साथ ही, Make पर आधारित सिस्टम, फ़ाइल को फिर से नहीं बनाएंगे.
आम तौर पर, Make फ़ाइलों में हुए बदलावों का पता लगाता है, लेकिन निर्देशों में हुए बदलावों का पता नहीं लगाता. अगर किसी बिल्ड चरण में, कंपाइलर को पास किए गए विकल्पों में बदलाव किया जाता है, तो Make कंपाइलर को फिर से नहीं चलाएगा. साथ ही, make clean का इस्तेमाल करके, पिछले बिल्ड के अमान्य आउटपुट को मैन्युअल तरीके से खारिज करना ज़रूरी है.
साथ ही, बनाएं कि सबप्रोसेस अपनी आउटपुट फ़ाइल पर लिखना शुरू कर देने के बाद, किसी एक सबप्रोसेस को बंद नहीं किया जा सकता. Make का मौजूदा वर्शन काम नहीं करेगा. हालांकि, Make का अगला वर्शन, काट-छांट की गई आउटपुट फ़ाइल को मान्य मान लेगा, क्योंकि यह अपने इनपुट से नई है. साथ ही, इसे फिर से नहीं बनाया जाएगा. इसी तरह, अगर Make प्रोसेस को बंद कर दिया जाता है, तो भी ऐसा ही हो सकता है.
Bazel, इन और अन्य अनुमान से बचता है. Bazel, पहले किए गए सभी काम का डेटाबेस बनाए रखता है. यह किसी बिल्ड चरण को सिर्फ़ तब छोड़ेगा, जब उसे पता चलेगा कि उस बिल्ड चरण के इनपुट फ़ाइलों (और उनके टाइमस्टैंप) का सेट और उस बिल्ड चरण के कंपाइलेशन कमांड, डेटाबेस में मौजूद किसी एक से पूरी तरह मैच करते हैं. साथ ही, डेटाबेस एंट्री के आउटपुट फ़ाइलों (और उनके टाइमस्टैंप) का सेट, डिस्क पर मौजूद फ़ाइलों के टाइमस्टैंप से पूरी तरह मैच करता है. इनपुट फ़ाइलों या आउटपुट फ़ाइलों में या कमांड में किए जाने वाले किसी भी बदलाव की वजह से, बिल्ड चरण फिर से लागू होगा.
सही इंक्रीमेंटल बिल्ड का इस्तेमाल करने से, उपयोगकर्ताओं को ये फ़ायदे मिलते हैं: भ्रम की वजह से कम समय बर्बाद होता है. (इसके अलावा, make
clean का इस्तेमाल करने पर, रीबिल्ड होने में लगने वाला समय भी कम हो जाता है. भले ही, रीबिल्ड करना ज़रूरी हो या पहले से तय किया गया हो.)
नियमित तौर पर वीडियो बनाते रहें और लगातार बढ़ाएं
औपचारिक तौर पर, जब सभी अनुमानित आउटपुट फ़ाइलें मौजूद होती हैं और उनका कॉन्टेंट सही होता है, तो बिल्ड की स्थिति एक जैसी के तौर पर होती है. यह स्थिति, उन्हें बनाने के ज़रूरी चरणों या नियमों में बताई गई होती है. किसी सोर्स फ़ाइल में बदलाव करने पर, बिल्ड की स्थिति असमान हो जाती है. यह स्थिति तब तक बनी रहती है, जब तक कि बिल्ड टूल को फिर से चलाकर बिल्ड पूरा नहीं हो जाता. हम इस स्थिति को अस्थिरी के साथ होने वाला बदलाव कहते हैं, क्योंकि यह सिर्फ़ कुछ समय के लिए होता है. साथ ही, बिल्ड टूल को चलाने पर, यह स्थिति फिर से पहले जैसी हो जाती है.
एक और तरह की गड़बड़ी भी होती है, जो नुकसान पहुंचा सकती है: लगातार एक जैसी गड़बड़ी. अगर बिल्ड बिना किसी गड़बड़ी के स्थायी स्थिति तक पहुंच जाता है, तो बिल्ड टूल को बार-बार शुरू करने से वह कंसिस्टेंसी वापस नहीं आती: बिल्ड "अटके हुए" हो जाता है और आउटपुट गलत रहते हैं. स्थिर और अलग-अलग स्थितियां, Make (और अन्य बिल्ड टूल) के उपयोगकर्ताओं को make clean टाइप करने की मुख्य वजह हैं.
यह पता लगाना कि बिल्ड टूल इस तरह से काम नहीं कर रहा है और फिर उससे ठीक होना, समय लेने वाला और बहुत परेशान करने वाला हो सकता है.
कॉन्सेप्ट के हिसाब से, एक जैसा बिल्ड पाने का सबसे आसान तरीका यह है कि पिछले सभी बिल्ड आउटपुट को हटाकर, फिर से शुरू करें: हर बिल्ड को क्लीन बिल्ड बनाएं. यह तरीका, शायद रिलीज़ इंजीनियर के अलावा, किसी और के लिए काम का नहीं है. ऐसा इसलिए है, क्योंकि इसमें काफ़ी समय लगता है. इसलिए, यह ज़रूरी है कि बिल्ड टूल, एक जैसी परफ़ॉर्मेंस बनाए रखते हुए, इंक्रीमेंटल बिल्ड कर सके.
इंक्रीमेंटल डिपेंडेंसी का सही विश्लेषण करना मुश्किल है. जैसा कि ऊपर बताया गया है, कई अन्य बिल्ड टूल, इंक्रीमेंटल बिल्ड के दौरान स्थिर और गलत स्टेटस से बचने के लिए खराब तरीके से काम करते हैं. इसके उलट, Bazel इस बात की गारंटी देता है: बगैर किसी बदलाव के, बाइल्ड टूल को इस्तेमाल करने के बाद, बाइल्ड एक जैसा रहेगा. (अगर किसी बिल्ड के दौरान सोर्स फ़ाइलों में बदलाव किया जाता है, तो Bazel इस बात की कोई गारंटी नहीं देता कि मौजूदा बिल्ड का नतीजा एक जैसा होगा. हालांकि, इससे यह गारंटी मिलती है कि अगले बिल्ड के नतीजों से, एक जैसी परफ़ॉर्मेंस वापस आ जाएगी.)
सभी गारंटी की तरह ही, इसमें भी कुछ शर्तें होती हैं: Bazel के साथ, स्टेबल और गैर-स्टेबल स्थिति में जाने के कुछ तरीके हैं. हम इस बात की गारंटी नहीं देते कि हम उन समस्याओं की जांच करेंगे जो जान-बूझकर, इंक्रीमेंटल डिपेंडेंसी विश्लेषण में गड़बड़ियां ढूंढने की कोशिश करने से होती हैं. हालांकि, हम बिल्ड टूल के सामान्य या "उचित" इस्तेमाल से होने वाली सभी समस्याओं की जांच करेंगे और उन्हें ठीक करने की पूरी कोशिश करेंगे.
अगर आपको कभी Bazel में स्टेबल स्टेटस में कोई गड़बड़ी दिखती है, तो कृपया गड़बड़ी की शिकायत करें.
सैंडबॉक्स में चलाने की सुविधा
बेज़ल, सैंडबॉक्स का इस्तेमाल करके यह गारंटी देते हैं कि कार्रवाइयां सही तरीके से और सही तरीके से की जाएं. Bazel, सैंडबॉक्स में स्पैन (आम तौर पर: कार्रवाइयां) चलाता है. इन सैंडबॉक्स में, सिर्फ़ उन फ़ाइलों का कम से कम सेट होता है जिनकी ज़रूरत टूल को अपना काम करने के लिए होती है. फ़िलहाल, सैंडबॉक्सिंग की सुविधा, CONFIG_USER_NS विकल्प चालू होने पर, Linux 3.12 या इसके बाद के वर्शन पर काम करती है. साथ ही, यह macOS 10.11 या इसके बाद के वर्शन पर भी काम करती है.
अगर आपका सिस्टम सैंडबॉक्सिंग की सुविधा के साथ काम नहीं करता है, तो Bazel आपको चेतावनी देगा. इससे आपको यह पता चलेगा कि बिल्ड के पूरी तरह से सुरक्षित होने की कोई गारंटी नहीं है और होस्ट सिस्टम पर इनका असर पड़ सकता है. इस चेतावनी को बंद करने के लिए, आपके पास
--ignore_unsupported_sandboxing फ़्लैग को Basel को भेजने का विकल्प है.
Google Kubernetes
Engine क्लस्टर नोड या Debian जैसे प्लैटफ़ॉर्म पर, सुरक्षा से जुड़ी समस्याओं की वजह से उपयोगकर्ता नेमस्पेस को डिफ़ॉल्ट रूप से बंद कर दिया जाता है. इसकी जांच करने के लिए, /proc/sys/kernel/unprivileged_userns_clone फ़ाइल देखें: अगर यह मौजूद है और इसमें 0 है, तो sudo sysctl kernel.unprivileged_userns_clone=1 की मदद से उपयोगकर्ता नेमस्पेस चालू किए जा सकते हैं.
कुछ मामलों में, सिस्टम सेटअप की वजह से Bazel सैंडबॉक्स, नियमों को लागू नहीं कर पाता. आम तौर पर, गड़बड़ी का पता तब चलता है, जब namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory जैसा मैसेज दिखता है.
ऐसे मामले में, जनरेटिव नियम के लिए --strategy=Genrule=standalone और दूसरे नियमों के लिए --spawn_strategy=standalone के साथ सैंडबॉक्स को बंद करने की कोशिश करें. कृपया हमारे समस्या ट्रैकर पर भी गड़बड़ी की शिकायत करें. साथ ही, यह भी बताएं कि आपने कौनसा Linux डिस्ट्रिब्यूशन इस्तेमाल किया है, ताकि हम इसकी जांच कर सकें और अगली रिलीज़ में इसे ठीक कर सकें.
बिल्ड के चरण
Bazel में, बिल्ड तीन अलग-अलग चरणों में होता है. उपयोगकर्ता के तौर पर, इनके बीच के अंतर को समझने से, बिल्ड को कंट्रोल करने वाले विकल्पों के बारे में अहम जानकारी मिलती है (नीचे देखें).
लोडिंग का चरण
पहला चरण लोड करना है. इस दौरान, शुरुआती टारगेट और उनकी डिपेंडेंसी के ट्रांज़िशन क्लोज़र के लिए, सभी ज़रूरी BUILD फ़ाइलें लोड की जाती हैं, पार्स की जाती हैं, उनका आकलन किया जाता है, और उन्हें कैश मेमोरी में सेव किया जाता है.
बेज़ल सर्वर के चालू होने के बाद, पहले बिल्ड के लिए लोड होने का चरण आम तौर पर कई सेकंड लगता है. ऐसा इसलिए होता है, क्योंकि फ़ाइल सिस्टम से कई बिल्ड फ़ाइलें लोड होती हैं. बाद में बनाए जाने वाले बिल्ड काफ़ी तेज़ी से लोड होते हैं. खास तौर पर तब, जब किसी बिल्ड फ़ाइल में बदलाव न किया गया हो.
इस चरण के दौरान रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: पैकेज नहीं मिला, टारगेट नहीं मिला, BUILD फ़ाइल में लेक्सिकल और व्याकरण से जुड़ी गड़बड़ियां, और आकलन से जुड़ी गड़बड़ियां.
विश्लेषण का फ़ेज़
दूसरा चरण, विश्लेषण है. इसमें हर बिल्ड नियम का सेमेटिक विश्लेषण और पुष्टि की जाती है. साथ ही, बिल्ड डिपेंडेंसी ग्राफ़ बनाया जाता है और यह तय किया जाता है कि बिल्ड के हर चरण में क्या काम करना है.
लोड होने की तरह ही, विश्लेषण में पूरी तरह से गणना होने में भी कुछ सेकंड लगते हैं. हालांकि, Bazel एक बिल्ड से अगले बिल्ड तक डिपेंडेंसी ग्राफ़ को कैश मेमोरी में सेव करता है और सिर्फ़ ज़रूरी चीज़ों का फिर से विश्लेषण करता है. इससे, अगर पिछले बिल्ड के बाद पैकेज में कोई बदलाव नहीं हुआ है, तो इंक्रीमेंटल बिल्ड बहुत तेज़ी से हो सकते हैं.
इस चरण में रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: डिपेंडेंसी गलत है, नियम के लिए अमान्य इनपुट, और नियम से जुड़ी गड़बड़ी के सभी मैसेज.
लोड होने और विश्लेषण करने के चरण तेज़ी से लोड होते हैं, क्योंकि इस चरण में Basel की वजह से गैर-ज़रूरी फ़ाइल I/O नहीं होती हैं. यहां काम को तय करने के लिए, सिर्फ़ बिल्ड फ़ाइलें पढ़ी जा सकती हैं. यह डिज़ाइन के हिसाब से है. इससे Bazel, विश्लेषण टूल के लिए एक अच्छा फ़ाउंडेशन बन जाता है. जैसे, Bazel का क्वेरी कमांड, जो लोड करने के फ़ेज़ के ऊपर लागू किया जाता है.
लागू करने का फ़ेज़
बिल्ड का तीसरा और आखिरी चरण, एक्सीक्यूशन है. इस चरण से यह पक्का होता है कि बाइल्ड के हर चरण के आउटपुट, उसके इनपुट के मुताबिक हों. साथ ही, ज़रूरत के हिसाब से कंपाइलेशन/लिंकिंग वगैरह के टूल फिर से चलाए जाएं. इस चरण में, बिल्ड का ज़्यादातर समय बीतता है. बड़े बिल्ड के लिए, इसमें कुछ सेकंड से लेकर एक घंटे से ज़्यादा समय लग सकता है. इस चरण के दौरान रिपोर्ट की गई गड़बड़ियों में ये शामिल हैं: सोर्स फ़ाइलें मौजूद न होना, बिल्ड ऐक्शन से लागू किए गए टूल में गड़बड़ियां या आउटपुट का उम्मीद के मुताबिक सेट बनाने में टूल का नाकाम होना.