सी ++ क्रॉस-प्लेटफ़ॉर्म लाइब्रेरी और बाइंडिंग के लिए सर्वश्रेष्ठ फ़ोल्डर संरचना

Question

मैं सी ++ में लिखे जाने वाले क्रॉस-प्लेटफ़ॉर्म लाइब्रेरी पर काम शुरू करने वाला हूं। सड़क के नीचे, मैं पाइथन, जावा इत्यादि जैसी अन्य भाषाओं के लिए बाइंडिंग लागू करना चाहता हूं। लाइब्रेरी को प्रमुख प्लेटफ़ॉर्म पर उपलब्ध होना आवश्यक है: Win32, Linux और Mac OSX।

हालांकि एप्लिकेशन वास्तव में एक पुस्तकालय है, कुछ बुनियादी कंसोल कार्यक्रमों को प्रदर्शन और परीक्षण के लिए इसके साथ बंडल किया जाएगा।

मैं सबवर्सन में सामान संग्रहीत करने से पहले एक इष्टतम फ़ोल्डर संरचना के साथ आना चाहता हूं।

मैं की तरह कुछ की सोच रहा हूँ:

/project     //Top level folder 

     /bin    //Binaries ready for deployment 
      /linux_amd64 //Linux AMD64 platform 
        /debug //Debug build - duplicated in all platforms 
        /release //Release build - duplicated in all platforms 
      /linux_i386  //Linux 32-bit platform 
      /macosx   //Mac OS X 
      /win32   //Windows 32-bit platform 
        /cygwin //Windows 32-bit platform compiled with Cygwin 
        /vs.net //Windows 32-bit platform compiled with Visual Studio .NET 
      /win64   //Windows 64-bit platform 

     /build    //Make and build files, IDE project files 
      /linux_amd64 //Linux AMD64 platform 
      /linux_i386  //Linux 32-bit platform 
      /macosx   //Mac OS X 
      /win32   //Windows 32-bit platform 
      /win64   //Windows 64-bit platform 

     /config    //Configuration files that accompany the binaries 

     /data    //Data files that accompany the binaries 

     /doc    //Documentation 

     /lib    //External or third-party libraries 
      /platforms  //Platform-specific code for ... 
         /linux_amd64 //Linux AMD64 platform 
         /linux_i386  //Linux 32-bit platform 
         /macosx   //Mac OS X 
         /win32   //Windows 32-bit platform 
         /win64   //Windows 64-bit platform 
      /src   //Available library source code in subfolders 

     /src    //Source code tree - this will contain main.cpp 
      /bindings  //Bindings to other languages such as ... 
         /python 
         /java 
      /h    //Header files 
      /modules  //Platform-independent modules, components or subprojects 
      /platforms  //Platform-specific code for ... 
         /linux_amd64 //Linux AMD64 platform-specific code 
         /linux_i386 //Linux 32-bit platform-specific code 
         /macosx 
         /win32  //Windows 32-bit platform-specific code 
         /win64  //Windows 64-bit platform 

     /test    //Automated test scripts 

आप सुझाव हैं, तो मैं उन्हें यह जानकर प्रसन्नता होगी। मुझे आश्चर्य है कि कोई उपकरण है जो इस संरचना को बनाने में मदद कर सकता है।

मैं सीएमके और सबवर्जन का उपयोग करने की योजना बना रहा हूं।

Answer 1

बाइनरी फ़ाइलों के लिए आपको विभिन्न प्लेटफ़ॉर्म फ़ोल्डरों की आवश्यकता क्यों है? आप इस स्रोत कोड को विभिन्न प्लेटफॉर्म के तहत बनाने के लिए जा रहे हैं लेकिन एक ही फाइल सिस्टम के साथ?

यदि हां, तो मुझे लगता है कि आपको कंपिलर विशिष्ट फ़ोल्डर भी चाहिए।

आप डिबग और रिलीज बिल्ड के लिए अलग-अलग फ़ोल्डरों का उपयोग क्यों नहीं करते हैं, शायद यूनिकोड और गैर-यूनिकोड, सिंगल-थ्रेडिंग या मल्टीथ्रेडिंग बिल्ड?

