Xcode से Bazel पर माइग्रेट करना

7.3 · 7.2 · 7.1 · 7.0 · 6.5

इस पेज पर, Bazel की मदद से Xcode प्रोजेक्ट बनाने या उसकी जांच करने का तरीका बताया गया है. यह Xcode और Basel के बीच के अंतर के बारे में बताता है. साथ ही, Xcode प्रोजेक्ट को Basel प्रोजेक्ट में बदलने का तरीका भी बताता है. इसमें सामान्य गड़बड़ियों को ठीक करने के लिए, समस्या हल करने वाले समाधान भी दिए गए हैं.

Xcode और Bazel के बीच अंतर

• Babel के लिए यह ज़रूरी है कि आप हर बिल्ड टारगेट और उसकी डिपेंडेंसी के साथ-साथ बिल्ड नियमों के ज़रिए उनसे जुड़ी बिल्ड सेटिंग भी साफ़ तौर पर बताएं.

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

• Baze के साथ Xcode प्रोजेक्ट बनाते समय, BUILD फ़ाइल(फ़ाइलें) मुख्य फ़ाइल बन जाती हैं. अगर Xcode में प्रोजेक्ट पर काम किया जा रहा है, तो आपको BUILD फ़ाइलों को अपडेट करने पर, rules_xcodeproj का इस्तेमाल करके, Xcode प्रोजेक्ट का नया वर्शन जनरेट करना होगा. यह वर्शन, BUILD फ़ाइलों से मेल खाता है. BUILD फ़ाइलों में कुछ बदलाव करने के लिए, प्रोजेक्ट को फिर से जनरेट करने की ज़रूरत नहीं होती. जैसे, किसी टारगेट में डिपेंडेंसी जोड़ना. इससे डेवलपमेंट में लगने वाला समय कम हो सकता है. अगर Xcode का इस्तेमाल नहीं किया जा रहा है, तो bazel build और bazel test कमांड, बिल्ड और टेस्ट करने की सुविधाएं देते हैं. इन सुविधाओं के बारे में इस गाइड में बाद में बताया गया है.

शुरू करने से पहले

शुरू करने से पहले, ये काम करें:

1. अगर आपने पहले से Bazel इंस्टॉल नहीं किया है, तो ऐसा करें.

2. अगर आपको Bagel और इसके सिद्धांतों के बारे में नहीं पता है, तो iOS ऐप्लिकेशन ट्यूटोरियल पूरा करें. आपको Basel के वर्कस्पेस के साथ-साथ, WORKSPACE और BUILD फ़ाइलों के बारे में भी पता होना चाहिए. इसके अलावा, आपको टारगेट, बिल्ड रूल, और Babel पैकेज के बारे में भी जानकारी होनी चाहिए.

3. प्रोजेक्ट की डिपेंडेंसी का विश्लेषण करें और उन्हें समझें.

प्रोजेक्ट डिपेंडेंसी का विश्लेषण करना

Xcode के उलट, Bazel में आपको BUILD फ़ाइल में हर टारगेट के लिए, सभी डिपेंडेंसी के बारे में साफ़ तौर पर बताना होगा.

एक्सटर्नल डिपेंडेंसी के बारे में ज़्यादा जानकारी के लिए, बाहरी डिपेंडेंसी के साथ काम करना लेख पढ़ें.

Bazel की मदद से Xcode प्रोजेक्ट बनाना या उसका टेस्ट करना

Basel के साथ Xcode प्रोजेक्ट बनाने या टेस्ट करने के लिए, ये काम करें:

1. WORKSPACE फ़ाइल बनाएं

2. (एक्सपेरिमेंटल) SwiftPM डिपेंडेंसी इंटिग्रेट करना

