पिछले सेक्शन में पैकेज, टारगेट, और लेबल के बारे में जानकारी दी गई थी. साथ ही, इनके ज़रिए डिपेंडेंसी से जुड़े ग्राफ़ को संक्षेप में समझाया गया था. इस सेक्शन में, किसी पैकेज को तय करने के लिए इस्तेमाल किए जाने वाले कंक्रीट सिंटैक्स की जानकारी दी गई है.
परिभाषा के मुताबिक, हर पैकेज में एक BUILD फ़ाइल होती है जो एक छोटा
प्रोग्राम होती है. BUILD फ़ाइलों का मूल्यांकन इम्पैक्टरी भाषा,
Starlark का इस्तेमाल करके किया जाता है.
उन्हें स्टेटमेंट की क्रम में चलने वाली सूची के तौर पर समझा जाता है.
आम तौर पर, क्रम मायने रखता है: उदाहरण के लिए, वैरिएबल का इस्तेमाल किए जाने से पहले उनकी जानकारी दी जानी चाहिए. हालांकि, ज़्यादातर BUILD फ़ाइलों में सिर्फ़ बिल्ड के नियमों के एलान शामिल होते हैं. साथ ही, इन स्टेटमेंट का रिलेटिव ऑर्डर मटीरियल नहीं होता; ये सभी मायने रखते हैं, जो एलान किए गए और किन वैल्यू का समय के हिसाब से पैकेज इवैलुएशन पूरा किया गया.
जब cc_library जैसा कोई बिल्ड नियम लागू किया जाता है, तो यह ग्राफ़ में एक नया टारगेट बनाता है. इस टारगेट को बाद में लेबल का इस्तेमाल करके, रेफ़र किया जा सकता है.
आसान BUILD फ़ाइलों में, नियमों में किए गए एलानों को 'फिर से ऑर्डर' किया जा सकता है. इसके लिए, व्यवहार बदलना नहीं पड़ता.
कोड और डेटा के बीच साफ़ अंतर दिखाने के लिए, BUILD फ़ाइलों में फ़ंक्शन की परिभाषाएं, for स्टेटमेंट या if स्टेटमेंट (हालांकि, सूची देखने और if एक्सप्रेशन की अनुमति है) नहीं हो सकते. इसके बजाय, फ़ंक्शन का एलान .bzl फ़ाइलों में किया जा सकता है. इसके अलावा, BUILD फ़ाइलों में *args और **kwargs आर्ग्युमेंट की अनुमति नहीं है. इसके बजाय, उन सभी आर्ग्युमेंट को साफ़ तौर पर सूची में शामिल करें.
क्रूरता से, Starlark के प्रोग्राम, आर्बिट्रेरी I/O की सुविधा नहीं दे सकते. यह वैरिएंट, BUILD फ़ाइलों को समझने में आसान बनाता है. यह इनपुट के सिर्फ़ ऐसे सेट पर निर्भर करता है जो पहले से जाना जा सकता है. यह पक्का करना ज़रूरी है कि बिल्ड फिर से किए जा सकें.
ज़्यादा जानकारी के लिए, Hermetic देखें.
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_*. इनमें से कुछ फ़ंक्शन,
Create Encyclopedia में दस्तावेज़ के रूप में मौजूद हैं. हालांकि, कोई भी
नए नियम बना सकता है.
*_binaryनियम, दी गई भाषा में एक्ज़ीक्यूटेबल प्रोग्राम बनाते हैं. बिल्ड एक्ज़ीक्यूटेबल, नियम के लेबल से जुड़े नाम में बिल्ड टूल के बाइनरी आउटपुट ट्री में रहेगा, इसलिए//my:program(उदाहरण के लिए)$(BINDIR)/my/programपर दिखेगा.कुछ भाषाओं में, इस तरह के नियम एक रनफ़ाइल डायरेक्ट्री भी बनाते हैं, जिसमें नियम से जुड़ी
dataएट्रिब्यूट या डिपेंडेंसी के सभी ट्रांज़िट के लिए लागू होने वाले नियमों की सभी चीज़ें शामिल होती हैं.*_testनियम,*_binaryनियम की विशेषज्ञता है. इसका इस्तेमाल अपने-आप होने वाले टेस्ट के लिए किया जाता है. टेस्ट बस ऐसे प्रोग्राम होते हैं जो सफलता पर शून्य देते हैं.बाइनरी की तरह, जांच में भी रन फ़ाइलें ट्री होते हैं और फ़ाइल के नीचे ही वे फ़ाइलें होती हैं जिन्हें रनटाइम पर रन किया जा सकता है. उदाहरण के लिए, एक प्रोग्राम
cc_test(name='x', data=['//foo:bar'])शायद काम करते समय$TEST_SRCDIR/workspace/foo/barको खोल और पढ़ सकता है. (हर प्रोग्रामिंग लैंग्वेज का,$TEST_SRCDIRकी वैल्यू ऐक्सेस करने का अपना यूटिलिटी फ़ंक्शन होता है. हालांकि, ये सभी एनवायरमेंट वैरिएबल का इस्तेमाल करने के बराबर होते हैं.) इस नियम का पालन न करने पर, हो सकता है कि टेस्ट को रिमोट टेस्टिंग होस्ट पर लागू करने पर जांच न हो पाए.*_libraryनियम, दी गई प्रोग्रामिंग भाषा में अलग से इकट्ठा किए गए मॉड्यूल के बारे में बताते हैं. लाइब्रेरी अन्य लाइब्रेरी पर निर्भर कर सकती हैं, और बाइनरी और टेस्ट, उम्मीद के मुताबिक अलग-अलग कंपाइलेशन के व्यवहार के साथ, लाइब्रेरी पर निर्भर हो सकती हैं.
| लेबल | डिपेंडेंसी |