2009-07-09 17 views
10

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

हाल ही में निर्णय तृतीय पक्ष प्लगइन को त्यागना था।

अब मेरी बड़ी चिंता एक निर्माण प्रणाली है। मैं क्रॉस प्लेटफार्म निर्माण उपकरण के लिए चारों ओर देख रहा था। इस तरह मुझे बिल्ड फाइलों के दो सेट को बनाए रखने की आवश्यकता नहीं है (उदाहरण के लिए vcproj/विंडोज के लिए समाधान और लिनक्स के लिए फाइलें बनाना)।

मुझे निम्नलिखित उम्मीदवार मिले: ए। स्कैन बी। सेमीकेक

क्रॉस-प्लैटफ्रॉम विकास के लिए टूल के बारे में आप क्या सोचते हैं?

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

धन्यवाद दीमा

पी एस 1: कुछ है कि मैं SCons बारे में पसंद है कि यह (क) अजगर का उपयोग करता है और इसलिए यह लचीला है, जबकि cmake औचित्य भाषा (मैं समझता हूँ कि यह एक विजेता सुविधा के लिए एक के लिए नहीं है का उपयोग करता है बिल्ड-सिस्टम) (बी) स्वयं निहित (लिनक्स पर मेकफ़ाइल जेनरेट करने की आवश्यकता नहीं है)।

तो स्कॉन क्यों नहीं? क्यों आपकी परियोजनाओं में निर्णय cmake का उपयोग करना था?

+0

आउट सिस्टम अधिकतम दो प्लेटफार्मों के लिए है, तो सवाल यह है कि अगर सेमेक "हत्या पर" नहीं है? एक और बिंदु मुझे चिंता है कि निर्माण पुन: उत्पन्न होना चाहिए (स्क्रैच से दो बार निर्माण करना * समान * उत्पादों को बिल्कुल देगा)। निस्संदेह देशी निर्माण प्रणाली का उपयोग करके मैं लक्ष्य के करीब हूं। क्या यह संभव है कि सेमेक इसे तोड़ देगा और इसे संकलित करने वाले व्यक्ति की सेटिंग के आधार पर vcproj/makefiles को अलग करेगा (उदाहरण के लिए विंडोज़ प्रत्येक डेवलपर अपनी निजी मशीन पर संकलन करता है)? – dimba

+0

केवल विजुअल असिस्ट के बारे में एक नोट के लिए। खाली समाधान का उपयोग करते समय इसमें निर्देशिका से फाइल लोड करने का विकल्प होता है। –

उत्तर

10

सीएमके आपको अभी भी विजुअल स्टूडियो समाधान और प्रोजेक्ट फ़ाइलों का उपयोग करने की अनुमति देगा। सीमेक स्रोत कोड का निर्माण नहीं करता है, बल्कि यह आपके लिए बिल्ड-बिल्ड जेनरेट करता है। लिनक्स के लिए यह कोड :: ब्लॉक, केडेवेल या सादे मेकफ़ाइल या फिर भी अन्य गूढ़ विकल्प हो सकते हैं। विंडोज के लिए यह मैकोज़ के लिए विजुअल स्टूडियो प्रोजेक्ट फाइलें और अभी भी दूसरों के बीच हो सकता है। तो विजुअल स्टूडियो समाधान और परियोजनाएं आपके CMakeLists.txt से बनाई गई हैं। यह बड़ी परियोजनाओं के लिए ठीक काम करता है। जैसे वर्तमान Ogre3d सभी प्लेटफ़ॉर्म (विंडोज, लिनक्स, मैकोज़ और आईफोन) के लिए सीएमके का उपयोग करता है और यह वास्तव में अच्छी तरह से काम करता है।

मुझे इस संबंध में स्कोन के बारे में बहुत कुछ पता नहीं है, हालांकि, मैं केवल एक पुस्तकालय बनाने और लिनक्स में ही उपयोग करता था। तो मैं इन दोनों को उचित जमीन पर तुलना नहीं कर सकता। लेकिन हमारे बहु-मंच परियोजनाओं के लिए सीएमके काफी मजबूत है।