3. BUILD फ़ाइल बनाएं:

   a. ऐप्लिकेशन टारगेट जोड़ना

   b. (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना

   c. लाइब्रेरी के टारगेट जोड़ें

4. (ज़रूरी नहीं) बिल्ड को बेहतर तरीके से तैयार करना

5. बिल्ड चलाना

6. rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना

पहला चरण: WORKSPACE फ़ाइल बनाना

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

ध्यान दें: प्रोजेक्ट सोर्स कोड को WORKSPACE फ़ाइल वाली डायरेक्ट्री ट्री में डालें.

दूसरा चरण: (प्रयोग के तौर पर) SwiftPM डिपेंडेंसी इंटिग्रेट करना

swift_bazel की मदद से, SwiftPM डिपेंडेंसी को Bazel वर्कस्पेस में इंटिग्रेट करने के लिए, आपको उन्हें Bazel पैकेज में बदलना होगा. इसके बारे में इस ट्यूटोरियल में बताया गया है.

ध्यान दें: SwiftPM सहायता एक मैन्युअल प्रोसेस है, जिसमें कई वैरिएबल होते हैं. Bazel के साथ SwiftPM इंटिग्रेशन की पूरी तरह से पुष्टि नहीं की गई है और इसे आधिकारिक तौर पर इस्तेमाल नहीं किया जा सकता.

तीसरा चरण: BUILD फ़ाइल बनाना

वर्कस्पेस और बाहरी डिपेंडेंसी तय करने के बाद, आपको एक BUILD फ़ाइल बनानी होगी. इससे Bazel को पता चलता है कि प्रोजेक्ट का स्ट्रक्चर कैसा है. Basel Workspace के रूट में BUILD फ़ाइल बनाएं और उसे प्रोजेक्ट के शुरुआती बिल्ड के लिए इस तरह से कॉन्फ़िगर करें:

• तीसरा चरण: ऐप्लिकेशन टारगेट जोड़ना
• तीसरा चरण (ज़रूरी नहीं): टेस्ट टारगेट जोड़ना
• चरण 3c: लाइब्रेरी के टारगेट जोड़ना

सलाह: पैकेज और Bazel के अन्य कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, फ़ाइल फ़ोल्डर, पैकेज, और टारगेट लेख पढ़ें.

चरण 3a: ऐप्लिकेशन टारगेट जोड़ना

macos_application या ios_application नियम टारगेट जोड़ें. यह टारगेट, macOS या iOS ऐप्लिकेशन बंडल बनाता है. टारगेट में, कम से कम ये चीज़ें बताएं:

• bundle_id - बाइनरी का बंडल आईडी (ऐप्लिकेशन के नाम के बाद रिवर्स-डीएनएस पाथ).

• provisioning_profile - अपने Apple Developer खाते से प्रोविज़निंग प्रोफ़ाइल (अगर iOS डिवाइस के लिए बनाना है).

• families (सिर्फ़ iOS के लिए) - iPhone, iPad या दोनों के लिए ऐप्लिकेशन बनाना है.

• infoplists - फ़ाइनल Info .plist फ़ाइल में मिलने के लिए.plist फ़ाइलों की सूची.

• minimum_os_version - macOS या iOS का वह कम से कम वर्शन जिस पर ऐप्लिकेशन काम करता है. इससे यह पक्का होता है कि Bazel, ऐप्लिकेशन को सही एपीआई लेवल के साथ बनाए.

तीसरा चरण: (ज़रूरी नहीं) टेस्ट टारगेट जोड़ना

Babel के Apple बिल्ड नियम से सभी Apple प्लैटफ़ॉर्म पर यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट करने की सुविधा मिलती है. टेस्ट टारगेट इस तरह जोड़ें:

• macOS पर लाइब्रेरी-आधारित और ऐप्लिकेशन-आधारित यूनिट टेस्ट चलाने के लिए, macos_unit_test.

• ios_unit_test का इस्तेमाल, iOS पर लाइब्रेरी के हिसाब से यूनिट टेस्ट बनाने और चलाने के लिए किया जाता है.

• ios_ui_test iOS सिम्युलेटर में यूज़र इंटरफ़ेस टेस्ट बनाने और चलाने के लिए.

• tvOS, watchOS, और visionOS के लिए भी टेस्ट के मिलते-जुलते नियम मौजूद हैं.

कम से कम, minimum_os_version एट्रिब्यूट के लिए वैल्यू सेट करें. bundle_identifier और infoplists जैसे पैकेजिंग के अन्य एट्रिब्यूट के लिए, डिफ़ॉल्ट रूप से सबसे ज़्यादा इस्तेमाल की जाने वाली वैल्यू सेट होती हैं. हालांकि, पक्का करें कि ये डिफ़ॉल्ट वैल्यू, प्रोजेक्ट के साथ काम करती हों. साथ ही, ज़रूरत के हिसाब से इनमें बदलाव करें. जिन टेस्ट के लिए iOS सिम्युलेटर की ज़रूरत होती है उनके लिए test_host एट्रिब्यूट की वैल्यू के तौर पर ios_application टारगेट का नाम भी बताएं.

तीसरा चरण: लाइब्रेरी टारगेट जोड़ना

हर Objective-C लाइब्रेरी के लिए objc_library टारगेट और हर उस Swift लाइब्रेरी के लिए swift_library टारगेट जोड़ें जिस पर ऐप्लिकेशन और/या टेस्ट निर्भर करते हैं.

लाइब्रेरी टारगेट को इस तरह जोड़ें:

• ऐप्लिकेशन लाइब्रेरी टारगेट को ऐप्लिकेशन टारगेट पर डिपेंडेंसी के तौर पर जोड़ें.

• टेस्ट लाइब्रेरी टारगेट को, टेस्ट टारगेट की डिपेंडेंसी के तौर पर जोड़ें.

• srcs एट्रिब्यूट में, लागू करने के सोर्स की सूची बनाएं.

• hdrs एट्रिब्यूट में हेडर की सूची बनाएं.

ध्यान दें: किसी खास टाइप के सभी सोर्स और/या हेडर शामिल करने के लिए, glob फ़ंक्शन का इस्तेमाल किया जा सकता है. इसका इस्तेमाल सोच-समझकर करें, क्योंकि इसमें ऐसी फ़ाइलें भी शामिल हो सकती हैं जिन्हें आपको Basel को बनाने की अनुमति नहीं है.

आप अलग-अलग तरह के ऐप्लिकेशन के लिए मौजूदा उदाहरणों को सीधे rules_apple उदाहरण डायरेक्ट्री में ब्राउज़ कर सकते हैं. उदाहरण के लिए:

• macOS ऐप्लिकेशन टारगेट

• iOS ऐप्लिकेशन टारगेट

• एक से ज़्यादा प्लैटफ़ॉर्म वाले ऐप्लिकेशन (macOS, iOS, watchOS, tvOS)

बिल्ड नियमों के बारे में ज़्यादा जानने के लिए, Bazel के लिए Apple के नियम देखें.

इस समय, बने हुए वर्शन की जांच करना अच्छा रहेगा:

bazel build //:<application_target>

चौथा चरण: (ज़रूरी नहीं) बाइनरी को ज़्यादा बेहतर बनाना

अगर प्रोजेक्ट बड़ा है या जैसे-जैसे यह बढ़ता जा रहा है, तो इसे कई बेज़ल पैकेज में बांटें. ज़्यादा जानकारी देने से ये फ़ायदे मिलते हैं:

• बाइनरी के इंक्रीमेंट में बढ़ोतरी,

• बिल्ड टास्क पर एक साथ ज़्यादा काम करना,

• आने वाले समय के उपयोगकर्ताओं के लिए बेहतर रखरखाव,

• टारगेट और पैकेज में, सोर्स कोड को देखने की सेटिंग पर बेहतर कंट्रोल. इससे, लाइब्रेरी में लागू करने की जानकारी, सार्वजनिक एपीआई में लीक होने जैसी समस्याओं से बचा जा सकता है.

प्रोजेक्ट की जानकारी देने के लिए सलाह:

• हर लाइब्रेरी को उसके अपने Bazel पैकेज में डालें. कम डिपेंडेंसी की ज़रूरत वाले ऐप्लिकेशन से शुरुआत करें और डिपेंडेंसी ट्री तक अपने हिसाब से काम करें.

• BUILD फ़ाइलें जोड़ने और टारगेट तय करने के दौरान, इन नए टारगेट को उन टारगेट के deps एट्रिब्यूट में जोड़ दें जो उन पर निर्भर करते हैं.

• glob() फ़ंक्शन, पैकेज की सीमाओं को पार नहीं करता है. इसलिए, पैकेज की संख्या बढ़ने पर glob() से मेल खाने वाली फ़ाइलें कम हो जाती हैं.

• किसी BUILD फ़ाइल को main डायरेक्ट्री में जोड़ते समय, उससे जुड़ी test डायरेक्ट्री में BUILD फ़ाइल भी जोड़ें.

• सभी पैकेज के लिए, विज्ञापन दिखने की सीमाएं लागू करें.

• BUILD फ़ाइलों में किए गए हर बड़े बदलाव के बाद, प्रोजेक्ट को बिल्ड करें. साथ ही, बिल्ड करने से जुड़ी गड़बड़ियों को ठीक करें.

पांचवां चरण: बिल्ड चलाना

पूरी तरह माइग्रेट किए गए बिल्ड को चलाकर, पक्का करें कि यह बिना किसी गड़बड़ी या चेतावनी के पूरा हो जाए. हर ऐप्लिकेशन और टेस्ट टारगेट को अलग-अलग चलाएं, ताकि किसी भी गड़बड़ी के सोर्स को आसानी से ढूंढा जा सके.

उदाहरण के लिए:

bazel build //:my-target

छठा चरण: criteria_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना

Bazel का इस्तेमाल करके बिल्ड करते समय, WORKSPACE और BUILD फ़ाइलें, बिल्ड के बारे में सटीक जानकारी देने वाली फ़ाइलें बन जाती हैं. Xcode को इस बारे में बताने के लिए, आपको rules_xcodeproj का इस्तेमाल करके, Bazel के साथ काम करने वाला Xcode प्रोजेक्ट जनरेट करना होगा.

समस्या का हल

Bazel में गड़बड़ियां तब हो सकती हैं, जब यह चुने गए Xcode वर्शन के साथ सिंक न हो. जैसे, अपडेट लागू करने पर. अगर आपको Xcode में गड़बड़ियां आ रही हैं, तो यहां दी गई कुछ बातों को आज़माएं. उदाहरण के लिए, "Apple CROSSTOOL का इस्तेमाल करने के लिए, Xcode वर्शन की जानकारी देना ज़रूरी है".

• Xcode को मैन्युअल तरीके से चलाएं और सभी नियम और शर्तें स्वीकार करें.

• Xcode चुनने का इस्तेमाल करके सही वर्शन बताएं, लाइसेंस स्वीकार करें, और बेज़ल की स्थिति मिटाएं.

  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  sudo xcodebuild -license
  bazel sync --configure

• अगर यह काम नहीं करता, तो आप bazel clean --expunge चलाकर भी देख सकते हैं.

ध्यान दें: अगर आपने अपने Xcode को किसी दूसरे पाथ में सेव किया है, तो उस पाथ पर ले जाने के लिए, xcode-select -s का इस्तेमाल किया जा सकता है.