बड़े पैमाने पर लिनक्स / मेकफाइल परियोजनाओं से प्रभावी ढंग से कैसे निपटें?


16

मैं अब 10 वर्षों से C ++ में विंडोज एप्लिकेशन विकसित कर रहा हूं। और हाल ही में मैंने कुछ लिनक्स परियोजनाओं में खुदाई शुरू कर दी है, और मैं बर्दाश्त नहीं कर सकता कि मैं कितना अनुत्पादक हूं ...

मैं एक तेज शिक्षार्थी हूं, और मैं पिछले कुछ समय से लिनक्स को एक प्राथमिक मंच के रूप में उपयोग कर रहा हूं। और मैं शेल, ओएस सिद्धांतों और जीयूआई के साथ बहुत सहज महसूस करता हूं। लेकिन जब विकास की बात आती है, तो ऐसा लगता है कि मैं स्कूल वापस आ गया हूं।

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

फिर एक गो-टू-डेफिनिशन सामान है, जो कि कोई नहीं लगता है, सोर्सफोर्ज से कुछ बड़े प्रोजेक्ट में शामिल होने की कोशिश करें, और आप दिनों के लिए अटक जाते हैं, क्योंकि परिभाषाओं पर नेविगेट करना इतना कठिन है ... grep -r "this_def" . --include "*.cpp" --include "*.h"इतना धीमा और भद्दा लगता है।

और फिर, डिबगिंग, gdb काम करता है, लेकिन कोई फर्क नहीं पड़ता कि मैं क्या करता हूं, ऐसा लगता है कि यह WinDbg या VisualStudio डिबगर के पीछे प्रकाश वर्ष है।

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

क्या कोई इससे गुज़रा है? क्या ऐसा कुछ है जो मुझे याद आ रहा है जो मुझे अधिक उत्पादक बना सकता है?


8
+1, मैं विज़ुअल स्टूडियो डीबगर के संबंध में समान निष्कर्ष पर पहुंचा हूं; किसी भी प्लेटफ़ॉर्म पर कोई अन्य आईडीई अपनी निरीक्षण क्षमताओं के करीब नहीं आता है।
अप्पेक्ष

जवाबों:


22

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

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

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

आपको CScope और CTags जैसे टूल के बारे में भी जानना होगा । जितना आप विरोध कर सकते हैं, मैं VIM या EMACS सीखने का सुझाव दूंगा । वे टैग टूल के साथ अच्छी तरह से एकीकृत हैं जिनका मैंने अभी उल्लेख किया है। जब रोम में हो तो वैसा ही करो जैसा की रोमन करते हैं। आप VIM और EMACS के लिए एक्सटेंशन पा सकते हैं जो आपके लिए कोड पूरा करने का काम करेगा। कोड पूरा करने की पेशकश करने वाले औजारों के साथ मेरा अपना अनुभव यह है कि हां, यह कुछ टाइपिंग को बचाता है, लेकिन सामान्य टाइपिंग में आसान है। सोच क्या मुश्किल है। आपकी राय अलग हो सकती है, खासकर अगर आपको कार्पल टनल सिंड्रोम है।

बनाने के लिए के रूप में। मेक-अप भयानक है, लेकिन आप शायद इसे चूसना और इसे सीखना चाहते हैं।


6
+1, मेमोराइजिंग कमांड्स GUIs को याद रखने से ज्यादा कठिन नहीं है
जेवियर

5
निश्चित रूप से VIM या EMACS सीखें। लाइनक्स का वास्तव में विजुअल स्टूडियो जैसा कोई गुण नहीं है, इसका कारण यह है कि वीआईएम और ईएमएसीएस में सभी समान विशेषताएं हैं, और अधिक। मैं विम की मेरी नकल करने के लिए प्लग-इन है कि मुझे टैब, टुकड़े, परियोजना नेविगेशन के साथ स्वतः पूर्ण देने के लिए, टर्मिनल, टैग, टैग नेविगेशन, खाली स्थान के रूपांतरण में बनाया का एक सेट है, और पूरी बात पीठ का उपयोग करने के लिए स्थापित मिल गया है GitHub । हालांकि, मैं विंडोज़ का उपयोग करता हूं, इसलिए यह वही है जो पथिक जानकारी vimrc फ़ाइल में उपयोग करता है।
स्पेंसर रथबुन

