फ़ाइल फ़ोल्डर, पैकेज, और टारगेट

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

Baze, सोर्स कोड से सॉफ़्टवेयर बनाता है. यह सॉफ़्टवेयर एक डायरेक्ट्री ट्री में व्यवस्थित करके बनाया जाता है, जिसे Workspace कहा जाता है. फ़ाइल फ़ोल्डर में सोर्स फ़ाइलें, पैकेज की नेस्ट की गई हैरारकी में व्यवस्थित की जाती हैं. यहां हर पैकेज एक डायरेक्ट्री है, जिसमें मिलती-जुलती सोर्स फ़ाइलों का सेट और एक BUILD फ़ाइल होती है. BUILD फ़ाइल से पता चलता है कि सोर्स से कौनसे सॉफ़्टवेयर आउटपुट बनाए जा सकते हैं.

Workspace

वर्कस्पेस आपके फ़ाइल सिस्टम पर मौजूद एक डायरेक्ट्री ट्री होता है. इसमें उस सॉफ़्टवेयर की सोर्स फ़ाइलें शामिल होती हैं जिसे आपको बनाना है. हर वर्कस्पेस में WORKSPACE नाम की एक टेक्स्ट फ़ाइल होती है, जो शायद खाली हो या उसमें आउटपुट बनाने के लिए ज़रूरी बाहरी डिपेंडेंसी के रेफ़रंस हों.

जिन डायरेक्ट्री में WORKSPACE नाम की फ़ाइल होती है उन्हें वर्कस्पेस का रूट माना जाता है. इसलिए, Basel किसी WORKSPACE फ़ाइल वाली सबडायरेक्ट्री पर रूट किए गए फ़ाइल फ़ोल्डर में मौजूद सभी डायरेक्ट्री ट्री को अनदेखा कर देता है, क्योंकि वे एक अन्य फ़ाइल फ़ोल्डर बनाते हैं.

Basel, WORKSPACE फ़ाइल के उपनाम के तौर पर WORKSPACE.bazel फ़ाइल के साथ भी काम करता है. अगर दोनों फ़ाइलें मौजूद हों, तो WORKSPACE.bazel का इस्तेमाल किया जाता है.

डेटा स्टोर करने की जगह

कोड को डेटा स्टोर करने की जगहों में व्यवस्थित किया गया है. WORKSPACE फ़ाइल वाली डायरेक्ट्री, डेटा स्टोर करने की मुख्य जगह का रूट होती है. इसे @ भी कहा जाता है. WORKSPACE फ़ाइल में, अन्य (बाहरी) डेटा स्टोर करने की जगहों के बारे में, फ़ाइल फ़ोल्डर के नियमों का इस्तेमाल करके बताया जाता है या Bzlmod सिस्टम में मॉड्यूल और एक्सटेंशन से जनरेट किया जाता है. ज़्यादा जानकारी के लिए, बाहरी डिपेंडेंसी की खास जानकारी देखें.

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

एक्सटर्नल डेटा स्टोर करने की जगहें खुद ही डेटा स्टोर करने की जगह होती हैं. इसलिए, इनमें अक्सर एक WORKSPACE फ़ाइल भी होती है. हालांकि, इन अतिरिक्त WORKSPACE फ़ाइलों को Baज़र ने अनदेखा किया है. खास तौर पर, डेटा स्टोर करने की ऐसी जगहें अपने-आप नहीं जुड़ती जो ट्रांज़िट पर निर्भर होती हैं.

पैकेज

रिपॉज़िटरी में कोड संगठन की मुख्य इकाई पैकेज होती है. पैकेज, मिलती-जुलती फ़ाइलों का एक कलेक्शन होता है. इसमें यह जानकारी होती है कि आउटपुट वाले आर्टफ़ैक्ट बनाने के लिए उनका इस्तेमाल कैसे किया जा सकता है.

पैकेज ऐसी डायरेक्ट्री होता है जिसमें BUILD (या BUILD.bazel) नाम की फ़ाइल होती है. पैकेज में, उसकी डायरेक्ट्री में मौजूद सभी फ़ाइलें होती हैं. साथ ही, उसके नीचे सभी सबडायरेक्ट्री शामिल होती हैं. हालांकि, इनमें वे फ़ाइलें शामिल नहीं होती हैं जिनमें BUILD फ़ाइल होती है. इस परिभाषा से पता चलता है कि कोई भी फ़ाइल या डायरेक्ट्री दो अलग-अलग पैकेज का हिस्सा नहीं हो सकती.

