2009-08-04 17 views
11

पर एक साथ सी ++ विकास हमारे पास एक गैर-वाणिज्यिक (पढ़ने: बस मज़ेदार) पर काम कर रहे कुछ हद तक डेवलपर्स हैं क्रॉस-प्लेटफ़ॉर्म सी ++ प्रोजेक्ट। हम पहले से ही सभी क्रॉस-प्लेटफार्म पुस्तकालयों की पहचान कर चुके हैं जिन्हें हमें आवश्यकता होगी। हालांकि, हमारे कुछ डेवलपर्स माइक्रोसॉफ्ट विजुअल सी ++ 2008 का उपयोग करना पसंद करते हैं, अन्य जीएनयू/लिनक्स पर एमएक्स में कोड करना पसंद करते हैं। हम सोच रहे हैं कि क्या हम सभी कोड एक ही कोड भंडार से, दोनों वातावरणों के साथ-साथ कम या कम काम करना संभव है। आखिरकार हम चाहते हैं कि परियोजना शुरुआत से दोनों प्लेटफार्मों पर साफ-सुथरा हो।लिनक्स और विंडोज

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

साझा करने के लिए कोई सुझाव या अनुभव?

उत्तर

14

अपनी बिल्ड फ़ाइलों को प्रबंधित करने के लिए CMake का उपयोग करें।

यह आपको टेक्स्ट रिपॉर्ड्स के एक सेट के साथ एक एकल संग्रह सेट करने देगा। प्रत्येक देव अपने सिस्टम के लिए सही निर्माण वातावरण बनाने के लिए उचित सेमेक स्क्रिप्ट चला सकता है (विजुअल स्टूडियो 2008/2005/जीएनयू सी ++ बिल्ड स्क्रिप्ट/आदि)।

वहाँ कई फायदे यहां हैं:

  • प्रत्येक देव अपने स्वयं के निर्माण पर्यावरण का उपयोग कर सकते
  • निर्भरता बहुत सफाई से संभाला जा सकता है मंच विशिष्ट deps भी शामिल है।
  • बिल्ड स्रोत से बाहर हो सकते हैं, जो अनुचित फ़ाइलों को गलती से रोकने में मदद करता है
  • नए देव के लिए आसान माइग्रेशन। वातावरण (यानी: जब वीएस 2010 जारी किया जाता है, तो कुछ देव सिर्फ अपने निर्माण फ़ोल्डर को पुनर्निर्माण करके वहां माइग्रेट कर सकते हैं)
+0

मैं यह सुझाव पसंद, makefile वाक्य रचना के लिए मेरी कभी तिरस्कार के बावजूद। मैं इसे एक कदम आगे ले जाऊंगा (शायद यह पहले से ही निहित है) और सुझाव देता है कि आप सीआईआई को आपके द्वारा लक्षित प्रत्येक प्लेटफॉर्म के लिए तैयार करते हैं। यह आपको जल्दी से बिल्ड-ब्रेकिंग परिवर्तनों की पहचान करने की अनुमति देता है। वहाँ कई सीआई सर्वर हैं - मैंने इस उद्देश्य के लिए कई बार सफलता के साथ हडसन का उपयोग किया है। –

+0

यदि आप सीएमके का उपयोग कर रहे हैं, तो इसे सीडीएश के साथ एकीकृत करना बहुत आसान है - जो आपको सीआई या रात में कई वितरित प्लेटफ़ॉर्म पर बनाता है, और एक अच्छा साफ वेब इंटरफ़ेस देता है: http://cdash.org/ –

+0

@ माइक: इसके अलावा - सीमेक का सिंटैक्स मेकफ़ाइल सिंटैक्स, आईएमओ से क्लीनर है - और मेकफ़ाइल को छूने की किसी भी ज़रूरत को पूरी तरह खत्म कर देता है - यदि आप जेनरेटर चुनते हैं तो यह उन्हें आपके लिए उत्पन्न करेगा (हालांकि मैं आमतौर पर जेनरेटर लक्ष्यीकरण आईडीई का उपयोग करता हूं) –

2

समस्या वास्तव में सी ++ स्रोत फ़ाइलों को संपादित नहीं कर रही है, लेकिन बिल्ड प्रक्रिया स्वयं ही है। वीएस समान मेकफ़ाइल आर्किटेक्चर का उपयोग नहीं करता है क्योंकि लिनक्स विकास आमतौर पर करता है। एक कट्टरपंथी सुझाव, लेकिन दोनों समूह वास्तव में एक ही सी ++ आईडीई और निर्माण प्रक्रिया का उपयोग कर सकते हैं - अधिक जानकारी के लिए Code::Blocks देखें।