+0

सीएमके बहुत अच्छा है - यह * वीएस प्रोजेक्ट फाइलों को पुन: उत्पन्न करेगा, इसलिए यह आंशिक रूप से कहने के लिए भ्रामक है "आपको अभी भी ... प्रोजेक्ट फाइलों का उपयोग करने की अनुमति देता है"। मैं इसे सी ++ प्रोजेक्ट के लिए अत्यधिक अनुशंसा करता हूं, एकमात्र समाधान के रूप में यदि किसी को कई ओएस के बीच संगतता की आवश्यकता होती है जिसमें विंडोज़ शामिल हैं (विंडोज केवल एकमात्र "मुश्किल" है ...), और जहां आप विजुअल स्टूडियो का उपयोग करना चाहते हैं। – Arafangion

+0

मुझे आशा है कि मेरा बाकी जवाब इसे साफ़ कर देगा। :) आप बिल्कुल सही हैं। आपके पास अभी मौजूद समाधान फ़ाइलों को जेनरेट किए गए लोगों द्वारा प्रतिस्थापित किया गया है। सीएमके आपके समाधान में कुछ परियोजनाएं जोड़ देगा (ALL_PROJECTS, इंस्टाल, ZERO_CHECK) ये पहले अजीब लग सकते हैं लेकिन जब आप दुबला हो जाते हैं तो वे बहुत आसान होते हैं। विशेष रूप से स्थापित करें। यह समाधान के सभी हिस्सों का निर्माण करेगा और सीएलकेफ़ाइल.txt में निर्दिष्ट डीएलएल, EXEs और अन्य फ़ाइलों को कॉपी करेगा जो कि उनके लक्षित डीआईआर में निर्दिष्ट है ताकि आप इंस्टॉलेशन पैकेज बनाने के लिए केवल एनएसआईएस या अन्य पैकेज टूल चला सकें। – haffax

+0

यह ध्यान देने योग्य है कि स्कैन * वीएस प्रोजेक्ट फाइलें उत्पन्न कर सकता है। –

3

मैंने पहले स्कॉन्स का उपयोग नहीं किया है, इसलिए यह नहीं कह सकता कि यह कैसे काम करता है, लेकिन सीएमके बहुत अच्छी तरह से काम करता है।

यह आपके द्वारा लक्षित प्लेटफ़ॉर्म के लिए आवश्यक बिल्ड फ़ाइलों का निर्माण करके काम करता है।

जब वीसी ++ को लक्षित करने के लिए उपयोग किया जाता है, तो यह वीएस से समाधान और प्रोजेक्ट फाइलें उत्पन्न करता है, ऐसा प्रतीत होता है जैसे वे देशी वीएस परियोजनाएं थीं। एकमात्र अंतर यह है कि, यदि आप वीएस के माध्यम से सीधे परियोजना या समाधान को संपादित करते हैं, तो अगली बार जब आप सीएमके चलाते हैं तो परिवर्तन मिटा दिए जाएंगे, क्योंकि यह आपकी परियोजना/समाधान फ़ाइलों को ओवरराइट करता है।

तो इसके बजाय सीएमके फाइलों में कोई भी बदलाव किया जाना है।

0

अतीत में ऐसा करना बहुत था। हमने जो कुछ किया वह कई बार विंडोज़ सहित लगभग सब कुछ के लिए gnu बनाने का उपयोग करता है।

यदि आप पसंद करते हैं और लिनक्स के लिए gnu बनाने का उपयोग करते हैं तो आप विंडोज़ के तहत प्रोजेक्ट फ़ाइलों का उपयोग कर सकते हैं।

