परियोजनाओं के बीच डेल्फी स्रोत फ़ाइलों को साझा करने का सबसे अच्छा तरीका क्या है?

Question

परियोजनाओं के बीच डेल्फी स्रोत फ़ाइलों को साझा करने का सबसे अच्छा तरीका क्या है?

स्पष्टीकरण: हम कई डेल्फी परियोजनाओं में एक एकल स्रोत फ़ाइल का उपयोग करना चाहते हैं। हम एक ही फाइल को एकाधिक फ़ोल्डरों में रखने के लिए हमारे एससीएम उपकरण का उपयोग कर रहे हैं, लेकिन यह एक अति-सुरुचिपूर्ण अनुभव नहीं है और हम ऐसे टूल पर माइग्रेट करने पर भी विचार कर रहे हैं जो इसका समर्थन नहीं करता है।

जैसा कि मैं इस प्रश्न की जांच कर रहा हूं, मैंने कुछ अलग दृष्टिकोणों पर विचार किया है, लेकिन मैं जानना चाहता हूं कि आप क्या कर रहे हैं और आप अपना दृष्टिकोण कैसे प्राप्त करते हैं।

महत्वपूर्ण परिदृश्य:

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

बातें:

• पास शब्द: जगह में डाल करने के लिए
  • क्या दृष्टिकोण सरल किया जाएगा?
• लंबी अवधि:
  • क्या दृष्टिकोण का उपयोग करने और बनाए रखने के लिए सरल हो जाएगा?

धन्यवाद, अग्रिम में, आपकी प्रतिक्रिया के लिए!

मैटिस

---

--- अद्यतन ---

आपकी प्रतिक्रिया का धन्यवाद, उत्तर, टिप्पणियां और वोट के माध्यम से!

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

रहें रहें! (लेकिन अपनी सांस पकड़ नहीं है, आप मिनटों में गला घोंटना होगा:! पी)

Answer 1

उपयोग स्रोत नियंत्रण प्रणाली के फ़ाइल शेयरिंग फ़ीचर

• प्रो: यदि एससीएम तीव्र और आसान, स्थापित करने के लिए प्रणाली इसका समर्थन करता है।
• प्रो/कॉन: प्रत्येक उपभोक्ता परियोजना स्वतंत्र रूप से संकलन-समय को प्रभावित कर सकती है।
• कॉन: स्रोतों की स्थानीय कार्यशील प्रति में कोई आधिकारिक स्थान नहीं है।
  • यह भ्रम हो सकता है।
• कॉन: स्रोत परिवर्तन अन्य स्थानों में चेकइन और पुनः पुनर्प्राप्त होने तक दिखाई नहीं देते हैं।
  • ठीक से अन्य परियोजनाओं को सत्यापित करने के लिए, चेकइन से पहले, संभव है लेकिन बट में एक शाही दर्द।
• कोन: सभी एससीएम सिस्टम साझा फ़ाइलों का समर्थन।
  • सबवर्सन के करीबी सुविधा फ़ोल्डर स्तरीय SVN है: बाहरी।

(संपादित करें: इस retitled भ्रम से बचने के।पाठ्यक्रम के , हर कोई का उपयोग करना चाहिए स्रोत नियंत्रण! :-))

Answer 2

कॉपी-ऑन-संकलन

• प्रो: फ़ाइल साझा प्रबंधित किया जा सकता फ़ाइल-दर-फ़ाइल।
• प्रो/कॉन: प्रत्येक उपभोक्ता परियोजना स्वतंत्र रूप से संकलन-समय को प्रभावित कर सकती है।
• कोन: डीबगर अस्थायी प्रतिलिपि, नहीं सरकारी संस्करण से लिंक करेगा।
  • कार्यसूची: किसी तरह यह बदलने के लिए है कि क्या वहाँ देखें।
• कोन: कुछ काम लग सकता है MSBuild परियोजनाओं की स्थापना के लिए।
• कॉन: साझा फ़ाइलों को बढ़ाने के लिए मुश्किल हो सकती है।
  • डेल्फी के MSBuild नियमों के कुछ पुनर्लेखन शामिल हो सकता है।

