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