+0

लेकिन यह कर सकता है: मेकफ़ाइल प्रोजेक्ट बनाएं, और यह किसी भी कमांड लाइन को चलाएगा जिसे आप चाहते हैं (न केवल एनएमके, हालांकि यह डिफ़ॉल्ट है)। –

+1

मुझे नहीं लगता कि लोग इतनी आसानी से इसमें शामिल होंगे, क्योंकि कुछ लोगों के लिए संपादक की पसंद का महत्व समान है, उदाहरण के लिए, धर्म की पसंद। इस मुद्दे ने इंटर्ननेट पर आभासी युद्धों को जन्म दिया है, इसलिए कृपया ध्यान दें कि आप क्या सुझाव देते हैं! हम Emacs के चर्च के खिलाफ वी मार्च के पंथ नहीं चाहते हैं! (हालांकि हम जानते हैं कि कल्चर आसानी से चर्च को पराजित करेगा) पीएस: कृपया इसे बहुत गंभीर न लें, केवल ध्यान रखें कि अधिकांश डेवलपर्स अपने प्यारे संपादकों को इतना आसान नहीं छोड़ेंगे :) – tr9sh

+0

अच्छा, सुझाव वह गंभीर नहीं था - मुझे पता है कि उपयोगकर्ता कितने emacs हैं :-) –

2

यह संभव है (मैं अपने दैनिक पैसे कमाने के लिए करता हूं :-))।

लेकिन आपको ओएस आपूर्ति पुस्तकालयों में मतभेदों को ध्यान में रखना होगा जो बहुत परेशान हो सकते हैं। बूस्ट और क्यूटी के आसपास होने के लिए दो अच्छे विकल्प हैं।

दोनों आपको उपयोगी सामग्री के प्लेटफ़ॉर्म स्वतंत्र कार्यों के साथ आपूर्ति करते हैं जो सी lib और STL द्वारा प्रबंधित नहीं हैं।

3

मैं व्यक्तिगत रूप से मेरी सभी सी ++ आवश्यकताओं के लिए cmake/mingw32/Qt4 का उपयोग करता हूं। क्यूटीक्रिएटर एक क्रॉसप्लेटफार्म आईडीई है जिसे क्यूटी 4 प्रोग्रामिंग के लिए कुछ हद तक अनुकूलित किया गया है।

10

मैंने इसे किया है और बिना किसी समस्या के इसे देखा है।

आप विभिन्न प्लेटफ़ॉर्म के लिए अलग कोड को अलग करना चाहते हैं। इसके अलावा, आप अपने निर्देशिका संरचना के बारे में सोचना चाहेंगे।जैसे

  • परियोजना/src < कुछ - .cc और ज फ़ाइलें
  • परियोजना/src/लिनक्स | जीतने < - कोड है कि एक मंच या अन्य
  • परियोजना/लिनक्स < के लिए विशिष्ट है - बनाने के फ़ाइलें और अन्य परियोजना से संबंधित सामान
  • परियोजना/जीत < - .sln और .csproj फ़ाइलों

मूल रूप से आप सिर्फ क्या specifi है वास्तव में स्पष्ट होना चाहता हूँ प्रत्येक प्रणाली के लिए सी और आम क्या है।

इसके अलावा, इकाई परीक्षण के बाद से वहाँ मामूली अंतर हो सकता है वास्तव में महत्वपूर्ण होने जा रहे हैं और आप की उम्मीद के रूप में यह आसान बनाने के लिए खिड़कियों लोग कुछ परीक्षण यकीन है कि linux कोड काम करता है बनाने के लिए चलाने के लिए चाहते हैं और दूसरी तरह के चारों ओर।

+2

+1 यूनिट परीक्षणों पर जोर देने के लिए। –

+0

यूनिट परीक्षणों के लिए भी +1। ध्यान दें कि इसका मतलब यह है कि आपको यह सुनिश्चित करने की ज़रूरत है कि आपका यूनिट टेस्ट फ्रेमवर्क भी क्रॉस-प्लेटफॉर्म है - उदाहरण के लिए, वीएस2012 में बनाया गया नया सी ++ यूनिट परीक्षण फ्रेमवर्क से बचें। – JBentley

2

मैं दो तरीकों से किया है:

  1. प्रत्येक मंच अपने स्वयं के निर्माण प्रणाली है। जब भी कोई कुछ बदलता है (एक स्रोत फ़ाइल जोड़ता है), तो वे या तो अन्य प्लेटफ़ॉर्म को भी अनुकूलित करते हैं, या वे एक अधिसूचना मेल करते हैं और दूसरे प्लेटफार्म से परिचित किसी और के अनुसार इसे अनुकूलित करता है।
  2. CMake का उपयोग करें।

