इस पेज पर हम यह मानकर चल रहे हैं कि आपको Bazel के बारे में पता है. यह आपको अपने प्रोजेक्ट को तैयार करने के लिए दिशा-निर्देश और सलाह देगा, ताकि बैजेल की सुविधाओं का पूरा फ़ायदा लिया जा सके.
कुल लक्ष्य ये हैं:
- साथ-साथ काम करने और बढ़ोतरी को बढ़ावा देने के लिए, बेहतर डिपेंडेंसी का इस्तेमाल करना.
- डिपेंडेंसी को अच्छी तरह से एन्कैप्सुलेट करने के लिए.
- कोड को अच्छी तरह से स्ट्रक्चर करने और टेस्ट करने लायक बनाने के लिए.
- ऐसा बिल्ड कॉन्फ़िगरेशन बनाने के लिए जो समझने और बनाए रखने में आसान हो.
इन दिशा-निर्देशों को लागू करना ज़रूरी नहीं है: कुछ प्रोजेक्ट ही सभी नीतियों का पालन कर पाएंगे. जैसा कि लिंट के लिए मैन पेज में कहा गया है, "असल में प्रोग्राम बनाने वाले पहले व्यक्ति को एक खास इनाम दिया जाएगा, जिससे सख्त जांच में कोई गड़बड़ी न हो." हालांकि, इनमें से ज़्यादा से ज़्यादा सिद्धांतों को शामिल करने से, प्रोजेक्ट को पढ़ने में आसान, कम गड़बड़ी वाला, और तेज़ी से बनाने में मदद मिलती है.
यह पेज, इस आरएफ़सी में बताए गए लेवल का इस्तेमाल करता है.
बिल्ड और टेस्ट चलाना
कोई प्रोजेक्ट ऐसा होना चाहिए कि वह हमेशा 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 की कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करें (bazelrc फ़ॉर्मैट देखें).
अगर आपको अपने ऐसे प्रोजेक्ट के लिए हर उपयोगकर्ता के हिसाब से विकल्प उपलब्ध कराने हैं जिसे आपको सोर्स कंट्रोल की जांच नहीं करनी है, तो यह लाइन शामिल करें:
try-import %workspace%/user.bazelrc
(या कोई दूसरा फ़ाइल नाम) को अपने workspace/.bazelrc
में जोड़ें और user.bazelrc को अपने .gitignore में जोड़ें.
पैकेज
हर डायरेक्ट्री में एक पैकेज होना चाहिए, जिसमें बनाई जा सकने वाली फ़ाइलें शामिल हों. अगर कोई BUILD फ़ाइल, सबडायरेक्ट्री (जैसे, srcs = ["a/b/C.java"]) की फ़ाइलों के बारे में बताती है, तो यह इस बात का संकेत है कि उस सबडायरेक्ट्री में BUILD फ़ाइल जोड़ी जानी चाहिए. यह स्ट्रक्चर जितना ज़्यादा लंबा
होगा, उतनी ही ज़्यादा सर्कुलर डिपेंडेंसी अनजाने में
बनाई जाएंगी, टारगेट का स्कोप कम हो जाएगा, और रिवर्स डिपेंडेंसी
की बढ़ती संख्या को अपडेट करना पड़ेगा.