Answer 3

कॉपी-संकलन हटाएं

• प्रो: प्रत्येक फ़ाइल का केवल एक आधिकारिक प्रतिलिपि, संपादित करने के लिए।
• प्रो: डीबगर, अस्थायी कॉपी से लिंक नहीं करेगा क्योंकि इसमें डिबग समय से हटा दिया गया है।
  • TODO: सत्यापित करें कि डीबगर मूल स्रोत पाएगा, अगर हम इसे "ब्राउज़िंग पथ" में डाल देते हैं।
• प्रो: फ़ाइल साझा फ़ाइल-दर-फ़ाइल प्रबंधित किया जा सकता।
• प्रो/कॉन: प्रत्येक उपभोक्ता परियोजना स्वतंत्र रूप से संकलन-समय को प्रभावित कर सकती है।
• कोन: कुछ काम लग सकता है MSBuild परियोजनाओं की स्थापना के लिए।
• कोन: मुश्किल/असंभव संवर्द्धित साझा फ़ाइलें निर्माण करने के लिए हो सकता है।
  • डेल्फी के MSBuild नियमों के कुछ पुनर्लेखन शामिल हो सकता है।

Answer 4

उपयोग एक लाइब्रेरी प्रोजेक्ट

• प्रो: संभावित संपादित करने के लिए प्रत्येक फ़ाइल के केवल कभी एक प्रति।
• प्रो: प्रत्येक स्रोत फ़ाइल के लिए केवल एक संकलन करें।
  • कम समय संकलित करने के लिए।
  • निर्भर परियोजनाओं के बीच लगातार संकलन।
  • प्राकृतिक वृद्धिशील बनाता है।
• प्रो: डीबगर स्वाभाविक रूप से उचित स्रोत से जोड़ता है।
  • TODO: पुष्टि करें।
• प्रो/कॉन: उपभोक्ता परियोजनाएं स्वतंत्र रूप से संकलन-समय को प्रभावित नहीं कर सकती हैं।
• Con: फ़ाइल-दर-फ़ाइल स्तर पर साझा करना प्रबंधित करना मुश्किल हो सकता है।
  • TODO: जांच करें।
• Con: स्थापित करने के लिए महत्वपूर्ण प्रयास कर सकते हैं।
  • एमएसबिल्ड परियोजनाओं का सेटअप।
  • आवश्यक परियोजना सेटिंग्स को केंद्रीकृत किया जाना चाहिए और इन परिवर्तनों को सत्यापित किया जाना चाहिए।

Answer 5

मुझे लगता है कि कोई विशेष समाधान की आवश्यकता है। हमारी परियोजना में (कोड के बड़े क्षेत्रों को साझा करने वाले कई अनुप्रयोग) हम निम्नलिखित दृष्टिकोण का उपयोग करते हैं:

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

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

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

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

Answer 6

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

\Main 
    \Project1 
    \Project2 
    ... 
    \CommonUnits 

हम प्रासंगिक परियोजनाओं (चाहे यह प्रोजेक्ट फ़ाइल को उसी फ़ोल्डर में नहीं है) के लिए आम इकाइयों जोड़ें। इसके अलावा, कभी-कभी छोटे कोड अंतरों के लिए प्रोजेक्ट-स्तरीय सशर्त परिभाषा (प्रोजेक्ट | विकल्प | निर्देशिकाएं/कंडीशनल) का उपयोग करना आसान होता है। उदाहरण के लिए, प्रोजेक्ट 1 में "APP_PROJECT1" जैसा कुछ परिभाषित होगा और फिर आप विशिष्ट कोड लिखने के लिए सामान्य इकाइयों में $ IFDEF का उपयोग कर सकते हैं।

क्या महत्वपूर्ण है: इस मामले में पूरे सूट के लिए एक स्रोत नियंत्रण भंडार होना बेहतर है (रूट मुख्य रूप से \ Main है)।