मैं नहीं कह सकता कि मुझे वास्तव में सीएमके पसंद आया, लेकिन एक क्रॉस-प्लेटफ़ॉर्म टूल में निश्चित रूप से इसके फायदे हैं।

आम तौर पर, पहले कुछ पंक्तियों से अपने कोड को संकलित करने के लिए विभिन्न कंपाइलरों का उपयोग करना हमेशा एक अच्छा विचार है, क्योंकि यह कोड की गुणवत्ता में सुधार करने में मदद करता है।

4

मेरे पास एक्रोनिस में ऐसा अनुभव था। हमारे पास वही कोडबेस था जो कि Win32/64, लिनक्स, और ओएस एक्स (और अन्य विदेशी प्लेटफ़ॉर्म, जैसे कि ईएफआई) को लक्षित करने वाले बाइनरी (पूरी तरह से पैक किए गए इंस्टॉलर, वास्तव में) बनाने के लिए उपयोग किया जाता था, जिसमें हर कोई अपनी पसंद के आईडीई में काम करता था। यह चाल यहां कंपाइलर- और आईडीई-विशिष्ट समाधान से बचने के लिए है, और अपनी परियोजना को स्वच्छ क्रॉस-प्लेटफार्म बनाने वाली फाइलों से पूरी तरह से निर्मित करने योग्य बनाती है। ध्यान दें कि आप किसी भी मेक सिस्टम को वीसी ++ के साथ पूरी तरह से अच्छी तरह से उपयोग कर सकते हैं, इसलिए यह कोई समस्या नहीं है (हमने ऐतिहासिक कारणों से वाटकॉम का उपयोग किया है, लेकिन मैं इसकी अनुशंसा नहीं करता)।

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

यह सुनिश्चित करना कि कोड हर किसी के लिए संकलित है, यह समस्या हो सकती है, अधिकतर क्योंकि वीसी ++ आम तौर पर जी ++ से नियमों को लागू करने में अधिक लक्स होता है (उदाहरण के लिए, यह आपको एक गैर-कॉन्स्ट संदर्भ के लिए एक रावल्यू बांधने देगा, यद्यपि चेतावनी)। यदि आप त्रुटियों के रूप में उपचार चेतावनियों के साथ संकलित करते हैं, और उच्चतम चेतावनी स्तर (शायद कुछ हाथ से उठाए गए चेतावनियों को अक्षम कर दिया गया है), तो आप अधिकतर इससे बचेंगे। संगत रोलिंग बिल्ड सेट होने के बाद उनको पकड़ने का एक और तरीका है। एक्रोनिस में हमने एक अन्य दृष्टिकोण का उपयोग किया है, जिसमें विंडोज बिल्ड पर्यावरण में साइगविन-आधारित क्रॉस-संकलन उपकरण हैं, इसलिए कोई भी विंडोज देव अपने बॉक्स से बिल्डिंग लक्ष्यीकरण लिनक्स (उसी जी ++ संस्करण और सभी के साथ) बना सकता है, और देखें कि क्या यह विफल रहता है, यह सत्यापित करने के लिए कि उसके परिवर्तन g ++ में संकलित होंगे।

4

जैसा कि पिछले पदों में उल्लिखित है, क्यूटी वास्तविक एक साथ बहु-मंच विकास करने के लिए एक बहुत ही आसान तरीका है - आपके आईडीई से स्वतंत्र और कई अलग-अलग कंपाइलरों (यहां तक ​​कि सिम्बियन, एआरएम, विंडोज सीई/मोबाइल ...) के लिए भी।

मेरी आखिरी और वर्तमान कंपनी में मैं मिश्रित लिनक्स- और विंडोज-डेवलपर टीमों में काम करता हूं, जो सबवर्सन और क्यूटी का उपयोग करके मिलकर काम करते हैं (जिसमें एक बहुत ही आसान और शक्तिशाली बिल्ड-सिस्टम "क्यूमेक" है, जो सभी अलग-अलग प्लेटफार्मों को छुपाता है/कंपाइलर विशिष्ट निर्माण वातावरण - आपको बस एकसभी प्लेटफ़ॉर्म के लिए फ़ाइल बनाने के लिए लिखना है - इतना आसान!)।