2
@ जेवियर पिछली बार जब मैंने जाँच की, GUI ने सादे दृष्टि में बहुत अधिक कार्यक्षमता प्रदर्शित की, याद रखने की कोई आवश्यकता नहीं है। वीआईएम स्क्रीन किसी भी संकेत या अनुस्मारक से रहित है।
quant_dev

2
@tdammers मैंने उस समय बीएस को कॉल करने के लिए अपने समय में पर्याप्त लिनक्स कोड देखा है।
quant_dev

4
@ क्वेंट_देव, क्विक! डुप्लिकेट प्रतीकों को त्रुटि के रूप में मानने के लिए आप लिंकर विकल्प को कहां सेट करते हैं? ज़रूर, आप इसे परियोजना के सी / सी ++ गुणों के लिंकर अनुभाग में सभी वस्तुओं की खोज करके पा सकते हैं, लेकिन यह लिंकर के लिए मैन पेज में देखने की तुलना में सादे दृष्टि में अधिक (या कम) नहीं है।
चार्ल्स ई। ग्रांट

11

मैं अब 10 वर्षों से C ++ में विंडोज एप्लिकेशन विकसित कर रहा हूं। और हाल ही में मैंने कुछ लिनक्स परियोजनाओं में खुदाई शुरू कर दी है, और मैं बर्दाश्त नहीं कर सकता कि मैं कितना अनुत्पादक हूं ...

क्या ऐसा कुछ है जो मुझे याद आ रहा है जो मुझे अधिक उत्पादक बना सकता है?

विंडोज पर विकसित करें, लिनक्स पर तैनात करें।

इसमें आपकी (विंडोज) मशीन, और बिल्ड सर्वर (लिनक्स) दोनों पर चल रहे यूनिट टेस्ट शामिल हैं।

साइड इफेक्ट के रूप में, आप पोर्टेबल कोड लिखना सीखेंगे।

एक और सकारात्मक प्रभाव यह है कि अलग-अलग संकलक का उपयोग करने से अधिक चेतावनी उत्पन्न होगी और इस प्रकार अधिक कीड़े पकड़ेंगे।

अद्यतन : सभी लिनक्स fanboys इस जवाब को नीचा दिखाने के लिए: मैं यह नहीं कहता कि हर किसी को विंडोज पर विकसित करना चाहिए! लेकिन जिस प्लेटफ़ॉर्म का आप बहुत अच्छी तरह से जानते हैं, उसका उपयोग करके एक नया प्लेटफ़ॉर्म सीखने में बहुत समय बिताने की तुलना में अधिक उत्पादक है।


डाउनवॉटर कृपया बता सकता है कि उसने डाउनवोट क्यों किया?
सोजेरड

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

-1: यदि वह एक विकल्प था, तो ओपी उसकी मूल समस्या नहीं होगी। और विंडोज पर विकसित होने से आपको विंडोज डेवलपमेंट की सभी लागतें मिलती हैं (जैसे कि 18 वीं शताब्दी की सॉफ़्टवेयर इंस्टॉलेशन प्रक्रिया) और आपको अभी भी Makefile लिखना होगा और अपने आवेदन को gdb के साथ क्रॉस-डीबग करना होगा, अगर कुछ भी पूरी तरह से पोर्टेबल नहीं है।
Thiton

@tdammers स्रोतों की जाँच करना और * .cpp से एक प्रोजेक्ट बनाना कई मामलों में काम करता है। यहां तक ​​कि अगर सेटअप करने में कुछ घंटों का समय लगता है, तो यह पूरी तरह से अलग विकास के माहौल को सीखने में बहुत कम होगा।
जोएर्ड

1
दूसरी ओर, जिस प्लेटफ़ॉर्म पर आपको काम करना चाहिए उसके बारे में अधिक सीखना स्वाभाविक और सार्थक लगता है।
बेसिल स्टारीनेविच

4

