फ़ाइलें बनाएं

समस्या की शिकायत करें सोर्स देखें

पिछले सेक्शन में, पैकेज, टारगेट, और लेबल के साथ-साथ बिल्ड डिपेंडेंसी ग्राफ़ के बारे में विस्तार से बताया गया है. इस सेक्शन में, पैकेज को तय करने के लिए इस्तेमाल किए गए कंक्रीट सिंटैक्स के बारे में बताया गया है.

परिभाषा के मुताबिक, हर पैकेज में एक 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 फ़ाइल को कौन लोड कर सकता है.

बिल्ड रूल के टाइप

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

लेबल	डिपेंडेंसी