स्रोत फ़ाइल संगठन

Question

मुझे अपनी स्रोत फ़ाइलों को व्यवस्थित करने में कुछ परेशानी हो रही है।

मेरे पास मेरा छोटा, लेकिन कोड की बढ़ती संग्रह है जिसे मैं विभिन्न परियोजनाओं में उपयोग करना चाहता हूं। फ़ाइल और फ़ोल्डर लेआउट कुछ इस तरह है:

पुस्तकालय \ sub1 \ source.h

पुस्तकालय \ sub1 \ source.cpp

पुस्तकालय \ sub2 \ source.h

पुस्तकालय \ sub2 \ source.cpp

में से एक मेरी समस्या यह है कि मैं अपनी अन्य परियोजनाओं में, आवश्यकतानुसार इस कोड को शामिल करना चाहता हूं। आज तक मैंने libary कोड को इंगित करने के लिए पूर्ण पथ का उपयोग किया है, लेकिन एक बेहतर तरीका होना चाहिए।

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

तो मेरा प्रश्न संक्षेप में है कि मैं इसे कैसे ठीक करूं? उपर्युक्त स्थिति को संभालने का उचित/सर्वोत्तम तरीका क्या है।

Answer 1

मुझे नहीं लगता कि ऐसा करने के लिए उचित तरीका है - यह उस पर निर्भर करेगा जो आप प्राप्त करने की कोशिश कर रहे हैं।

यहाँ कुछ चीजें आप के बारे में पता नहीं हो सकता है:

• आप अपनी परियोजनाओं में संबंधित पथ का उपयोग कर सकते हैं।

• आप पथों में पर्यावरण चर का उपयोग कर सकते हैं।

• आप विजुअल स्टूडियो के खोज नियमों में निर्देशिका जोड़ सकते हैं।

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

Answer 2

पहला: अपनी प्रोजेक्ट में सभी प्रयुक्त निर्देशिकाओं को पथ शामिल करें। यदि संभव हो तो उन्हें सापेक्ष पथ के रूप में जोड़ें।

दूसरा: आपको अपनी प्रोजेक्ट में सभी प्रयुक्त लाइब्रेरी/स्रोत फ़ाइलों को जोड़ना होगा। यह या तो प्रोजेक्ट एक्सप्लोरर में या प्रोजेक्ट-> लिंकर टैब में किया जा सकता है। बाद के मामले में, आपको प्रोजेक्ट लाइब्रेरी पथों में भी प्रयुक्त निर्देशिकाएं जोड़नी होंगी।

आमतौर पर # अंतर्निहित निर्देशों में पथों का उपयोग करने का अच्छा विचार नहीं है।

Answer 3

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

लाइब्रेरी की निर्देशिका संरचना ही है, के आयोजन के लिए अभी मैं निम्नलिखित संरचना की तरह कुछ पर बसे

• library1/widget.h
• library1/निजी/onlyinlib.h
• library1/निजी/widget.cpp

(और यदि लागू हो)

• library1/निजी/संसाधन/widget.jpg
• library1/निजी/परियोजना/widget.xcode

मैं पुस्तकालय रास्ते में सीधे सभी हेडर रखा, और एक सबफ़ोल्डर private जो सब कुछ शामिल होंगे है कि केवल है लाइब्रेरी द्वारा उपयोग किया जाता है, लेकिन इसे साझा/खुलासा नहीं किया जाना चाहिए।

सबसे बड़ा लाभ यह है कि हर परियोजना मैं शुरू ही की जरूरत है एक मेरी पुस्तकालयों युक्त निर्देशिका पर इंगित पथ शामिल है, तो हर (सार्वजनिक) शामिल की तरह किया जाता है

#include "library1/widget.h" 

निजी शामिल बस रहे हैं

#include "onlyinlib.h" 

यह फायदे की एक संख्या है:

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

Answer 4

तुम सिर्फ (जैसे, शायद आप इसे करने के लिए संशोधन या बदलाव करने की जरूरत है) एक पूर्व संकलित संस्करण के साथ जोड़ने के बजाय तीसरे पक्ष के कोड शामिल होना चाहिए, तो में शाखाओं यह विचार करें जो कुछ भी आप स्रोत-नियंत्रण के लिए उपयोग करते हैं:

• /ट्रंक/... --- अपने कोड यहाँ जाता है
• /तीसरे पक्ष --- तीसरे पक्ष के पुस्तकालयों के प्राचीन प्रतियां यहां जाना
  • /तीसरे पक्ष/lib1
  • /तीसरे पक्ष/lib2
  • इत्यादि।
• /ट्रंक/lib1 --- से branched:/तीसरे पक्ष/lib1, शायद स्थानीय परिवर्तन
  • इस के साथ संस्करण है कि आप के साथ/लिंक का निर्माण होता है।

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

उदाहरण के लिए, "lib1" एक नया संस्करण विज्ञप्ति:

• को/तीसरे पक्ष/lib1 परिवर्तन प्रतिबद्ध होते हैं।
• /ट्रंक से/तीसरे पक्ष/lib1 मर्ज/lib1
• किसी भी विलय के विरोध को ठीक करें।

यह आईएमओ, तीसरे पक्ष के पुस्तकालयों को अपग्रेड करने का एकमात्र तरीका है जिस पर आपने स्थानीय संशोधन किए हैं।