अतिरिक्त Xcode एसडीके - यह क्या है और आपको इसकी आवश्यकता क्यों नहीं है

Apple दुनिया के लिए बहुत कुछ लेकर आया है। सफल नवाचारों की जड़ें होती हैं, और छोटी-छोटी मौतों से असफल। वैसे, कुछ असफल निर्णय नहीं हैं, और मुझे लगता है कि यह बिल्कुल सामान्य है। अंत में, हम जोखिम लेने और प्रयोग करने की अपनी इच्छा के लिए Apple का सम्मान करते हैं :)

यह सब पूरी तरह से विकास के साधनों पर लागू होता है। पिछली पोस्ट में, मैंने Xcode में हेडर फ़ाइलों को खोजने के लिए एक गैर-मानक एल्गोरिथ्म के बारे में लिखा था। आज मैं तथाकथित एसडीके पर ध्यान केंद्रित करना चाहता हूं - एक्सकोड में यह शब्द आईओएस या मैक ओएस के एक विशिष्ट संस्करण के लिए पुस्तकालयों और हेडर फ़ाइलों के एक सेट को संदर्भित करता है। हमें XCode की समझ में SDK की आवश्यकता क्यों है?

• प्रत्येक एसडीके अपने अलग फ़ोल्डर में है और अन्य एसडीके में दर्द रहित सह-कलाकार हैं - यह आपको एक कंप्यूटर पर विभिन्न ओएस के लिए विकास का संचालन करने की अनुमति देता है। पहले, एसडीके / डेवलपर / एसडीके में थे; चौथी xCode श्रृंखला द्वारा, वे xCode.app के अंदर चले गए।
• ओएस के एक विशिष्ट संस्करण के लिए एक परियोजना की स्थापना एक तुच्छ मामला है। यह एसडीके को प्रोजेक्ट सेटिंग्स में निर्दिष्ट करने के लिए पर्याप्त है।

तकनीकी रूप से, इसे निम्नानुसार लागू किया जाता है। Apple ने कंपाइलर में --sysroot स्विच जोड़ा। शीर्ष लेख फ़ाइलों और पुस्तकालयों की खोज के लिए पथ में उपसर्ग के रूप में sysroot मान जोड़ा जाता है। दोनों मानक पथ (उदा: / usr / शामिल) और -I और -L विकल्पों के साथ जोड़े गए उपयोगकर्ता पथ इस संशोधन से प्रभावित हैं।

यह निम्नानुसार काम करता है। मान लें कि macosx10.6 SDK को Xcode सेटिंग्स में चुना गया है। Xcode संकलक को --sysroot = / Developer / SDKs / MacOSX10.6.sdk स्विच पास करता है। परिणामस्वरूप, / usr / / /eeveloper/SDKs/MacOSX10.6.sdk/usr/include में शामिल हो जाता है। पुस्तकालयों और रूपरेखाओं को खोजने के लिए पथों के साथ भी यही होता है। जैसा कि आप आसानी से अनुमान लगा सकते हैं, एसडीके के अंदर usr / शामिल हैं और इसी सामग्री के साथ usr / lib हैं।

अब यह Xcode में गुप्त "अतिरिक्त एसडीके" विकल्प पर आगे बढ़ने का समय है।

इसकी आवश्यकता क्यों है? मान लीजिए आप एक मिडलवेयर कंपनी हैं। आप अपने पुस्तकालयों और रूपरेखाओं को एक Xcode एसडीके के रूप में डिज़ाइन करते हैं। परियोजना में अपने मिडलवेयर का उपयोग करने के लिए, बस अपने एसडीके के लिए पूर्ण पथ निर्दिष्ट करें अतिरिक्त एसडीके अनुभाग में एक्सकोड सेटिंग्स में। हैडर फाइलें और लाइब्रेरी अपने आप उपलब्ध हो जाती हैं।

वैसे, आप एक ही समय में कई अतिरिक्त एसडीके का उपयोग कर सकते हैं।

दुर्भाग्य से, जैसा कि अक्सर होता है, कार्यान्वयन एक सुंदर विचार को बर्बाद कर रहा है।

