पिछले सेक्शन में पैकेज, टारगेट, और लेबल के बारे में साफ़ तौर पर बताया गया था. इस सेक्शन में पैकेज तय करने के लिए इस्तेमाल किए गए कंक्रीट सिंटैक्स के बारे में बताया गया है.
परिभाषा के मुताबिक, हर पैकेज में एक BUILD
फ़ाइल होती है. यह एक छोटा प्रोग्राम है.
BUILD
फ़ाइलों का आकलन किया गया है और वे इंपीरिटिव भाषा का इस्तेमाल करते हैं,
Starlark.
उन्हें स्टेटमेंट की क्रम वाली सूची समझा जाता है.
आम तौर पर, क्रम ज़रूरी है: वैरिएबल का इस्तेमाल करने से पहले उनकी जानकारी दी जानी चाहिए, उदाहरण के लिए. हालांकि, ज़्यादातर BUILD
फ़ाइलों में सिर्फ़ बिल्ड नियमों के एलान होते हैं. साथ ही, इन स्टेटमेंट का क्रम एक जैसा नहीं होता. सभी अहमियत इस बात से तय होती है कि किन नियम तय किए गए थे और समय के साथ पैकेज का आकलन पूरा होने तक किन वैल्यू का इस्तेमाल किया जाता है.
जब बिल्ड नियम का फ़ंक्शन, जैसे कि cc_library
को लागू किया जाता है, तब यह ग्राफ़ में एक नया टारगेट बनाता है. बाद में, इस टारगेट का इस्तेमाल लेबल का इस्तेमाल करके किया जा सकता है.
आसान BUILD
फ़ाइलों में, नियम में किए गए एलानों को बिना किसी बदलाव के फिर से क्रम में लगाया जा सकता है.
कोड और डेटा को आसानी से अलग करने के लिए, BUILD
फ़ाइल में फ़ंक्शन की परिभाषाएं, for
स्टेटमेंट या if
स्टेटमेंट शामिल नहीं हो सकते. हालांकि, सूची और समझकर समझने और if
एक्सप्रेशन की अनुमति है. इसके बजाय, .bzl
फ़ाइलों में फ़ंक्शन का एलान किया जा सकता है. इसके अलावा, BUILD
फ़ाइलों में *args
और **kwargs
आर्ग्युमेंट की अनुमति नहीं है. इसके बजाय, सभी तर्कों को साफ़ तौर पर सूची में शामिल करें.
अहम बात यह है कि Starlark के प्रोग्राम, I/O के लिए आर्बिट्रेरी नहीं हो सकते. यह वैरिएंट BUILD
फ़ाइलों को हर्मेटिक बनाता है. यह इनपुट के सिर्फ़ सेट पर निर्भर करता है. यह पक्का करना ज़रूरी है कि बिल्ड फिर से बनाया जा सके.
ज़्यादा जानकारी के लिए, मंज़ूरी देखें.
BUILD
फ़ाइलों को सिर्फ़ ASCII वर्णों का इस्तेमाल करके लिखा जाना चाहिए. हालांकि, लैटिन-1 वर्ण सेट का इस्तेमाल करके, तकनीकी तौर पर इन्हें समझा जा सकता है.
क्योंकि जब भी कोड में बदलाव होता है, तो BUILD
फ़ाइलों को अपडेट करने की ज़रूरत होती है. आम तौर पर, टीम में कई लोग इसका रखरखाव करते हैं. BUILD
फ़ाइल लेखकों को हर बिल्ड टारगेट की भूमिका को लिखते समय उदारता से टिप्पणी करनी चाहिए, चाहे वह सार्वजनिक इस्तेमाल के लिए हो या न हो और पैकेज की भूमिका का दस्तावेज़ हो.
एक्सटेंशन लोड हो रहा है
Bazel एक्सटेंशन, .bzl
से खत्म होने वाली फ़ाइलें हैं. किसी एक्सटेंशन से सिंबल इंपोर्ट करने के लिए, load
स्टेटमेंट का इस्तेमाल करें.
load("//foo/bar:file.bzl", "some_library")
यह कोड, foo/bar/file.bzl
फ़ाइल को लोड करता है और एनवायरमेंट में some_library
सिंबल जोड़ता है. इसका इस्तेमाल नए नियमों, फ़ंक्शन या कॉन्सटेंट को लोड करने के लिए किया जा सकता है
(उदाहरण के लिए, कोई स्ट्रिंग या सूची). load
को कॉल करने के लिए और तर्क इस्तेमाल करके एक से ज़्यादा चिह्न इंपोर्ट किए जा सकते हैं. तर्क स्ट्रिंग लिटरल होने चाहिए
(कोई वैरिएबल नहीं) और load
स्टेटमेंट टॉप लेवल पर होने चाहिए — ये किसी फ़ंक्शन बॉडी में नहीं हो सकते.
load
का पहला आर्ग्युमेंट, एक लेबल है, जो .bzl
फ़ाइल की पहचान करता है. अगर यह रिलेटिव लेबल है, तो उस पैकेज (डायरेक्ट्री) के हिसाब से इसे ठीक किया जाता है जिसमें मौजूदा bzl
फ़ाइल होती है. load
स्टेटमेंट में मौजूद रिलेटिव लेबल, लीड :
के तौर पर इस्तेमाल होने चाहिए.
load
उपनामों का भी इस्तेमाल करता है. इसलिए, इंपोर्ट किए गए सिंबल के लिए अलग-अलग नाम असाइन किए जा सकते हैं.
load("//foo/bar:file.bzl", library_alias = "some_library")
आपके पास एक load
स्टेटमेंट में एक से ज़्यादा उपनाम तय करने का विकल्प होता है. इसके अलावा,
आर्ग्युमेंट सूची में उपनाम और सामान्य सिंबल के नाम, दोनों हो सकते हैं. नीचे दिया गया उदाहरण पूरी तरह से कानूनी है (कृपया ध्यान दें कि कोटेशन मार्क का इस्तेमाल कब करना है).
load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")
.bzl
फ़ाइल में, _
से शुरू होने वाले सिंबल एक्सपोर्ट नहीं किए जाते और उन्हें किसी दूसरी फ़ाइल से लोड नहीं किया जा सकता.
.bzl
लोड करने के लिए, लोड होने की जानकारी लोड करने की सुविधा का इस्तेमाल करें.
बिल्ड नियमों के टाइप
बिल्ड के ज़्यादातर नियम, परिवारों के हिसाब से होते हैं जिन्हें भाषा के हिसाब से एक साथ रखा जाता है. उदाहरण के लिए, cc_binary
, cc_library
और cc_test
क्रमश: C++ बाइनरी, लाइब्रेरी, और टेस्ट के लिए नियम हैं. दूसरी भाषाएं, एक ही नाम वाली स्कीम का इस्तेमाल करती हैं, जिसका नाम प्रीफ़िक्स है, जैसे कि Java के लिए java_*
. इनमें से कुछ फ़ंक्शन बिल्ड एनसाइक्लोपीडिया में दर्ज किए गए हैं, लेकिन सभी के लिए नए नियम बनाना मुमकिन है.
*_binary
नियम, किसी दी गई भाषा में एक्ज़ीक्यूटेबल प्रोग्राम बनाते हैं. एक बिल्ड के बाद, एक्ज़ीक्यूटेबल, बिल्ड टूल के बाइनरी आउटपुट आउटपुट में नियम के लेबल से जुड़े नाम के हिसाब से होगा, ताकि//my:program
, उदाहरण के लिए$(BINDIR)/my/program
पर दिखे.कुछ भाषाओं में, ऐसे नियम एक रनफ़ाइल डायरेक्ट्री भी बनाते हैं जिसमें इस नियम से जुड़े
data
एट्रिब्यूट या डिपेंडेंसी के ट्रांज़िशन से जुड़ी सभी नियम शामिल होते हैं. प्रोडक्शन में आसानी से डिप्लॉयमेंट के लिए, फ़ाइलों का यह सेट एक ही जगह पर इकट्ठा किया जाता है.*_test
नियम,*_binary
नियम की विशेषज्ञता है. इसका इस्तेमाल, अपने-आप होने वाले टेस्ट के लिए किया जाता है. टेस्ट बस ऐसे प्रोग्राम होते हैं जो सफलता की तरफ़ इशारा करते हैं.बाइनरी की तरह, जांच में भी रनफ़ाइल ट्री होती हैं. इसके अलावा, सिर्फ़ फ़ाइलें ही रनटाइम के दौरान सही तरीके से खुल सकती हैं. उदाहरण के लिए,
cc_test(name='x', data=['//foo:bar'])
प्रोग्राम चलने के दौरान$TEST_SRCDIR/workspace/foo/bar
खुल सकता है और पढ़ सकता है. ($TEST_SRCDIR
का मान ऐक्सेस करने के लिए हर प्रोग्रामिंग भाषा की अपनी उपयोगिता फ़ंक्शन है, लेकिन वे सीधे तौर पर एनवायरमेंट वैरिएबल का इस्तेमाल करने के बराबर हैं.) इस नियम का पालन न करने पर, रिमोट टेस्टिंग होस्ट पर जांच लागू होने पर जांच पूरी नहीं हो पाएगी.*_library
नियम, प्रोग्रामिंग भाषा में अलग-अलग कंपाइल किए गए मॉड्यूल के बारे में बताते हैं. लाइब्रेरी अन्य लाइब्रेरी पर निर्भर कर सकती हैं. साथ ही, बाइनरी और टेस्ट, लाइब्रेरी के हिसाब से अलग-अलग हो सकते हैं.
लेबल | डिपेंडेंसी |