आपकी समस्या को लिनक्स दुनिया में कई बार हल किया गया है, हालांकि, विंडोज / माइक्रोसॉफ्ट टूल्स के विपरीत, यह एक्स्ट्रा के साइड डिश के साथ चांदी की प्लेट पर नहीं दिया जाएगा। इसे पाने के लिए आपको कुछ काम करने की आवश्यकता हो सकती है।

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

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

लिनक्स में कई प्रकार के उपकरण हैं, जो लोग जानते हैं कि vi मुझे संपादन के सभी पहलुओं में अच्छी तरह से करते हैं, इसमें संदर्भ लुकअप आदि हैं, बस एक सीखने की अवस्था है। मुझे यकीन है कि Emacs यह सब भी कर सकते हैं, हालांकि इसका इस्तेमाल कभी नहीं किया है।


3
"लिनक्स दुनिया में आपकी समस्या कई बार हल हो गई है, हालांकि, विंडोज / माइक्रोसॉफ्ट टूल्स के विपरीत, यह चांदी की प्लेट पर एक्स्ट्रा डिश के साइड डिश के साथ नहीं दिया जाएगा।" तो यह पूरी तरह से हल नहीं किया गया है, तो।
मात्रा_देव १dev

4
@quant_dev। सही या गलत तरीके से, लिनक्स सॉफ्टवेयर के एक टुकड़े के लिए यह असामान्य है कि हर उपयोगकर्ता के लिए सभी चीजें होने की कोशिश करें। यह मॉडल के लिए अधिक सामान्य है जहां प्रत्येक टुकड़ा एक छोटी सी चीज को अच्छी तरह से करता है, और अंत उपयोगकर्ता अपनी समस्याओं को हल करने के लिए उसके द्वारा आवश्यक कोडांतरण करता है। विंडोज़ उपयोगकर्ता के लिए, समस्या को हल नहीं माना जाता है, लिनक्स उपयोगकर्ता के लिए, यह है, कौन सही है, जाहिर है कि आप सोचते हैं कि आप हैं, मुझे नहीं पता, और अधिकांश लिनक्स उपयोगकर्ता सोचते हैं कि वे हैं। यह थोड़ा कठोर है क्योंकि मुझे दुनिया को जिस तरह से असहमत होना चाहिए, वह सिर्फ मुझे दे रहा है।
मटनज़

3

क्या इसके लायक है, लिनक्स पर आप बेहतर सादे पुराने की तुलना में निर्माण किया है सिस्टम के लिए जीएनयू मेकअप (जो अक्सर भयानक के साथ चला जाता autoconf ), उदाहरण के लिए omake और कई अन्य ( cmake, scons...)।


3

कोड के लिए खोज करने के लिए grep का उपयोग करने में यह कितना कठिन है, इसके बारे में एक सुझाव: अपने .bashrc फ़ाइल में बैश उपनाम सेट करें। तो फिर इसका सिर्फ एक ही आदेश:

alias searchCode='find -iname \*.cpp | xargs grep $1'
alias searchCodeHeaders='find -iname \*.h | xargs grep $1'

कमांड लिखने के लिए शायद बेहतर तरीके हैं, लेकिन विचार समान है। खोज कोड चाहते हैं? सर्चकोड नामक एक उपनाम लिखें। याद रखें कि हालांकि वे थकाऊ और जटिल हैं, यूनिक्स उपकरण का उपयोग आपके जीवन को आसान बनाने के लिए भी किया जा सकता है।


3

मेरा 2 सी किसी ऐसे व्यक्ति के रूप में जिसने दोनों प्लेटफार्मों पर C ++ विकसित किया है और उन दोनों को पसंद करता है।

1) मेकफाइल्स दर्दनाक हैं - सबसे अच्छी सलाह जो मैं आपको दे सकता हूं वह है कि यदि संभव हो तो दूसरे बिल्ड सिस्टम पर स्विच करने का प्रयास करें।

2) कोड एडिटिंग और ब्राउजिंग के लिए, कुछ काफी उपयोगी उपकरण हैं। ज़रूर, वे एकीकृत नहीं हैं, लेकिन यह वास्तव में कोई फर्क नहीं पड़ता जब यह काम करने की बात आती है। vim + ctags + grep आपको वहीं मिलेगा। बेशक, वहाँ आईडीई के रूप में अच्छी तरह से कर रहे हैं, लेकिन स्पष्ट रूप से मुझे कुछ भी पसंद नहीं था जो मैंने कोशिश की थी: ग्रहण + सीडीटी, केडेवलप, कोड :: ब्लॉक। आप विभिन्न निष्कर्ष पर आ सकते हैं, हालाँकि।

