पिछले सेक्शन में पैकेज, टारगेट, और लेबल के बारे में जानकारी दी गई थी. साथ ही, इस पर निर्भरता दिखाने वाला ग्राफ़ बनाया गया था. इस सेक्शन में किसी कॉन्क्रीट के बारे में जानकारी दी गई है.
परिभाषा के हिसाब से, हर पैकेज में एक BUILD फ़ाइल होती है जो एक छोटा प्रोग्राम होता है. BUILD फ़ाइलों का मूल्यांकन एक ज़रूरी भाषा,
Starlark का इस्तेमाल करके किया जाता है.
इन्हें स्टेटमेंट की क्रम में बनी सूची के तौर पर समझा जाएगा.
आम तौर पर, क्रम अहम होता है: उदाहरण के लिए, वैरिएबल का इस्तेमाल किए जाने से पहले. हालांकि, ज़्यादातर BUILD फ़ाइलों में सिर्फ़ बिल्ड के नियमों के एलान होते हैं और इन स्टेटमेंट का क्रम एक जैसा होता है; पैकेज
के मूल्यांकन की अवधि पूरी होने के बाद ही, मायने रखने वाले सभी नियमों के महत्व के बारे में पता चलता है.
जब बिल्ड नियम फ़ंक्शन, जैसे cc_library निष्पादित किया जाता है, तो यह ग्राफ़ में एक नया टारगेट बनाता है. इस टारगेट को बाद में लेबल का इस्तेमाल करके रेफ़र किया जा सकता है.
आसान BUILD फ़ाइलों में, नियम के एलानों को बिना किसी शुल्क के फिर से क्रम में लगाया जा सकता है.
कोड और डेटा के बीच के अंतर को बढ़ावा देने के लिए, BUILD फ़ाइल में फ़ंक्शन की परिभाषाएं, for स्टेटमेंट या if स्टेटमेंट नहीं हो सकते हैं (लेकिन सूची समझ और if एक्सप्रेशन शामिल किए जा सकते हैं) चुनें. इसके बजाय, फ़ंक्शन को .bzl फ़ाइलों में बताया जा सकता है. इसके अलावा, BUILD फ़ाइलों में *args और **kwargs तर्क की अनुमति नहीं है; इसके बजाय, सभी तर्कों की सूची खास तौर पर रखें.
खास तौर पर, Starlark के प्रोग्राम की मदद से, I/O को मनमुताबिक नहीं बनाया जा सकता. यह इनवेरिएंट
BUILD फ़ाइलों की बनावट को समझता है — यह सिर्फ़ इनपुट के सेट पर निर्भर करता है. यह पक्का करने के लिए ज़रूरी है कि बिल्ड फिर से जनरेट हो सकें.
ज़्यादा जानकारी के लिए, पर्यावरण से जुड़ी जानकारी देखें.
BUILD फ़ाइलों को सिर्फ़ ASCII वर्णों का इस्तेमाल करके लिखा जाना चाहिए, हालांकि
तकनीकी रूप से उन्हें लैटिन-1 वर्ण सेट का इस्तेमाल करके समझा जाता है.
जब भी काम करने वाले कोड में मौजूद डिपेंडेंसी में बदलाव होता है, तब BUILD फ़ाइलों को अपडेट करना पड़ता है. इसलिए, आम तौर पर इन फ़ाइलों का रखरखाव कई लोग करते हैं. BUILD फ़ाइल के लेखक को हर बिल्ड टारगेट की भूमिका को दस्तावेज़ के तौर पर दर्ज करना चाहिए, चाहे वह सार्वजनिक तौर पर इस्तेमाल करने के लिए हो या पैकेज के बारे में.
एक्सटेंशन लोड हो रहा है
बैजल एक्सटेंशन, .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 फ़ाइल को दिखाने के लिए आपको exports_files का इस्तेमाल करने की ज़रूरत नहीं है.
बिल्ड के नियम किस तरह के हैं
बिल्ड के ज़्यादातर नियम, परिवारों के हिसाब से बनाए जाते हैं. इन्हें भाषा के हिसाब से एक साथ रखा जाता है. उदाहरण के लिए, 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नियमों में, दी गई प्रोग्रामिंग भाषा में अलग-अलग बनाए गए मॉड्यूल तय किए जाते हैं. लाइब्रेरी दूसरे लाइब्रेरी पर निर्भर कर सकती हैं, और बाइनरी और टेस्ट, अलग-अलग कंपाइलेशन व्यवहार के साथ लाइब्रेरी पर निर्भर कर सकते हैं.
| लेबल | डिपेंडेंसी |