पिछले सेक्शन में पैकेज, टारगेट, और लेबल के बारे में साफ़ तौर पर बताया गया था. इस सेक्शन में पैकेज तय करने के लिए इस्तेमाल किए गए कंक्रीट सिंटैक्स के बारे में बताया गया है.
परिभाषा के मुताबिक, हर पैकेज में एक 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नियम, प्रोग्रामिंग भाषा में अलग-अलग कंपाइल किए गए मॉड्यूल के बारे में बताते हैं. लाइब्रेरी अन्य लाइब्रेरी पर निर्भर कर सकती हैं. साथ ही, बाइनरी और टेस्ट, लाइब्रेरी के हिसाब से अलग-अलग हो सकते हैं.
| लेबल | डिपेंडेंसी |