और: क्यूटी आप की जरूरत लगभग सब कुछ शामिल हैं: आसान अनुवाद समर्थन और आसान स्ट्रिंग रूपांतरण के साथ

  • सरल स्ट्रिंग हैंडलिंग, (UTF8, UTF16, एएससीआई ...)
  • फ़ाइल के लिए सरल वर्गों मैं/ओ, चित्र, नेटवर्किंग आदि
  • आरामदायक जीयूआई कक्षाएं
  • जीयूआई लेआउट/डिजाइन के लिए चित्रमय डिजाइनर
  • चित्रमय अनुवाद अपने एप्लिकेशन के लिए गतिशील अनुवाद बनाने के लिए (आप चला सकते हैं उपकरण विभिन्न चयन भाषाओं के साथ एक द्विआधारी - यहां तक ​​कि सिरिलिक, एशियाई फोंट ...)
  • एकीकृत परीक्षण ढांचे (इकाई परीक्षण)

तो क्यूटी एक पूर्ण विशेषताओं और बहुत विश्वसनीय वातावरण है - मैं 10 साल के लिए इसका इस्तेमाल करते हैं।

और: क्यूटी वीसी ++, ग्रहण जैसे आईडीई में सहजता से एकीकृत करता है या अपना स्वयं का आईडीई "क्यूटी क्रिएटर" प्रदान करता है।

देखें: http://www.trolltech.com + http://doc.trolltech.com

शुभकामनाओं सहित, क्रिस

2

cmake के लिए एक और वोट।
देखने के लिए एक चीज, फ़ाइल नामों को बंद कर दिया गया है लेकिन विंडोज़ पर केस संवेदनशील नहीं है। वे ज्यादातर यूनिक्स फाइल सिस्टम पर संवेदनशील हैं।

यह आमतौर पर #include

उदाहरण के साथ एक समस्या है। एक फ़ाइल दी गई FooBar.h

#include "foobar.h" // works on Windows, fails on Linux. 
1

मैं यहां हर किसी के साथ सहमत हूं जिसने सी ++ में क्रॉस प्लेटफार्म विकास के लिए सेमेक का सुझाव दिया है। यह एक उत्कृष्ट उपकरण है।

एक और चीज जो मैं सुझाव दूंगा वह ग्रहण सीडीटी को विकास पर्यावरण के रूप में उपयोग करना है। यह किसी भी स्थान पर काम करता है जहां आप जावा को एक जीसीसी चला सकते हैं और यह आपके विकास पर्यावरण को एकीकृत करता है।

मुझे लगता है कि एलन जैक्सन ने यूनिट परीक्षण पर जोर दिया था। ऐसा करने के लिए आपको कुछ क्रॉस प्लेटफ़ॉर्म यूनिट परीक्षण पुस्तकालयों की आवश्यकता होगी। मैंने सी ++ इकाई परीक्षण ढांचे के बारे में समय पहले इस post को पढ़ा था। यह थोड़ा पुराना लेकिन विचारशील है। एक लापता जो कि दोनों प्लेटफार्मों में भी काम करता है googletest है।

अंत में यदि आप दोनों प्लेटफार्मों में स्वचालित रूप से उन परीक्षणों को चलाने के लिए चाहते हैं तो सेमेक में एक और टूल है जिसे सीटीएस्ट कहा जाता है जो ऐसा करने के लिए बहुत अच्छा है।

3

हम एक क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट पर भी काम कर रहे हैं। हम कोड करने के लिए Emacs का उपयोग कर रहे हैं, निर्माण करने के लिए स्कैन और विजुअल स्टूडियो 2008 डीबग करने के लिए। यह मेरी पहली बार Emacs + SCons का उपयोग कर रहा है और मुझे यह कहना होगा कि स्कैनस्ट्रक्चर और स्कॉन्स्क्रिप्ट्स कैसे काम करता है यह पता लगाने के बाद यह बहुत निफ्टी है।

3

