सी ++ लाइब्रेरी के लिए निर्देशिका संरचना

Question 1

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

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

मैंने "C ++ लाइब्रेरी डायरेक्टरी स्ट्रक्चर" जैसे शब्दों के लिए Google में जाने की कोशिश की, लेकिन कुछ भी उपयोगी नहीं है। मुझे कुछ बहुत बुनियादी दिशानिर्देश मिले, लेकिन कोई क्रिस्टल स्पष्ट समाधान नहीं।

कुछ खुले स्रोत पुस्तकालयों को देखते हुए, मैं निम्नलिखित के साथ आया:

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

मेरे पास मल्टी-प्लेटफॉर्म डेवलपमेंट / ओपन सोर्स प्रोजेक्ट्स के साथ कोई / थोड़ा सा पिछला अनुभव नहीं है और मैं इस बात से काफी चकित हूं कि मुझे इस तरह के प्रोजेक्ट को तैयार करने के बारे में कोई अच्छा दिशानिर्देश नहीं मिला है।

इस तरह की लाइब्रेरी परियोजना की संरचना आम तौर पर कैसे की जानी चाहिए? क्या सीए को पढ़ने की सलाह दी जाती है? क्या कुछ अच्छे उदाहरण हैं?

Question 2

यूनिक्स पुस्तकालयों के बीच एक बात बहुत आम है कि वे इस तरह से आयोजित की जाती हैं:

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

यह कुछ हद तक पारंपरिक यूनिक्स फाइल सिस्टम को दर्शाता है /usrजहां:

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

बेशक, ये अंत में हो सकते हैं /usr/local(जो कि GNU ऑटोकॉनफ के लिए डिफ़ॉल्ट इंस्टॉल उपसर्ग है), और वे इस संरचना का बिल्कुल भी पालन नहीं कर सकते हैं।

कोई कठिन-व्रत नियम नहीं है। मैं व्यक्तिगत रूप से इस तरह से चीजों को व्यवस्थित नहीं करता हूं। ( ./src/उदाहरण के लिए, सबसे बड़ी परियोजनाओं को छोड़कर, मैं एक निर्देशिका का उपयोग करने से बचता हूं । मैं ऑटोटूलस का उपयोग नहीं करता, इसके बजाय प्रेकेक को प्राथमिकता देता हूं।)

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

Question 3

इस भयानक सम्मेलन है कि मैं हाल ही में आया था कि सहायक हो सकता है: पिचफोर्क लेआउट ( GitHub पर भी )।

योग करने के लिए, उपधारा 1.3 बताता है कि:

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

अन्य निर्देशिकाएँ रूट पर नहीं दिखनी चाहिए।

build/: एक विशेष निर्देशिका जिसे परियोजना के स्रोत का हिस्सा नहीं माना जाना चाहिए। पंचांग निर्माण परिणामों के भंडारण के लिए उपयोग किया जाता है। स्रोत नियंत्रण में जाँच नहीं की जानी चाहिए। यदि स्रोत नियंत्रण का उपयोग किया जाता है, तो स्रोत नियंत्रण उपेक्षा-सूचियों का उपयोग करके अनदेखा किया जाना चाहिए।

src/: मुख्य संकलन योग्य स्रोत स्थान। संकलित घटकों के साथ परियोजनाओं के लिए उपस्थित होना चाहिए जो सबमॉड्यूल का उपयोग नहीं करते हैं। की उपस्थिति में include/भी निजी हेडर शामिल हैं।

include/: सार्वजनिक हेडर के लिए निर्देशिका। उपस्थित हो सकते हैं। उन परियोजनाओं के लिए छोड़ा जा सकता है जो निजी / सार्वजनिक हेडर के बीच अंतर नहीं करती हैं। सबमोडुल्स का उपयोग करने वाली परियोजनाओं के लिए छोड़ा जा सकता है।

tests/: परीक्षणों के लिए निर्देशिका।

examples/: नमूने और उदाहरण के लिए निर्देशिका।

external/: प्रोजेक्ट द्वारा उपयोग किए जाने वाले पैकेज / प्रोजेक्ट के लिए निर्देशिका, लेकिन प्रोजेक्ट के हिस्से के रूप में संपादित नहीं की गई।

extras/: परियोजना के लिए अतिरिक्त / वैकल्पिक सबमॉडल्स युक्त निर्देशिका।

data/: परियोजना के गैर-स्रोत कोड पहलुओं वाली निर्देशिका। इसमें ग्राफिक्स और मार्कअप फाइलें शामिल हो सकती हैं।

tools/: डायरेक्टरी जिसमें डेवलपमेंट यूटिलिटीज होती हैं, जैसे स्क्रिप्ट्स का निर्माण और रिफैक्टिंग

docs/: परियोजना प्रलेखन के लिए निर्देशिका।

libs/: मुख्य परियोजना सबमॉड्यूल के लिए निर्देशिका।

इसके अतिरिक्त, मुझे लगता है कि extras/निर्देशिका वह जगह है जहाँ आपके पायथन बाइंडिंग को जाना चाहिए ।

Question 4

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

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

Question 5

मुझे लगता है कि wxWidgets लाइब्रेरी (खुला स्रोत) एक अच्छा उदाहरण है। वे कई अलग-अलग प्लेटफार्मों (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) और कंपाइलर्स (MSVC, GCC, CodeWarrior, Watcom, आदि) का समर्थन करते हैं। आप यहां ट्री लेआउट देख सकते हैं:

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/

Question 6

मैं आपको सीएमके का उपयोग करने की सिफारिश कर सकता हूं ... यह क्रॉस प्लेटफॉर्म डेवलपमेंट के लिए है और यह बहुत अधिक लचीला है कि ऑटोमेट करें, सीएमके का उपयोग करें और आप सभी सिस्टम पर अपने स्वयं के direcory स्ट्रक्चर के साथ क्रॉस प्लेटफॉर्म कोड लिखने में सक्षम होंगे।