उदाहरण के लिए, नीचे दिए गए डायरेक्ट्री ट्री में दो पैकेज हैं, my/app, और सबपैकेज my/app/tests. ध्यान दें कि my/app/data कोई पैकेज नहीं है, बल्कि my/app पैकेज की डायरेक्ट्री है.

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

टारगेट

पैकेज, टारगेट का एक कंटेनर होता है, जिसकी जानकारी पैकेज की BUILD फ़ाइल में दी जाती है. ज़्यादातर टारगेट दो मुख्य तरह के होते हैं, फ़ाइलें और नियम.

फ़ाइलों को दो कैटगरी में बांटा गया है. आम तौर पर, सोर्स फ़ाइलें लोगों की कोशिशों से लिखी जाती हैं और रिपॉज़िटरी में चेक इन की जाती हैं. जनरेट की गई फ़ाइलों को कभी-कभी डिराइव्ड फ़ाइलें या आउटपुट फ़ाइलें भी कहा जाता है. इन फ़ाइलों में चेक इन नहीं किया जाता, लेकिन इन्हें सोर्स फ़ाइलों से जनरेट किया जाता है.

दूसरे तरह के टारगेट को नियम के साथ तय किया गया है. हर नियम इंस्टेंस, इनपुट के सेट और आउटपुट फ़ाइलों के सेट के बीच संबंध बताता है. किसी नियम के इनपुट, सोर्स फ़ाइलें हो सकते हैं, लेकिन वे अन्य नियमों के आउटपुट भी हो सकते हैं.

ज़्यादातर मामलों में, चाहे नियम का इनपुट कोई सोर्स फ़ाइल है या जनरेट की गई फ़ाइल, ज़्यादातर मामलों में अभौतिक है; सिर्फ़ उस फ़ाइल के कॉन्टेंट का ही महत्व है. इससे, कॉम्प्लेक्स सोर्स फ़ाइल को किसी नियम के ज़रिए बनी जनरेट की गई फ़ाइल से बदलना आसान हो जाता है. उदाहरण के लिए, जब बहुत ज़्यादा स्ट्रक्चर वाली फ़ाइल को मैन्युअल तौर पर मैनेज करने की ज़रूरत नहीं पड़ती और कोई व्यक्ति इसे समझने के लिए प्रोग्राम लिख लेता है. उस फ़ाइल के उपभोक्ताओं के लिए किसी बदलाव की आवश्यकता नहीं है. इसके उलट, जनरेट की गई फ़ाइल को सिर्फ़ स्थानीय बदलावों वाली सोर्स फ़ाइल से बदला जा सकता है.

किसी नियम के इनपुट में अन्य नियम भी शामिल हो सकते हैं. ऐसे संबंधों का सटीक मतलब अक्सर काफ़ी जटिल और भाषा- या नियम पर निर्भर होता है, लेकिन सहजता से यह आसान है: किसी इनपुट के लिए, C++ लाइब्रेरी नियम A में दूसरा C++ लाइब्रेरी नियम B हो सकता है. इस डिपेंडेंसी का असर यह होता है कि B की हेडर फ़ाइलें, कंपाइलेशन के दौरान A को उपलब्ध हो जाती हैं. लिंक करने के दौरान B के सिंबल A को उपलब्ध हो जाते हैं. साथ ही, B के रनटाइम डेटा को एक्ज़ीक्यूशन के दौरान A के लिए उपलब्ध कराया जाता है.

सभी नियमों का एक वैरिएंट यह है कि किसी नियम के ज़रिए जनरेट की गई फ़ाइलें हमेशा उसी पैकेज से जुड़ी होती हैं जिसका नियम नियम होता है. फ़ाइलें किसी दूसरे पैकेज में जनरेट नहीं की जा सकतीं. हालांकि, नियम के इनपुट किसी दूसरे पैकेज से शामिल होते हैं, यह आम बात है.

पैकेज ग्रुप ऐसे पैकेज के सेट होते हैं जिनका मकसद, कुछ खास नियमों की सुलभता को सीमित करना होता है. पैकेज ग्रुप, package_group फ़ंक्शन से तय किए जाते हैं. इनमें तीन प्रॉपर्टी होती हैं: उनमें मौजूद पैकेज की सूची, उनका नाम, और वे दूसरे पैकेज ग्रुप जिनमें शामिल हैं. इनके बारे में जानकारी देने के लिए, नियमों के visibility एट्रिब्यूट या package फ़ंक्शन के default_visibility एट्रिब्यूट से ही रेफ़रंस दिया जा सकता है. ये न तो फ़ाइलें जनरेट करते हैं और न ही उनका इस्तेमाल करते हैं. ज़्यादा जानकारी के लिए, package_group दस्तावेज़ देखें.

लेबल