मुझे इस प्रश्न का देर हो चुकी है, और यहां बहुत अच्छे उत्तर दिए गए हैं, लेकिन मैंने किसी भी व्यक्ति को मेरे द्वारा चलाए गए सभी मुद्दों का आकलन नहीं देखा है (सी ++ में मेरा अधिकांश काम है और पार हो गया है -प्लाफार्म), इसलिए:

  • क्रॉस-प्लेटफ़ॉर्म संकलन। हर किसी ने इसे काफी अच्छी तरह से कवर किया है। CMake, और SCons दूसरों के बीच उपयोगी हैं।
  • प्लेटफ़ॉर्म अंतर। ये वास्तव में लिनक्स बनाम विंडोज तक सीमित नहीं हैं। विंडोज के विभिन्न संस्करणों में सूक्ष्म मुद्दों के बहुत सारे हैं। यदि आप कभी भी लिनक्स से ओएस एक्स तक कूदना चाहते हैं तो आपको वही मिल जाएगा। तो प्रोसेसर आर्किटेक्चर मतभेद करें: 32 वी 64 बिट आमतौर पर कोई फर्क नहीं पड़ता - जब तक यह नहीं करता है और चीजें आप पर बहुत बुरी तरह टूट जाती हैं। यह कुछ अन्य भाषाओं में सी ++ प्रोग्रामर का सामना करना पड़ता है, जिनके कार्यान्वयन प्रोग्रामर से इस तरह की चीज को छिपाने के लिए कड़ी मेहनत कर रहे हैं।
  • सबकुछ परीक्षण करें। एलन mentions unit tests लेकिन मुझे उन पर जोर देने दो। क्रॉस-प्लेटफ़ॉर्म प्रोग्रामिंग के साथ वास्तविक समस्या कोड नहीं है जो संकलित नहीं करेगा: यह कोड है जो ठीक से संकलित करता है और सूक्ष्म मामलों में गलत चीज करता है। जब आप एक मंच पर काम कर रहे हों तो यूनिट परीक्षण उनसे कहीं अधिक महत्वपूर्ण हैं।
  • जब भी संभव हो पोर्टेबल पुस्तकालयों का उपयोग करें। यह अधिकार प्राप्त करना सूक्ष्म गठिया से भरा है। अपने आप को रोल करने के बजाय किसी और के काम का लाभ उठाना बेहतर है। Qt यहां उपयोगी है, जैसे कि NSPR और APR (बाद वाले दो सी हैं, लेकिन यदि आप सीधे उनके साथ गड़बड़ नहीं करना चाहते हैं तो रैपर मौजूद हैं।) ये पुस्तकालय हैं जो एक लक्ष्य के रूप में प्लेटफार्म अबास्ट्रक्शन को स्पष्ट रूप से लक्षित करते हैं, लेकिन अधिकांश अन्य पुस्तकालय आप इसके लिए जांच की जानी चाहिए। शांत पुस्तकालयों से उचित रूप से सावधान रहें जिनके पास पोर्टेबिलिटी का ट्रैक रिकॉर्ड नहीं है। मैं यह नहीं कह रहा हूं कि उनका उपयोग न करें: बस पहले परीक्षण करें। इस अधिकार को करने से आपको परीक्षण पर भारी प्रयास बचाता है।
  • पावेल mentions continual integration। इससे कोई फर्क नहीं पड़ता कि आप केवल कुछ मुट्ठी भर हैं। लेकिन मुझे पता चला है कि जब आप ओएस, ओएस संस्करण, और प्रोसेसर मतभेदों पर विचार करते हैं तो प्लेटफार्मों की संख्या का मतलब है कि निरंतर बिल्ड-टेस्ट चक्र के कुछ रूपों के बिना आप हमेशा कुछ एज केस खो देंगे। यदि आपकी परियोजना कुछ हद तक लोगों से बड़ी हो जाती है तो ऐसा करने पर विचार करें।
  • संस्करण नियंत्रण। सबसे स्पष्ट मुद्दा न्यूलाइन और फ़ाइल नाम केस-संवेदनशीलता को संभालने वाला है लेकिन अन्य भी हैं। अधिकांश प्रसिद्ध ओपन सोर्स वीसीएसई अभी तक यह सही करते हैं, लेकिन यह उल्लेखनीय है कि आमतौर पर पोर्टेबिलिटी से संबंधित सभी बग खोजने के लिए उन्हें कई सालों लगते हैं। एक उदाहरण के रूप में Mercurial, जिसने अपने विक्रय बिंदुओं में से एक के रूप में पोर्टेबिलिटी रखी है, में असामान्य स्थितियों में विंडोज फ़ाइल नामों से निपटने में तीन या चार रिलीज फैले हुए फिक्स की एक श्रृंखला है। सुनिश्चित करें कि आप यह जांच सकते हैं कि दूसरे लोग क्या जांचते हैं।
  • लिपियों। अपनी स्क्रिप्टिंग के लिए पर्ल/पायथन/रूबी (या उनके जैसे कुछ) का उपयोग करें। सिंक में लिनक्स खोल और विंडोज बैच स्क्रिप्ट को रखने की कोशिश करना दर्दनाक रूप से कठिन है।

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

0

प्रीकेक देखें ... यह सीएमके के समान ही है लेकिन लुआ का उपयोग करके लिखा गया है।

मैंने इसे कई विकास परियोजनाओं पर उपयोग किया है और मौजूदा कंपनी और परियोजना संरचनाओं में सीखना और एकीकृत करना आसान लगता है।

इसे आज़माएं!

http://industriousone.com/premake

संबंधित मुद्दे