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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

Xcode और Baज़र के बीच अंतर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. BUILD फ़ाइल बनाने के लिए:

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

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

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

4. (ज़रूरी नहीं) बेहतर तरीके से बने बाइनरी

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

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

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

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

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

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

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

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

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

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

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

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

चरण 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 का वह कम से कम वर्शन जिस पर ऐप्लिकेशन काम करता है. इससे यह पक्का होता है कि Baज़र, ऐप्लिकेशन को सही एपीआई लेवल.

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

Bazel के Apple के लिए बने बिल्ड नियम, iOS और macOS पर लाइब्रेरी पर आधारित यूनिट टेस्ट चलाने के साथ-साथ, macOS पर ऐप्लिकेशन पर आधारित टेस्ट चलाने की सुविधा देते हैं. iOS पर ऐप्लिकेशन-आधारित परीक्षणों के लिए या फिर किसी भी प्लैटफ़ॉर्म के तौर पर, Baze टेस्ट आउटपुट तैयार करेगा, लेकिन टेस्ट Xcode में ही किए जाने चाहिए नियमों_xcodeproj के साथ जनरेट किए गए प्रोजेक्ट के ज़रिए किया जा सकता है. टेस्ट टारगेट इस तरह जोड़ें:

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

• ios_unit_test iOS पर लाइब्रेरी पर आधारित यूनिट टेस्ट चलाने के लिए. iOS से जुड़े टेस्ट के लिए सिम्युलेटर का इस्तेमाल करके, Baze टेस्ट आउटपुट तैयार करेगा, लेकिन टेस्ट नहीं चलाएगा. आपको ऐसा ज़रूर करना चाहिए Terms_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना और Xcode के अंदर से टेस्ट करा सकता है.

• ios_ui_test का इस्तेमाल करके, iOS सिम्युलेटर में यूज़र इंटरफ़ेस टेस्ट करने के लिए ज़रूरी आउटपुट बनाए जा सकते हैं. Xcode का इस्तेमाल करना होगा. आपको rules_xcodeproj की मदद से Xcode प्रोजेक्ट जनरेट करना होगा और Xcode में जाकर टेस्ट चलाने होंगे. Bazel, यूज़र इंटरफ़ेस (यूआई) टेस्ट को नेटिव तौर पर नहीं चला सकता.

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

चरण 3c: लाइब्रेरी के टारगेट जोड़ना

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

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

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

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

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

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

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

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

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

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

• मल्टी-प्लैटफ़ॉर्म ऐप्लिकेशन (macOS, iOS, watchOS, tvOS)

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

इस समय, बिल्ड की जांच करना बेहतर होगा:

bazel build //:<application_target>

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

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

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

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

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

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

प्रोजेक्ट के बारे में ज़्यादा जानकारी देने के लिए सलाह:

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

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

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

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

• सभी पैकेज में यह तय करें कि वे ज़्यादा से ज़्यादा कितने लोगों को दिखें.

• BUILD फ़ाइलों में हर बड़े बदलाव के बाद प्रोजेक्ट बनाएं और उसे ठीक करें आपको गड़बड़ियों का पता चलते ही उन्हें हल करना.

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

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

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

bazel build //:my-target

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

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

समस्या का हल

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

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

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

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

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

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