क्रॉस प्लेटफ़ॉर्म मेकफ़ाइल लिखने का वास्तव में एक अच्छा तरीका नहीं है क्योंकि लक्ष्य फ़ाइल अन्य चीजों (और पथनाम समस्याएं, \ बनाम/आदि) के बीच अलग होगी। आम तौर पर, आप सूक्ष्म मतभेदों को ध्यान में रखने के लिए विभिन्न प्लेटफॉर्म पर कोड को ट्वीव कर देंगे, इसलिए किसी फ़ाइल को ट्विक करने और अन्य प्लेटफ़ॉर्म पर जांच करने के लिए होना होगा।

कई ओएस परियोजनाओं जहां वे Makefile.win की तरह नाम हैं इस तरह के zlib के रूप में विभिन्न प्लेटफार्मों, Makefile.linux आदि आप अपने नेतृत्व का पालन कर सकता है के लिए Makefiles बनाए रखें।

+0

आपके दृष्टिकोण के साथ सीएमके जैसे कुछ का उपयोग करने पर क्या फायदा है? सीएमके के साथ आपको केवल बिल्ड फाइलों का एक सेट प्रबंधित करना होगा और फिर भी पूर्ण लाभ के लिए अपने पसंदीदा आईडीई का उपयोग कर सकते हैं। – haffax

+0

एक फायदा यह है कि एक एकल क्रॉस प्लेटफार्म स्क्रिप्ट को समझने के बजाय प्रत्येक सिस्टम के लिए मानक स्क्रिप्ट का उपयोग करना आसान हो सकता है जो किसी भी तरह से सभी ओएस के लिए किसी भी तरह के quirks के आसपास काम करता है। अभी भी बहुत सारे नकल प्रयास, हालांकि ... – Arafangion

2

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

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

दोनों प्लेटफार्मों पर संकलन पार करने के लिए समय निकालने के बजाय हम प्रत्येक प्लेटफ़ॉर्म के लिए सर्वोत्तम प्रणाली का उपयोग करते हैं और विशिष्ट मुद्दों को ठीक करने और सॉफ़्टवेयर को बेहतर बनाने में समय व्यतीत करते हैं।

हम केवल Windows एटीएम पर जीयूआई क्षुधा की है। तो संकलन पार करने के लिए कोई जीयूआई नहीं है। विंडोज और लिनक्स के बीच साझा किए गए हमारे अधिकांश विकास सर्वर साइड नेटवर्किंग (सॉकेट, टीसीपी/आईपी, यूडीपी ...) और फिर विंडोज़ पर लिनक्स और जीयूआई ऐप्स पर क्लाइंट साइड टूल्स हैं।

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

पुन सिंक प्रश्न:

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

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

यह लगातार तरीके से परियोजनाओं को स्थापित करने में मदद करता है।

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

+0

अगर आप कहते हैं कि आप कैसे सुनिश्चित करते हैं कि विभिन्न बिल्ड स्क्रिप्ट सिंक से बाहर नहीं जाते हैं तो मैं वोट दूंगा। (एक निरंतर एकीकरण सर्वर एक तरीका होगा) – Arafangion

+0

अब अपवॉट्स के लायक है! – Arafangion

1

यहां केडीएस डेवलपर्स द्वारा किए गए निर्णय के बारे में स्कैन पर सीएमके चुनने के लिए article है। हालांकि मुझे यह इंगित करना है कि यह लेख लगभग तीन साल पुराना है, इसलिए स्कॉन्स में सुधार होना चाहिए था।

Here अन्य भवन औजारों के साथ स्कैन की तुलना है।

+0

यह भी ध्यान दें कि स्कैन अधिक सामान्य है, जबकि सीएमके विशेष भाषाओं की ओर पक्षपातपूर्ण है। – Arafangion

3

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

देखें Premake 4.0 Homepage

CruiseControl निरंतर एकीकरण के लिए एक अच्छा विकल्प है। हम सफलतापूर्वक मोनो का उपयोग कर लिनक्स पर चल रहे हैं।

+1

मैं सीएमके और स्कॉन्स की तुलना में लोकप्रियता/समुदाय/समर्थन की कमी के कारण प्रीमेक की सिफारिश नहीं करता हूं जिसका उपयोग कई प्रमुख परियोजनाओं में किया जाता है। –

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