अतिरिक्त एसडीके का समर्थन करने के लिए, Xcode को बहुत सारे अतिरिक्त काम करने पड़ते हैं, जो प्रोजेक्ट बनाते समय ब्रेक द्वारा प्रकट होता है। उपयोग किए गए आधार और अतिरिक्त एसडीके के प्रत्येक संयोजन के लिए, सभी एसडीके से फ़ाइलों का एक संयुक्त पेड़ अस्थायी फ़ोल्डर में बनाया गया है और इस फ़ोल्डर का मार्ग --sysroot पर स्थानांतरित कर दिया गया है। फ़ाइलों की ईमानदारी से नकल करने के बजाय, सीमलिंक का उपयोग किया जाता है, लेकिन फिर भी यह प्रक्रिया तेज नहीं है।

जो लोग अतिरिक्त एसडीके के साथ प्रयोग करना चाहते हैं, मैंने गीथूब पर एक परियोजना तैयार की। SDKSettings.plist पर ध्यान दें। एसडीके को "पहचान" करने के लिए यह फाइल Xcode के लिए आवश्यक है।

मेरी परियोजनाओं में, मैं अतिरिक्त एसडीके का उपयोग नहीं करता हूं और इसके बजाय हेडर, लाइब्रेरी और फ्रेमवर्क की खोज के लिए पथों को मैन्युअल रूप से कॉन्फ़िगर करता हूं।

बोनस: एसडीके और ओएस संस्करण

ओएस के प्रत्येक अगले संस्करण के लिए, एक नया एसडीके जारी किया गया है। हालांकि, इसका मतलब यह नहीं है कि macosx10.8 एसडीके के साथ संकलित एक परियोजना केवल मैक ओएस एक्स 10.8 पर काम करेगी और पहले के ओएस पर शुरू नहीं होगी।

एसडीके संस्करण 10.8 का मतलब है कि एसडीके में वे सभी एपीआई शामिल हैं जो मैक ओएस एक्स 10.8 और पहले के सिस्टम (अपग्रेड किए गए एपीआई को छोड़कर) पर उपलब्ध हैं। यदि प्रोजेक्ट OS X 10.6 में उपलब्ध सुविधाओं का उपयोग नहीं करता है, तो प्रोजेक्ट 10.6 पर समस्याओं के बिना काम करेगा।

एक और दिलचस्प स्थिति यह है कि जब हम नई सुविधाओं का उपयोग करते हैं, अगर वे उपलब्ध हैं, और पुराने सिस्टम के लिए हम एक वैकल्पिक कार्यान्वयन का उपयोग करते हैं। हम इसके लिए कमजोर लिंकिंग का उपयोग करते हैं। "कमजोर रूप से जुड़ा हुआ" या तो एक संपूर्ण गतिशील पुस्तकालय या एक गतिशील पुस्तकालय से अलग कार्य हो सकता है। यदि शुरुआत में यह कमजोर रूप से लिंक किए गए पुस्तकालय को खोजने के लिए संभव नहीं है, तो कार्यक्रम चलता रहेगा जैसे कि कुछ भी नहीं हुआ था, और लिंकर गायब कार्यों के पते के रूप में NULL को स्थानापन्न करेगा। बेशक, यदि आप एक फ़ंक्शन को कॉल करते हैं जो वहां नहीं है, तो प्रोग्राम क्रैश हो जाएगा।

इसलिए, कॉल करने से पहले, हम NULL के साथ फ़ंक्शन के पते की तुलना करते हैं, और यदि फ़ंक्शन उपलब्ध नहीं है, तो हम एक वैकल्पिक कार्यान्वयन का उपयोग करते हैं।

मैक ओएस का न्यूनतम समर्थित संस्करण परियोजना सेटिंग्स (MACOSX_DEPLOYMENT_TARGET) में निर्दिष्ट है। कमजोर लिंकिंग के लिए सभी बाद में एपीआई स्वचालित रूप से चिह्नित किए जाते हैं। यह मैक्रोज़ का उपयोग करके किया जाता है जो /usr/include/Avucation.h में घोषित किए जाते हैं।