इस पेज पर, Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने का तरीका बताया गया है. यह Xcode और Bazel के बीच अंतर बताता है. साथ ही, Xcode प्रोजेक्ट को Bazel प्रोजेक्ट में बदलने का तरीका बताता है. इससे, आम गड़बड़ियों को ठीक करने के लिए समस्या हल करने का तरीका भी मिलता है.
Xcode और Bazel में अंतर
Bazel के लिए ज़रूरी है कि आप हर बिल्ड टारगेट और उसकी डिपेंडेंसी के साथ बिल्ड नियमों के ज़रिए उससे जुड़ी बिल्ड सेटिंग साफ़ तौर पर बताएं.
Bazel के लिए ज़रूरी है कि वह सभी फ़ाइलें जिस पर प्रोजेक्ट, फ़ाइल फ़ोल्डर की डायरेक्ट्री में मौजूद हो या
WORKSPACE
फ़ाइल में इंपोर्ट के तौर पर बताई गई हो.Bazel के साथ Xcode प्रोजेक्ट बनाते समय,
BUILD
फ़ाइल(फ़ाइलें) सच का सोर्स बन जाती है. अगर आप Xcode में प्रोजेक्ट पर काम करते हैं, तो आपको जब भीBUILD
फ़ाइलें अपडेट करनी हों, तब rules_xcodeproj का इस्तेमाल करके, Xcode प्रोजेक्ट का एक नया वर्शन जनरेट करना होगा जोBUILD
फ़ाइलों से मेल खाए.BUILD
फ़ाइलों में होने वाले कुछ बदलावों, जैसे कि किसी टारगेट के लिए डिपेंडेंसी जोड़ना. इसके लिए प्रोजेक्ट को फिर से जनरेट नहीं करना पड़ता. इससे डेवलपमेंट में तेज़ी आती है. अगर Xcode का इस्तेमाल नहीं किया जा रहा है, तोbazel build
औरbazel test
निर्देश, बिल्ड और टेस्ट की सुविधाएं देते हैं. हालांकि, इनके बारे में इस गाइड में आगे बताया गया है.
शुरू करने से पहले
शुरू करने से पहले, ये काम करें:
अगर आपने पहले से ऐसा नहीं किया है, तो Bzel इंस्टॉल करें.
अगर आपको Bazel और इसके सिद्धांतों के बारे में नहीं पता है, तो iOS ऐप्लिकेशन ट्यूटोरियल पूरा करें. आपको Bazel फ़ाइल फ़ोल्डर के बारे में जानकारी होनी चाहिए, जिसमें
WORKSPACE
औरBUILD
फ़ाइलें भी शामिल हैं. साथ ही, आपको टारगेट, बिल्ड के नियम, और Bazel पैकेज के कॉन्सेप्ट के बारे में भी पता होना चाहिए.प्रोजेक्ट की डिपेंडेंसी का विश्लेषण करें और समझें.
प्रोजेक्ट डिपेंडेंसी का विश्लेषण करें
Xcode से अलग, Bazel के लिए BUILD
फ़ाइल में हर टारगेट के लिए, सभी डिपेंडेंसी साफ़ तौर पर बताने की ज़रूरत होती है.
बाहरी डिपेंडेंसी के बारे में ज़्यादा जानने के लिए, बाहरी डिपेंडेंसी के साथ काम करना देखें.
Bazel की मदद से Xcode प्रोजेक्ट बनाना या टेस्ट करना
Bazel के साथ Xcode प्रोजेक्ट बनाने या टेस्ट करने के लिए, ये काम करें:
पहला चरण: WORKSPACE
फ़ाइल बनाएं
नई डायरेक्ट्री में WORKSPACE
फ़ाइल बनाएं. यह डायरेक्ट्री, Bazel
वर्कस्पेस रूट बन गई है. अगर यह प्रोजेक्ट किसी बाहरी डिपेंडेंसी का इस्तेमाल नहीं करता है, तो इस फ़ाइल को खाली छोड़ा जा सकता है. अगर प्रोजेक्ट उन फ़ाइलों या पैकेज पर निर्भर करता है जो किसी प्रोजेक्ट की डायरेक्ट्री में नहीं हैं, तो WORKSPACE
फ़ाइल में इन बाहरी डिपेंडेंसी के बारे में बताएं.
दूसरा चरण: (प्रयोग के तौर पर) SwiftPM डिपेंडेंसी इंटिग्रेट करें
swift_bazel के साथ Bazel वर्कस्पेस में SwiftPM डिपेंडेंसी जोड़ने के लिए, आपको उन्हें Bazel पैकेज में बदलना होगा. इसके बारे में नीचे दिए गए ट्यूटोरियल में बताया गया है.
तीसरा चरण: BUILD
फ़ाइल बनाना
फ़ाइल फ़ोल्डर और बाहरी डिपेंडेंसी तय करने के बाद, आपको एक BUILD
फ़ाइल बनानी होगी. इससे, Bazel को पता चलेगा कि प्रोजेक्ट किस तरह से स्ट्रक्चर किया गया है. BUILD
फ़ाइल को Bazel वर्कस्पेस के रूट में बनाएं और इसे प्रोजेक्ट का शुरुआती बिल्ड करने के लिए, इस तरह से कॉन्फ़िगर करें:
- तीसरे चरण का पहला हिस्सा: ऐप्लिकेशन टारगेट जोड़ना
- तीसरा चरण (b): (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना
- तीसरा चरण(c): लाइब्रेरी के टारगेट जोड़ना
सलाह: पैकेज और Bazel के अन्य कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, फ़ाइल फ़ोल्डर, पैकेज, और टारगेट देखें.
तीसरे चरण का पहला हिस्सा: ऐप्लिकेशन टारगेट जोड़ना
macos_application
या ios_application
नियम टारगेट जोड़ें. यह टारगेट, macOS या iOS ऐप्लिकेशन बंडल बनाता है.
टारगेट में, कम से कम यह जानकारी दें:
bundle_id
- बाइनरी का बंडल आईडी (रिवर्स-डीएनएस पाथ के बाद ऐप्लिकेशन का नाम).provisioning_profile
- आपके Apple डेवलपर खाते की प्रोफ़ाइल का प्रावधान (अगर किसी iOS डिवाइस डिवाइस के लिए बनाया जा रहा है).families
(सिर्फ़ iOS के लिए) - ऐप्लिकेशन को iPhone, iPad या दोनों के लिए बनाना है या नहीं.infoplists
- अंतिम Info .plist फ़ाइल में मर्ज करने के लिए.plist फ़ाइलों की सूची.minimum_os_version
- macOS या iOS का सबसे कम वर्शन, जो ऐप्लिकेशन पर काम करता है. इससे यह पक्का होता है कि Bazel, ऐप्लिकेशन को सही एपीआई लेवल के साथ बनाता है.
चरण 3b: (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना
Bazel के Apple बिल्ड नियम, Apple के सभी प्लैटफ़ॉर्म पर चलने वाली यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट की सुविधा देते हैं. टेस्ट टारगेट इस तरह जोड़ें:
macos_unit_test
का इस्तेमाल, macOS पर लाइब्रेरी और ऐप्लिकेशन के हिसाब से यूनिट टेस्ट करने के लिए किया जा सकता है.ios_unit_test
iOS पर लाइब्रेरी-आधारित यूनिट टेस्ट बनाने और चलाने के लिए.ios_ui_test
iOS सिम्युलेटर में यूज़र इंटरफ़ेस टेस्ट बनाने और चलाने के लिए.जांच के यही नियम tvOS, watchOS, और visionOS के लिए भी उपलब्ध हैं.
कम से कम, minimum_os_version
एट्रिब्यूट के लिए वैल्यू तय करें. पैकेजिंग से जुड़े दूसरे एट्रिब्यूट, जैसे कि bundle_identifier
और infoplists
, आम तौर पर इस्तेमाल की जाने वाली वैल्यू पर डिफ़ॉल्ट रूप से सेट होते हैं. इसलिए, पक्का करें कि वे डिफ़ॉल्ट वैल्यू प्रोजेक्ट के साथ काम करती हों. साथ ही, इनमें ज़रूरत के मुताबिक बदलाव भी किए जाते हैं. जिन जांच में iOS सिम्युलेटर की ज़रूरत होती है उनमें test_host
एट्रिब्यूट की वैल्यू के तौर पर ios_application
टारगेट का नाम भी बताएं.
तीसरा चरण(c): लाइब्रेरी के टारगेट जोड़ना
हर ऑब्जेक्टिव-सी लाइब्रेरी के लिए, objc_library
टारगेट जोड़ें. साथ ही, हर उस Swift लाइब्रेरी के लिए एक swift_library
टारगेट जोड़ें जिस पर ऐप्लिकेशन और/या टेस्ट निर्भर करते हैं.
लाइब्रेरी टारगेट इस तरह जोड़ें:
ऐप्लिकेशन लाइब्रेरी टारगेट को, ऐप्लिकेशन टारगेट के डिपेंडेंसी के तौर पर जोड़ें.
टेस्ट लाइब्रेरी टारगेट को, टेस्ट टारगेट के लिए डिपेंडेंसी के तौर पर जोड़ें.
srcs
एट्रिब्यूट में, लागू किए जाने वाले सोर्स की सूची बनाएं.hdrs
एट्रिब्यूट में हेडर की सूची बनाएं.
आप सीधे rules_apple के उदाहरणों की डायरेक्ट्री में, अलग-अलग तरह के ऐप्लिकेशन के लिए मौजूदा उदाहरणों को ब्राउज़ कर सकते हैं. उदाहरण के लिए:
बिल्ड के नियमों के बारे में ज़्यादा जानने के लिए, Apple Rules for Bazel देखें.
यहां दिए गए समय में, बिल्ड की जांच करना अच्छा आइडिया है:
bazel build //:<application_target>
चौथा चरण: (ज़रूरी नहीं) बिल्ड को बड़ा करना
अगर प्रोजेक्ट बड़ा हो या बड़ा हो रहा हो, तो उसे कई बज़ल पैकेज में चंककर देखें. जानकारी के इस स्तर में बढ़ोतरी से, यह जानकारी मिलती है:
पहले से ज़्यादा बिल्ड,
बिल्ड टास्क को एक साथ बेहतर तरीके से चलाना,
आने वाले समय के उपयोगकर्ताओं के लिए रखरखाव की बेहतर सुविधा,
सभी टारगेट और पैकेज में, सोर्स कोड दिखने की सेटिंग पर बेहतर कंट्रोल होता है. इससे, ऐसी लाइब्रेरी से बचने में मदद मिलती है जिनमें एपीआई लागू करने से जुड़ी जानकारी सार्वजनिक एपीआई में लीक हो जाती है.
प्रोजेक्ट के बारे में खास जानकारी देने के लिए सलाह:
हर लाइब्रेरी को उसके Bazel पैकेज में रखें. कम डिपेंडेंसी के साथ शुरुआत करें और डिपेंडेंसी ट्री सेट करें.
BUILD
फ़ाइलें जोड़ने और टारगेट तय करने के बाद, इन नए टारगेट को उन टारगेट केdeps
एट्रिब्यूट में जोड़ दें जो इन पर निर्भर हैं.glob()
फ़ंक्शन, पैकेज की सीमाएं पार नहीं करता है. इसलिए, पैकेज की संख्या बढ़ने पर,glob()
से मेल खाने वाली फ़ाइलें कम हो जाएंगी.main
डायरेक्ट्री मेंBUILD
फ़ाइल जोड़ते समय, इससे जुड़ीtest
डायरेक्ट्री मेंBUILD
फ़ाइल भी जोड़ें.सभी पैकेज में सही तरीके से दिखने की सीमा लागू करें.
BUILD
फ़ाइलों में किए गए हर बड़े बदलाव के बाद प्रोजेक्ट बनाएं और गड़बड़ियां मिलने पर उन्हें ठीक करें.
पांचवां चरण: बिल्ड चलाना
पूरी तरह से माइग्रेट किया गया बिल्ड चलाएं, ताकि यह पक्का किया जा सके कि यह बिना किसी गड़बड़ी या चेतावनी के पूरा हो. हर ऐप्लिकेशन को अलग-अलग चलाएं और टारगेट को अलग-अलग चलाएं, ताकि किसी भी गड़बड़ी के स्रोत को आसानी से ढूंढा जा सके.
उदाहरण के लिए:
bazel build //:my-target
छठा चरण: actions_xcodeproj के साथ Xcode प्रोजेक्ट जनरेट करना
Bazel के साथ बनाते समय, WORKSPACE
और BUILD
फ़ाइलें, बिल्ड की सही जानकारी देती हैं. Xcode को इसके बारे में बताने के लिए, आपको rules_xcodeproj का इस्तेमाल करके, Bazel के साथ काम करने वाला Xcode प्रोजेक्ट जनरेट करना होगा.
समस्या हल करना
जब डिवाइस को चुने गए Xcode वर्शन के साथ सिंक नहीं किया जाता है, तब Bazel की गड़बड़ियां हो सकती हैं. जैसे, कोई अपडेट लागू करने पर. अगर आपको Xcode में गड़बड़ियां दिख रही हैं, तो इसे आज़माएं. उदाहरण के लिए, "Apple CROSSTOOL का इस्तेमाल करने के लिए Xcode वर्शन तय होना चाहिए".
मैन्युअल रूप से Xcode चलाएं और सभी नियम और शर्तें स्वीकार करें.
सही वर्शन दिखाने के लिए Xcode 'चुनें' का इस्तेमाल करें. साथ ही, लाइसेंस स्वीकार करें, और Bazel का स्टेटस मिटाएं.
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license
bazel sync --configure
- अगर इससे काम नहीं बनता है, तो आप
bazel clean --expunge
चलाकर देखें.