यह पेज मान लेता है कि आपको Baज़र के बारे में जानकारी है और यह दिशा-निर्देश और बेज़ल की सुविधाओं का पूरा फ़ायदा पाने के लिए, अपने प्रोजेक्ट को स्ट्रक्चर करने से जुड़ी सलाह भी पाएं.
कुल लक्ष्य ये हैं:
- समानता और बढ़ोतरी के लिए, सटीक डिपेंडेंसी का इस्तेमाल करना.
- डिपेंडेंसी को अच्छी तरह से इनकैप्सुलेट करने के लिए.
- कोड को अच्छी तरह से स्ट्रक्चर करने और टेस्ट करने लायक बनाने के लिए.
- ऐसा बिल्ड कॉन्फ़िगरेशन बनाने के लिए जो समझने और बनाए रखने में आसान हो.
ये दिशा-निर्देश ज़रूरी शर्तों के मुताबिक नहीं हैं: कुछ ही प्रोजेक्ट उन सभी को. जैसा कि लिंट के लिए मैन पेज ने कहा है, "एक विशेष इनाम दिया जाएगा पहले व्यक्ति को एक ऐसा असली प्रोग्राम बनाने की अनुमति दें जिससे कोई गड़बड़ी न हो सख्त जांच होनी चाहिए." हालांकि, इनमें से ज़्यादा से ज़्यादा सिद्धांतों को शामिल करने से होना चाहिए, ताकि प्रोजेक्ट पढ़ने में आसान हो, गड़बड़ी की संभावना कम हो, और प्रोजेक्ट बनाने में कम समय लगता हो.
यह पेज, इसमें बताई गई ज़रूरी शर्तों के लेवल का इस्तेमाल करता है यह आरएफ़सी.
बिल्ड और टेस्ट चलाना
प्रोजेक्ट ऐसा होना चाहिए जो हमेशा bazel build //... और
bazel test //... अपनी स्थायी ब्रांच पर काम करता है. ज़रूरी टारगेट
लेकिन कुछ परिस्थितियों में उसका निर्माण न करें (जैसे कि एक विशिष्ट बिल्ड की आवश्यकता हो)
फ़्लैग, किसी खास प्लैटफ़ॉर्म पर नहीं बनाए जाते हैं, तो लाइसेंस देने के लिए कानूनी समझौता ज़रूरी है)
जितना हो सके उतना सटीक तौर पर टैग करें (उदाहरण के लिए, "requires-osx"). यह
टैगिंग की सहायता से लक्ष्यों को
"मैन्युअल" टैग करके BUILD फ़ाइल की जांच करने वाले व्यक्ति को यह समझने में मदद मिलती है कि
किसी टारगेट पर लगी पाबंदियां हैं.
तीसरे पक्ष की डिपेंडेंसी
तीसरे पक्ष की डिपेंडेंसी का एलान किया जा सकता है:
- इनमें से किसी एक को
WORKSPACEफ़ाइल में, रिमोट डेटा स्टोर करने की जगह के तौर पर एलान करें. - या उन्हें अपनी वर्कस्पेस की डायरेक्ट्री में,
third_party/नाम की डायरेक्ट्री में रखें.
बाइनरी के आधार पर
जब भी हो सके, सब कुछ सोर्स से बनाया जाना चाहिए. आम तौर पर इसका मतलब है
कि, लाइब्रेरी some-library.so पर निर्भर करने के बजाय, आप एक
BUILD फ़ाइल बनाई और उसके सोर्स से some-library.so बनाएं. इसके बाद, उस पर निर्भर करें
टारगेट.
हमेशा सोर्स से बनाने पर, यह पक्का होता है कि बिल्ड ऐसी लाइब्रेरी का इस्तेमाल नहीं कर रहा है जो को असंगत फ़्लैग या अलग आर्किटेक्चर के साथ बनाया गया था. यहां आपको ये सुविधाएं भी कुछ ऐसी सुविधाएं होती हैं जिनमें सिर्फ़ कवरेज, स्टैटिक विश्लेषण या डाइनैमिक विश्लेषण शामिल होता है स्रोत पर काम करते हैं.
वर्शन
जब भी संभव हो, शीर्ष से सभी कोड बनाना पसंद करें. वर्शन कब बनाए जाने चाहिए
इस्तेमाल किया गया है, तो टारगेट नाम में वर्शन शामिल करने से बचें (उदाहरण के लिए, //guava,
//guava-20.0 नहीं है). यह नाम रखने से लाइब्रेरी को अपडेट करना आसान हो जाता है (सिर्फ़ एक विकल्प के लिए)
टारगेट को अपडेट करने की ज़रूरत है). यह डायमंड डिपेंडेंसी से भी बेहतर तरीके से सुरक्षित रखता है
समस्याएं: अगर एक लाइब्रेरी guava-19.0 पर और दूसरी guava-20.0 पर निर्भर है, तो
तो आपको एक ऐसी लाइब्रेरी मिल सकती है जो दो अलग-अलग वर्शन पर निर्भर रहने की कोशिश करती है.
अगर आपने दोनों टारगेट को एक guava लाइब्रेरी पर ले जाने के लिए गुमराह करने वाला उपनाम बनाया है,
तो BUILD फ़ाइलें गुमराह करने वाली हैं.
.bazelrc फ़ाइल का इस्तेमाल करना
प्रोजेक्ट-विशिष्ट विकल्पों के लिए, कॉन्फ़िगरेशन फ़ाइल का उपयोग करें
workspace/.bazelrc (bazzrc फ़ॉर्मैट देखें).
अगर आपको अपने प्रोजेक्ट के लिए, हर उपयोगकर्ता के हिसाब से उपलब्ध ऐसे विकल्पों को इस्तेमाल करना है जो नहीं हैं सोर्स कंट्रोल की जांच करना चाहते हैं, तो यह लाइन शामिल करें:
try-import %workspace%/user.bazelrc
आपके workspace/.bazelrc में (या किसी अन्य फ़ाइल नाम)
और user.bazelrc को अपने .gitignore में जोड़ें.
पैकेज
हर उस डायरेक्ट्री का पैकेज होना चाहिए जिसमें बिल्ड की जा सकने वाली फ़ाइलें हों. अगर BUILD
यह फ़ाइल सबडायरेक्ट्री (जैसे, srcs = ["a/b/C.java"]) की फ़ाइलों के बारे में बताती है
यह चिह्न कि BUILD फ़ाइल को उस सबडायरेक्ट्री में जोड़ा जाना चाहिए. लंबी अवधि वाला
इस संरचना का इस्तेमाल करते हैं, तो इस बात की संभावना ज़्यादा होगी कि सर्कुलर डिपेंडेंसी
अनजाने में बनाए गए, टारगेट का दायरा कम हो जाएगा और बढ़ती हुई संख्या में
को रिवर्स डिपेंडेंसी को अपडेट करना होगा.