3) डिबगिंग के लिए, बस कमांड-लाइन gdb से चिपके रहें। निश्चित रूप से, यह विंडबग के पीछे है जब यह सुविधाओं की बात आती है, लेकिन अधिकांश उद्देश्यों के लिए यह ठीक है। पिछली बार जब मैंने उन्हें आज़माया था, तो ग्राफिकल फ्रंट-एंड्स (ddd, केडीबीजी) बहुत छोटी थीं, लेकिन फिर से चीजें बदल गईं :)

लब्बोलुआब यह है - हाँ आपको कुछ सीखने का प्रयास करने की आवश्यकता है, लेकिन उसके बाद आप केवल उतने ही उत्पादक होंगे जितना कि आप विंडोज पर हैं।


मैं अक्सर (लिनक्स पर) gdbअंदर से चलाता हूं emacsऔर यह बहुत मदद करता है।
बेसिल स्टारीनेवविच

1

आपके द्वारा पहले से प्राप्त शेष सभी अच्छी सलाह के लिए, मैं क्रमशः ack और pss से कुछ लिंक जोड़ना चाहूंगा ।

वे प्रोग्रामर के उद्देश्य से हैं, जिन्हें विशेष रूप से स्रोत कोड के बारे में ध्यान रखना है, grep पर सुधार करने की कोशिश कर रहा है।


0

शानदार जवाब। उन्हें जोड़ना,

जब मैंने यह कदम उठाया, तो मैंने जो गलती की थी, वह जीएनयू बिल्ड सिस्टम को उचित परिश्रम दिए बिना कोड में कूदने की कोशिश कर रहा था, जो कोड परिवर्तन करने के इच्छुक होने पर मुझे काटने के लिए वापस आ गया। ऑटोमैके / ऑटोकॉन्फ / मेक सूट ऑफ टूल्स कैसे काम करते हैं, इसे समझने में कुछ दिनों का समय बिताइए, आप इसके बाद बहुत जल्दी हो जाएंगे।

उपकरणों के बारे में - ग्रहण + सीडीटी / जीडीबी + डीडीडी वास्तव में एक लंबा रास्ता तय करता है।


-1