बीजेएएम या स्कैन को प्रतिलिपि बनाने के लिए देखें। हो सकता है कि आपको बिल्ड निर्देशिका में विभिन्न फ़ोल्डर्स की आवश्यकता न हो।

मुझे लगता है कि यह बेहतर होगा अगर "मॉड्यूल" निर्देशिका के सभी मॉड्यूल में परीक्षण स्वयं के लिए "परीक्षण" निर्देशिका होगी।

---

और आखिरी - बूस्ट लाइब्रेरी देखें, यह प्लैटोफ्रम अपरिपक्व लाइब्रेरी जिसमें अच्छी संरचना है।

एंटीदर प्लेटफार्म अप्रत्याशित परियोजनाओं से विचार प्राप्त करने का भी प्रयास करें।

बूस्ट फ़ोल्डरों संरचना:

boost - root dir 
- boost - library header lib (for users) 
- libs - library source dir (one dir per lib) 
    - build - library build files (if they are needed) 
    - doc - documentation files 
    - example - sample programs 
    - src - library source files 
    - test - programs and srcipts for testing module 
- bin - created by bjam build system 
    - libs 
     - <lib-name> 
      for all compiled folders from libs [example|test|build] 
       - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]> 
        contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system 

- doc 
- tools 

आप bjam का चुनाव करते हैं - आप का निर्माण और बिन फ़ोल्डर्स संरचना पर चिंतित नहीं किया जाएगा।

इसके अलावा आपके libs/src/dir प्लेटफॉर्म स्पैसिफिक फ़ाइलों के लिए सभी प्लेटफ़ॉर्म फ़ाइलों और जोड़े डीआईआर के लिए स्वयं भी हो सकता है।

मैं अपने फ़ोल्डर में किसी भी गंभीर समस्याओं, structre हो सकता है आप उन्हें जब शुरू लिखने परियोजना प्रोटोटाइप देखेंगे नहीं दिख रहा।

Answer 2

संरचना मेरे लिए अच्छा लग रहा है, लेकिन कुछ बिंदु हैं:

• यह अलग निर्देशिका में सी ++ शीर्ष लेख और स्रोत फ़ाइलों को अलग करने के सामान्य है, या हो सकता है वहाँ मॉड्यूल निर्देशिका आप नहीं दिखा रहे हैं में संरचना है ?आप के लिए है -
• आप शायद निर्देशिका मध्यवर्ती फाइल की तरह *
• में .obj डाल आप डिबग के लिए अलग निर्देशिका
• InnoSetup तरह संस्थापक के लिए एक निर्देशिका की आवश्यकता होगी और आउटपुट फ़ाइलों को रिहा करने और उनके स्थापित फ़ाइलों उपयोगी हो सकता है करना चाहते हैं इन

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

Answer 3

मैंने हाल ही में एक निर्देशिका में question about packaging headers पोस्ट किया है, जिसमें निर्देशिकाओं की एक छोटी संख्या शामिल है।

क्या आप Win64 के लिए पूरा करने जा रहे हैं? यह एक तेजी से महत्वपूर्ण लक्ष्य होगा।

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

इसके बजाय, यदि आपका कंपाइलर इसे अनुमति देता है, तो मध्यवर्ती निर्देशिकाओं को एक तरफ रखें।

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

Answer 4

क्या मैं बिल्ड फाइलों को वर्गीकृत करने के लिए आर्किटेक्चर का उपयोग नहीं करने का सुझाव दे सकता हूं?

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

/project 
    /build 
     /linux 
     /macosx 
     /win32 (or win) 

और उदाहरण मामले में शामिल हैं:

/project 
    /build 
     /linux 
     Make.defs 
     Makefile [i386, amd64] 
     /win32 
     /VC8 
      /<project> 
       <project>.vcproj 
      <solution>.sln [Win32, x64] 
     /VC11 
      /<project> 
       <project>.vcxproj 
      <solution>.sln [Win32, x64, ARM] 

आप वास्तुकला परिभाषित करने के लिए नहीं करना चाहते हैं विन्यास के माध्यम से बनाता है, कैसे के बारे में मंच प्रकार के तहत किसी अन्य फ़ोल्डर परत?

/project 
    /build 
     /linux 
     /linux_amd64 
     /linux_i386 
     /macosx 
     /? 
     /win32 (or win) 
     /win32 
     /win64 

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