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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

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

फ़ाइल फ़ोल्डर

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

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

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

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

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

Bazel के साथ बंडल किए गए फ़ाइल फ़ोल्डर के नियमों को, Create Encyclopedia के Workspace Rules सेक्शन में जाना जाता है. साथ ही, एम्बेड किए गए Starlark डेटा संग्रह नियमों के दस्तावेज़ पढ़ें.

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

पैकेज

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

पैकेज, ऐसी डायरेक्ट्री के तौर पर बताया जाता है जिसमें 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 के सिंबल उपलब्ध होते हैं और एक्ज़ीक्यूशन के दौरान B का रनटाइम डेटा A के लिए उपलब्ध होता है.

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

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

लेबल