2011-02-08 9 views
6

क्या कोई आपकी स्रोत फ़ाइलों को व्यवस्थित करने और लिनक्स के तहत सी ++ का उपयोग करते समय निर्माण के प्रबंधन के लिए कुछ अच्छे अभ्यास प्रस्तावित कर सकता है। मैं अपने निर्माण को प्रबंधित करने के लिए सीएमके का उपयोग करता हूं हालांकि मैं इस समय जटिल संरचनाओं का उपयोग नहीं करता हूं। हमें बताएं कि हमारे पास निम्नलिखित तीन परिदृश्य हैं।
1. सरल .cpp और .h फ़ाइलों से कुछ निष्पादन योग्य बनाने के लिए मेकफ़ाइल एप्लिकेशन के लिए
2. अन्य लोकप्रिय साझा पुस्तकालयों का उपयोग करने वाली स्थिर/साझा लाइब्रेरी बनाने के लिए ओपनसीवी और ओपनजीएल, उदाहरण के लिए।
3. उदाहरण के लिए, हमें बताएं कि हमें एक निष्पादन योग्य बनाने की आवश्यकता है जिसका स्रोत फ़ाइलें ओपनसीवी जैसे बाहरी पुस्तकालयों का उपयोग करती हैं और एक कस्टम स्थिर लाइब्रेरी भी है जिसे हम ने स्वयं बनाया है (उदाहरण के लिए, एक कस्टम स्थिर लाइब्रेरी संबंधित शीर्षलेख जिन्हें हम ऊपर चरण 2 के साथ बनाया गया है)।लिनक्स के तहत सी ++ विकास में सीओ ++ विकास में निर्माण और निर्माण (0 जनरेटर के रूप में सीएमके)

मुझे यकीन है कि आप में से कई जटिल पुस्तकालय परियोजनाओं पर काम करते हैं जहां निर्माण प्रक्रिया इतना आसान नहीं है। मैं खुले स्रोत उत्साही और हैकर्स से खुले स्रोत परियोजनाओं में योगदान देने वाले अद्भुत उत्तरों की उम्मीद कर रहा हूं। आप लोग अपने स्रोत कोड को व्यवस्थित कैसे करते हैं?

उत्तर

4

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

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

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

|--cmake 
| | 
| |--FindXXX.cmake 
| 
|--src 
| | 
| |--projectABC 
| | | 
| | |--CMakeLists.txt 
| | 
| |--library1 
| | | 
| | |--CMakeLists.txt 
| | 
| |--library2 
|  | 
|  |--CMakeLists.txt 
| 
|--CMakeLists.txt 
| 
|--build-release 
|--build-debug 
|--build-msvc-release 
|--[...] 
+0

आपको बहुत बहुत धन्यवाद। – hAcKnRoCk

+0

@trenki जहां आप सामान्य हेडर फाइलें डालते हैं? क्या आपके पास src के अंतर्गत "शामिल" निर्देशिका है? – hopia

+0

@hopia: अगर मैंने "src" निर्देशिका के समान स्तर पर "शामिल" निर्देशिका में लाइब्रेरी के लिए _public_ शीर्षलेख फ़ाइलें डाली हैं, जैसे कि अधिकांश स्रोत स्रोत पुस्तकालय इसे करते हैं। – trenki

0

मैं थीम द्वारा स्रोतों का आयोजन करने और अलग बाइनरी (या ऑब्जेक्ट) निर्देशिका रखने का सुझाव देता हूं। एक ही निर्देशिका में शीर्षलेख फ़ाइलें और स्रोत फ़ाइलें। प्रत्येक अलग संकलक या मंच के लिए एक निर्देशिका:

Fields 
|-- src 
| field_int.hpp 
| field_int.cpp 
| 
|-- obj_linux_gcc 
| | 
| |-- debug 
| | 
| |-- release 
| 
|-- obj_windows_gcc 
| 
|-- obj_visual_studio 

विभिन्न दुकानों पर हाल के वर्षों में, मैं ने पाया है कि बिना विषय के संबंध अलग निर्देशिका में शीर्ष लेख और स्रोत फ़ाइलें, को अलग करने, बनाए रखने के लिए एक दर्द है और यह भी एक लेता है लंबे समय से परिचित होने के लिए।

"यह सिर्फ मेरी राय है, मैं गलत हो सकता हूं।" - डेनिस मिलर, हास्य अभिनेता।

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