PostgreSQL डेवलपर के रूप में, मुझे कभी-कभी विंडोज़ पर अपना कोड काम करने की आवश्यकता होती है। जैसा कि मैं सामान्य रूप से विंडोज का उपयोग नहीं करता हूं और मेरे पास स्थायी विंडोज इंस्टॉलेशन नहीं है, यह हमेशा थोड़ा बोझिल रहा है। मैंने इसे आसान बनाने के लिए कुछ तकनीकों का विकास किया है, और मुझे लगता है कि वे साझा करने लायक हैं। और वास्तव में यह पाठ काफी लंबा हो गया था, इसलिए यह कई ब्लॉग पोस्ट की एक श्रृंखला होगी।
पहली बात जो समझने में उपयोगी है वह है विभिन्न प्रकार के विंडोज़ बिल्ड लक्ष्य और वे कैसे समान और भिन्न हैं।
यकीनन, विंडोज़ के निर्माण का प्राथमिक तरीका माइक्रोसॉफ्ट विजुअल स्टूडियो . का उपयोग कर रहा है संकलक सुइट। इसे आप सबसे मूल परिवेश के रूप में सोच सकते हैं। अधिकांश यदि विंडोज़ के लिए पोस्टग्रेएसक्यूएल के सभी बाइनरी वितरण इस बिल्ड का उपयोग नहीं करते हैं। यह बिल्ड सामान्य यूनिक्स मेकफ़ाइल्स का उपयोग नहीं करता है बल्कि src/tools/msvc/ के अंतर्गत एक अलग बिल्ड सिस्टम का उपयोग करता है। . यह मेकफाइल्स को पार्स करता है और इसमें कुछ कस्टम लॉजिक होते हैं और इस टूल चेन के लिए विशिष्ट "प्रोजेक्ट" फाइलें बनाता है, जिसे आप कोड बनाने के लिए चला सकते हैं। आइए इसे यहां MSVC बिल्ड कहते हैं। यह बिल्ड दो तरह से टूटने का खतरा है:एक, यदि कोड वास्तव में विंडोज पर नहीं बनता या चलता है, और दूसरा, यदि आप सामान्य (मेकफाइल-आधारित) बिल्ड सिस्टम में कुछ बदलते हैं जो उन एड-हॉक स्क्रिप्ट का कारण बनता है टूटना। इसलिए इससे निपटने में हमेशा बहुत मज़ा आता है।
दूसरा तरीका है MinGW . का उपयोग करना . यह विंडोज़ पर मूल कोड बनाने के लिए जीएनयू टूलचेन (जीसीसी, जीएनयू बिनुटिल्स, जीएनयू एलडी, आदि) का उपयोग करता है। आप इसे "विंडोज़ पर जीसीसी" के रूप में सोच सकते हैं, लेकिन वास्तव में इसमें विंडोज सिस्टम लाइब्रेरी के साथ इंटरफेस करने के लिए अतिरिक्त शिम और ग्लू होता है। यह कॉन्फ़िगर और मेकफ़ाइल्स का उपयोग करके सामान्य यूनिक्स-ईश बिल्ड सिस्टम का उपयोग करता है, लेकिन यह जो कोड उत्पन्न करता है वह मूल विंडोज कोड है, सिद्धांत रूप में एमएसवीसी बिल्ड के आउटपुट के बराबर है। इसका मतलब यह भी है कि यदि कोड MSVC बिल्ड के साथ नहीं बनता या चलता है, तो यह यहां भी नहीं बनेगा या नहीं चलेगा। लेकिन बिल्ड सिस्टम लिनक्स आदि के समान ही है, इसलिए इसे गलती से तोड़ना कठिन होगा।
तीसरा तरीका है साइगविन . सिगविन एक सबसिस्टम है जो विंडोज़ पर पॉज़िक्स जैसा वातावरण प्रस्तुत करता है। उदाहरण के लिए, सिगविन उपयोगकर्ताओं, समूहों को जोड़ता है, fork() , SysV साझा स्मृति, और अन्य सुविधाएं जो मूल विंडोज़ पर मौजूद नहीं हैं लेकिन मानक हैं, कहें, लिनक्स। विचार यह है कि आप लिनक्स या बीएसडी के लिए स्रोत कोड ले सकते हैं और इसे बिना बदलाव के सिगविन के तहत बना सकते हैं (या कम से कम केवल उन परिवर्तनों के साथ जो यूनिक्स जैसी प्रणालियों के बीच पोर्टिंग परिवर्तनों की सामान्य सीमा के भीतर होंगे)। इस कारण से, PostgreSQL का एक Cygwin पोर्ट मूल Windows पोर्ट से बहुत पहले मौजूद था, क्योंकि यह बहुत छोटा प्रयास था। व्यवहार में, अमूर्तता कुछ क्षेत्रों में टूट जाती है, विशेष रूप से नेटवर्किंग कोड और फ़ाइल नामकरण और पहुंच के आसपास, लेकिन सामान्य तौर पर अन्य लक्ष्यों की तुलना में सिगविन बिल्ड बहुत कम ही टूटता है।
विंडोज़ पर निर्माण करने का एक और तरीका होता था। वहाँ थे win32.mak फ़ाइलें जिन्हें आप सीधे विंडोज़ पर एनएमके के साथ उपयोग कर सकते हैं, और कुछ बिंदु पर बोर्लैंड कंपाइलर्स के लिए भी समर्थन था। मूल रूप से पूर्ण देशी बंदरगाह आने से पहले विंडोज़ पर मूल रूप से libpq बनाने के लिए ये मूल रूप से स्टॉपगैप उपाय थे। इन्हें अब हटा दिया गया है।
इस संदर्भ में एक और शब्द है:MSYS . इसका कारण यह है कि मिनजीडब्ल्यू अपने आप में अक्सर उपयोगी नहीं होता है। यह सिर्फ एक कंपाइलर टूल चेन है। लेकिन विशिष्ट यूनिक्स सॉफ़्टवेयर बनाने के लिए, आपको अतिरिक्त टूल की आवश्यकता होती है जैसे बैश, मेक, सेड, ग्रेप, और वे सभी चीजें जो आमतौर पर कॉन्फ़िगर स्क्रिप्ट या मेकफ़ाइल से उपयोग की जाती हैं। ये सभी उपकरण मूल विंडोज पोर्ट के रूप में मौजूद नहीं हैं। लेकिन आप उन्हें सिगविन सबसिस्टम के शीर्ष पर चला सकते हैं। तो मिनजीडब्ल्यू का उपयोग करने का एक तरीका सिगविन के अंदर से है। एक और MSYS है, जो "न्यूनतम प्रणाली" के लिए खड़ा है, जो मोटे तौर पर Cygwin का एक bespoke सबसेट और विशेष रूप से सॉफ़्टवेयर के निर्माण के लिए MinGW का उपयोग करने के लिए कुछ पैकेजिंग बोल रहा है। जहाँ तक मुझे पता है मूल MSYS अब छोड़ दिया गया है, लेकिन एक लोकप्रिय नया विकल्प MSYS2 है। इसके बारे में बाद के ब्लॉग पोस्ट में। अभी के लिए इन सभी अलग-अलग सॉफ्टवेयर पैकेजों के बीच के संबंध को समझें।
अब आइए विचार करें कि स्रोत कोड इन विभिन्न बिल्ड परिवेशों को कैसे देखता है।
MSVC या MinGW का उपयोग करने वाला एक मूल निर्माण _WIN32 . को परिभाषित करता है . (अजीब बात यह है कि 32-बिट और 64-बिट बिल्ड दोनों के लिए यह मामला है। 64-बिट बिल्ड _WIN64 को भी परिभाषित करता है। , लेकिन इसका उपयोग शायद ही कभी किया जाता है।) PostgreSQL स्रोत कोड WIN32 . का उपयोग करता है इसके बजाय, लेकिन यह PostgreSQL के लिए विशिष्ट है, संकलक द्वारा नहीं किया गया है।
MSVC _MSC_VER . को भी परिभाषित करता है कुछ संस्करण संख्या के लिए। यह कभी-कभी किसी विशेष कंपाइलर संस्करण के साथ मुद्दों के आसपास काम करने के लिए उपयोगी होता है (अक्सर जिस तरह की चीज यूनिक्स बनाता है वह कॉन्फ़िगर का उपयोग करेगा)। ध्यान दें कि MinGW _MSC_VER . को परिभाषित नहीं करता है , इसलिए इसे भी संभालने के लिए कोड को सावधानीपूर्वक लिखने की आवश्यकता है। इसके आस-पास कुछ छोटी-मोटी त्रुटियां हैं क्योंकि कोड जैसे #if _MSC_VER < NNNN शायद एक पुराने कंपाइलर के साथ किसी समस्या के आसपास काम करने के लिए मिनजीडब्ल्यू पर भी ट्रिगर होगा, जिसका इरादा नहीं हो सकता था। (अधिक सही होगा #if defined(_MSC_VER) && _MSC_VER < NNNN और निश्चित रूप से #ifdef WIN32 . में लपेटें .) MinGW __MINGW32__ . को परिभाषित करता है और __MINGW64__ , लेकिन इनका उपयोग बहुत ही कम किया जाता है। साथ ही, MinGW निश्चित रूप से __GNUC__ . को परिभाषित करता है चूंकि यह जीसीसी है, इसलिए जीसीसी या जीसीसी संस्करण के लिए विशिष्ट सशर्त कोड का भी उपयोग किया जा सकता है। सामान्य तौर पर, चूंकि MinGW Autoconf का उपयोग करता है, उन चीजों को आमतौर पर configure . में चेक किया जाना चाहिए कोड के बजाय।
Cygwin __CYGWIN__ . को परिभाषित करता है . विशेष रूप से, Cygwin _WIN32 . को परिभाषित नहीं करता है , या WIN32 , और इसी तरह - क्योंकि यह खुद को देशी विंडोज नहीं मानता है। यही कारण है कि कुछ कोड क्षेत्रों में जहां विंडोज सिगविन एब्स्ट्रैक्शन के माध्यम से देखता है, आपको #if defined(WIN32) || के साथ बहुत सारे कोड दिखाई देते हैं। दोनों मामलों को संभालने के लिए।
defined(__CYGWIN__)
(कोड में कुछ धूल भरे कोने हैं जो हमेशा इन सभी प्रीप्रोसेसर को एक समझदार और सुसंगत तरीके से परिभाषित नहीं करते हैं। कुछ मामलों में, यह जानबूझकर है क्योंकि वास्तविकता अजीब है, अन्य मामलों में यह सड़ा हुआ और गलत कोड है जिसे होना चाहिए साफ किया।)
इनमें से प्रत्येक लक्ष्य सिद्धांत रूप में 32-बिट और 64-बिट संस्करण के रूप में मौजूद है। एक 64-बिट विंडोज ऑपरेटिंग सिस्टम इंस्टॉलेशन, जो सामान्य आधुनिक इंस्टॉलेशन है, 32-बिट और 64-बिट दोनों सॉफ्टवेयर चला सकता है, इसलिए आप इस तरह के सिस्टम पर दोनों वेरिएंट को इंस्टॉल और चला सकते हैं। एक उत्पादन स्थापना को शायद 64-बिट बिल्ड का उपयोग करना चाहिए, और इसलिए आप 32-बिट वातावरण से परेशान नहीं होना चुन सकते हैं। वास्तव में, सिग्विन का 32-बिट संस्करण काफी मृत प्रतीत होता है, और हो सकता है कि आप इसे बिल्कुल भी काम करने में सक्षम न हों। हालाँकि, एक समस्या यह है कि 64-बिट MinGW में कुछ अस्पष्ट बग हैं, इसलिए MinGW का उपयोग करते समय विशेष रूप से 32-बिट वातावरण का उपयोग करना कभी-कभी बेहतर होता है, जब तक कि आप ऑपरेटिंग सिस्टम या टूलचैन बग से लड़ना नहीं चाहते। हालांकि, 32-बिट कंप्यूटिंग स्पष्ट रूप से अधिकतर सामान्य रूप से समाप्त हो रही है, इसलिए यह भविष्य-सबूत विकल्प नहीं है।
अब सवाल शायद यह है कि इनमें से कौन सा वातावरण "सर्वश्रेष्ठ" है। जहां तक विकास की बात है, यह वास्तव में मायने नहीं रखता क्योंकि सभी कोड को उन सभी पर काम करने की जरूरत है। जैसा कि मैंने ऊपर उल्लेख किया है, MSVC बिल्ड का उपयोग विंडोज़ के अधिकांश उत्पादन परिनियोजन के लिए किया जाता है। यदि आप यूनिक्स जैसे वातावरण के अभ्यस्त हैं, तो MinGW (या बल्कि MSYS2) वातावरण विकसित करने के लिए अच्छा है, लेकिन विशेष रूप से 64-बिट MinGW वातावरण कुछ हद तक छोटा लगता है, इसलिए उत्पादन के लिए इसकी अनुशंसा करना मुश्किल है। कुछ लोगों द्वारा इस बिंदु पर सिगविन को एक ऐतिहासिक जिज्ञासा माना जा सकता है। साइगविन के तहत उत्पादन सर्वर चलाने की अनुशंसा नहीं की जाती है क्योंकि प्रदर्शन काफी खराब है। लेकिन कुछ स्थितियों में सिगविन वास्तव में उपयोगी है। उदाहरण के लिए, रीडलाइन किसी भी मूल विंडोज बिल्ड पर काम नहीं करता है, लेकिन यह सिगविन पर काम करता है, इसलिए यदि आप एक psql उपयोगकर्ता हैं, तो उसके लिए सिगविन बिल्ड का उपयोग करना बेहतर है। इसके अलावा, सिगविन उस स्थिति में उपयोगी है जो इस ब्लॉग पोस्ट के विपरीत है:आप एक विंडोज़-ज्यादातर डेवलपर हैं और यह सुनिश्चित करना चाहते हैं कि आपका कोड यूनिक्स के साथ अधिकतर संगत है। इसलिए इन तीनों परिवेशों का अपना महत्व है और इस समय बनाए रखने योग्य हैं।
इस श्रृंखला के अगले भाग में, अगर यह आपका प्राथमिक विकास परिवेश नहीं है, तो मैं विंडोज़ पर और उसके लिए कोड परिवर्तनों का परीक्षण करने के लिए कुछ तकनीकों पर चर्चा करूँगा।