इसे आसान बनाने के लिए यहां कुछ सलाह दी गई हैं:

  1. शुरू से शुरू करो। इसका मतलब है कि आप पहले एक मेकफाइल रिप्लेसमेंट के रूप में बैश स्क्रिप्ट का उपयोग करेंगे और एक बार निर्भरता की आवश्यकता होने पर सरल मेकफाइल्स। शुरुआत में इसे सरल रखें। आपके मेकफाइल को 15 विभिन्न यूनिक्स प्लेटफार्मों को संभालने की आवश्यकता नहीं है - बस इसे निर्भरता के साथ संकलित करें। (आपका आरंभिक मेकफाइल जैसा दिखने वाला है: सभी: g ++ -o main main.cpp) (अधिक जटिल उदाहरण http://sivut.koti.soon.fi/~terop/Makefile से पाया जा सकता है - खरोंच से शुरू होने पर , फ़ाइल को प्रोजेक्ट में कॉपी करें, फ़ाइल नाम बदलें, mkdir objs डायरेक्टरी, आप जो चाहें बदल सकते हैं)
  2. आईडीई को भूल जाओ। यह केवल आपको धीमा बनाने वाला है। कोड को पढ़ना सीखें और अपनी परियोजना की फ़ाइल पदानुक्रम को याद रखें। सामान्य कमांडलाइन टूल जैसे 'cd dir' और 'emacs foo.cpp' को इतना ऑटोमैटिक होना चाहिए कि आप इसके बारे में दो बार न सोचें।
  3. सिंटैक्स हाइलाइटिंग और इंटैलिजेंस को भूल जाओ। यह कभी भी उसी तरह से काम करने वाला नहीं है जैसा कि यह विज़ुअल स्टूडियो पर काम करता है, और इसके संकेत केवल आपको भ्रमित करने के लिए जा रहे हैं क्योंकि यह आपके द्वारा उपयोग किए जाने वाले से अलग है। उन पर भरोसा न करना सीखें।
  4. Gdb एक अच्छा डीबगर है। आपको कॉल स्टैक मिलेगा। कोड के आसपास कदम रखने की कोशिश भी न करें, यह बहुत अच्छा काम नहीं करने वाला है। वेलग्रिंड का भी उपयोग करें। ब्रेकपॉइंट बहुत अच्छे हैं, लेकिन उन पर बहुत अधिक भरोसा न करें; केवल शायद ही कभी gdb के साथ प्रयोग किया जाता है।
  5. यदि आपका संकलन शेल में सरल 'मेक' के अलावा कुछ और है, तो आपको अपने एडिट-कंपाइल-डिबग-एडिट-साइकल को फिर से क्लिक करना होगा।
  6. यहां एक चाल है जो दृश्य स्टूडियो नहीं कर सकता है: एक ही समय में स्क्रीन पर हेडर फ़ाइल और .cpp फ़ाइल दोनों दिखाएं - ताकि दोनों टैब के साथ उनके बीच फ़्लिप किए बिना दिखाई दे सकें। Emacs कर सकते हैं। तो नोटपैड कर सकते हैं। दृश्य स्टूडियो या IDE नहीं कर सकता।
  7. इमैक कीबाइंडिंग सीखें। यह आपको और तेज करने वाला है। एक अच्छा संकेत यह है कि सभी कुंजी कीबोर्ड में बहुत निकट स्थित हैं। कमांड क्रम लंबे हैं, लेकिन उन्हें टाइप करना अभी भी तेज है।
  8. गो-टू-डेफिनिशन को बदलने के लिए आसान ट्रिक है: कोड को उसी फ़ाइल में लिखें, और एस्क में <और Cs :: myfunction का उपयोग उस फ़ंक्शन को खोजने के लिए करें जिसे आप चाहते हैं। यदि आपने कई छोटी फ़ाइलों का उपयोग किया है तो प्रक्रिया अलग है - आपका कोड अलग दिखने वाला है। (नोटपैड में ctrl-f सीखें, और आपको यह विचार मिलेगा)। लेकिन आपको निश्चित रूप से इसे शेल में करने की आवश्यकता नहीं है।
  9. पाठ संपादक स्टार्टअप समय बहुत महत्वपूर्ण है। यदि इसे खोलने में 1 सेकंड से अधिक समय लगता है, तो यह अच्छा नहीं है। हर आईडीई को इस आवश्यकता के कारण तोड़ दिया जाता है। नोटपैड और एमएसीएस ठीक हैं।
  10. Emacs में गोटो-लाइन प्रोग्रामिंग के लिए महत्वपूर्ण विशेषता है। इसे कुछ कुंजी से बांधें। मैं Cx जी का उपयोग करता हूं

1
-1 के लिए "कोड को उसी फ़ाइल में लिखें": आपको मज़ाक करना चाहिए! और आप कैसे स्वीकार कर सकते हैं "कोड के चारों ओर कदम रखने की कोशिश भी न करें" और फिर भी जोर देते हैं कि "जीडीबी एक अच्छा डीबग है"!
सोजर्ड

@sjoerd: ये केवल तकनीकें हैं जिन्हें हमने ठीक से काम करने के लिए पाया है। यह नहीं हो सकता है कि अन्य लोग क्या उपयोग कर रहे हैं, लेकिन वे लिनक्स वातावरण में अच्छी तरह से काम करते हैं - बड़े कार्यक्रमों को जरूरी रूप से बड़ी फ़ाइलों का उपयोग करने की आवश्यकता होती है। प्रोग्रामिंग में 10 साल के अनुभव के साथ, उसे अब कोड में इधर-उधर जाने की जरूरत नहीं है - उसे पहले से ही पता है कि प्रोग्राम एक्जीक्यूशन कैसे काम करता है और कोड के माध्यम से कदम बढ़ाने में मदद की जरूरत नहीं है।
tp1
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.