2011-04-21 17 views
8

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

अभी मैं निर्देशिका वृक्ष

 \Project 
    \build\output 
    \dist\release 
    \dist\debug 
    \doc 
    \env 
    \res 
    \src

\src निर्देशिका *.pas और *.dfm फ़ाइलें और project.dpr शामिल निम्नलिखित का उत्पादन किया है। विभिन्न संसाधन (आइकन, छवियां और फोंट) \res निर्देशिका में रहते हैं। \env डीबगिंग उद्देश्यों के लिए विभिन्न वातावरण बनाने के लिए उपयोग किया जाता है। इस डीआईआर में project.exe बनाने के लिए आईडीई सेट किया गया था। बिल्ड स्क्रिप्ट build फ़ोल्डर में संग्रहीत हैं। dcc32.exe की सहायता से ये स्क्रिप्ट उत्पाद वितरण (exe में डीबग जानकारी के साथ और बिना) dist\release और dist\debug फ़ोल्डरों में उत्पाद वितरण का उत्पादन करती हैं। build\output आईडीई या बिल्ड स्क्रिप्ट के अंदर बिल्ड प्रक्रिया के दौरान डीसीयू फाइलों को सहेजने के लिए प्रयोग किया जाता है।

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

यह पिछले सप्ताह तक एक बड़ी समस्या नहीं थी। मैंने एक बग को ठीक करने के लिए तीसरे पक्ष के घटक को संशोधित किया है (यह घटक अब और नहीं रखा गया है :-(), इसलिए मुझे इस प्रोजेक्ट की संरचना को मेरे प्रोजेक्ट की संरचना में जोड़ना होगा। इस बिंदु पर यदि मैं चेकआउट करूँगा रेपो मैं अगर वहाँ 3 पार्टी libs के कोड में परिवर्तन किया गया है की जाँच की जरूरत है। यदि libs का कोड बदल दिया गया था मैं घटकों पुनः संकलित करें और उन्हें पुनर्स्थापित करने के लिए की जरूरत है।

प्रश्न

  1. वहाँ घटकों को पुनर्स्थापित करने के कोई तरीका है डेल्फी 7 में कमांड लाइन से? क्या डी 7 के हार्डकोडिंग इंस्टॉलेशन पथ के बिना ऐसा करने का कोई तरीका है?
  2. प्रोजेक्ट पेड़ में आप तीसरे भाग घटकों के कोड को कैसे स्टोर करेंगे?
  3. मुझे bpl और dcu कहां रखना चाहिए जो घटकों के निर्माण के दौरान उत्पादित किया जाएगा। क्या मुझे उन्हें Project\build\output पर रखना चाहिए? या आउटपुट को किसी अन्य स्थान पर रखना बेहतर होगा (डेल्फी सेटिंग्स को ओवरराइड न करें), लेकिन प्रोजेक्ट कॉन्फ़िगरेशन में लाइब्रेरी पथ बदलें?

उत्तर

4

अद्यतन: कमांड लाइन से स्थापित नोटिस प्रश्न का अनुरोध करें।

आप वास्तव में कमांड लाइन से स्थापित नहीं कर सकते हैं, लेकिन ऐसा कुछ बनाना आसान होगा। आप DCC32.EXE का उपयोग कर संकुल संकलित कर सकते हैं।

घटकों की स्थापना रजिस्ट्री प्रविष्टियों द्वारा नियंत्रित की जाती है। रजिस्ट्री में स्थान डेल्फी के प्रत्येक संस्करण के लिए अलग है, लेकिन यह एक ही मूल पैटर्न का पालन करता है। उदाहरण:

डेल्फी 2007 HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Known Packages डेल्फी XE 'HKEY_CURRENT_USER \ Software \ Embarcadero \ बीडीएस \ 8.0 \ ज्ञात संकुल'

हम FinalBuilder का उपयोग कर, हम सब 3 पार्टी घटकों का निर्माण किया है के बाद इस अद्यतन करें। यह प्रत्येक डेवलपर को सिंक में रखना आसान बनाता है।

निर्देशिका संरचना के लिए, मैं संस्करण नियंत्रण के बारे में सोचता हूं और निम्नलिखित करता हूं।

रूट निर्देशिका ...

C:\dev\trunk\ 

यह मैं एक आसान प्रारूप में शाखाओं बनाने के लिए अनुमति देता है।

C:\dev\branch1\ 

वहां से मैं निम्न कार्य करें:

मैं \ बिन और \ DCU के लिए एक आम निर्देशिका का उपयोग के बाद से मैं जिनमें से कई डिजाइन समय लोड करने की आवश्यकता पैकेज विकास का एक बहुत कुछ है। यह डेल्फी को खुश रखने के लिए सिस्टम पथ में कई निर्देशिकाओं को जोड़ने से रोकता है।

\output\DelphiXE\Release\Bin 
\output\DelphiXE\Release\Dcu 
\output\DelphiXE\Debug\Bin 
\output\DelphiXE\Debug\Dcu 

प्रत्येक परियोजना के लिए, मैं यह कर, हालांकि अक्सर मैं एक ही निर्देशिका में एक से अधिक परियोजना प्लेस भरोसा करता है, तो:

\output\DelphiXE\Bin 
\output\DelphiXE\Dcu 

यह अगर जरूरत इस तरह होने के लिए बढ़ाया जा सकता है एक ही कोड के बहुमत पर।

\project\ (DPR/DPK Here) 
\project\source (if the project is small, if not I break it out further) 
\project\forms\ 
\project\classes\ 
\project\datamodules\ 
\project\resources\ 
\project\install\ (Install Scripts) 
etc... 

अंततः विभिन्न परियोजनाओं के लिए घटकों और कोड के लिए आम है।

\Commonlib\ (Directory for my code that common among projects) 
\Components\3rdPartyName\ 
\Components\3rdPartyName2\ 
\Components\3rdPartyName3\ 

मैं इसे इस तरह से करना तो मैं बस संस्करण नियंत्रण संशोधन संख्या का उपयोग करके अपने आवेदन के अपने संस्करण एक्स बना हर चीज पता है।

इस ऊपर करने के लिए मैं के लिए

सी एक वातावरण चर बनाने: \ देव \ ट्रंक \

तब मैं प्रणाली पुस्तकालय पथ में वातावरण चर का उपयोग करें। इस तरह:

%MYCODE%components\3rdParty1;%MYCODE%components\3rdParty2\ 

तब मैं वातावरण चर फिर से लॉन्च डेल्फी और सब कुछ कोड बेस के उस संस्करण का उपयोग कर बदल सकते हैं अगर मैं शाखाओं स्विच करने के लिए किया है।

+0

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

6
  1. तुम बस डेल्फी कमांडलाइन संकलक के साथ पैकेज संकलित करने के लिए किया है। यदि डेल्फी बिन पथ आपके PATH में है तो आपको इंस्टॉलशन पथ को हार्ड कोड करने की आवश्यकता नहीं है। यदि आपकी बिल्ड सिस्टम रजिस्ट्री से पढ़ने में सक्षम है तो आपको पथ मिल जाएगा। HKEY_LOCAL_MACHINE\SOFTWARE\CodeGear\BDS\6.0\RootDir (इस मामले में डेल्फी 200 9)।

  2. मैं प्रत्येक पैकेज के लिए उप-शाखाओं के साथ एक और शाखा components जोड़ दूंगा। उन्हें अपनी परियोजनाओं के साथ मिश्रण न करें।

  3. मेरे अनुभव से सबसे अच्छा अभ्यास उन्हें डेल्फी गंतव्य (जहां डेल्फी संस्करण पर निर्भर करता है) में रखना है।

+0

यदि आप 'घटकों' को submodules (Mercurial के मामले में subrepos) के रूप में जोड़ने की सलाह देते हैं तो यह उनके repos के अंदर कहीं भी 'डीसीयू' और 'बीपीएल 'स्टोर करना बेहतर होगा। यही है ना दूसरे मामले में कभी-कभी यह किसी अन्य ऐप के लिए बिल्ड प्रक्रिया को खराब कर देगा जो एक ही घटक का उपयोग करता है लेकिन एक और संस्करण। – Alik

+0

मेरा मतलब है कि यदि प्रत्येक 'घटक' 'घटक \ src' में रहता है और बिल्ड टूल' dcu' और 'bpl' को 'घटक \ build' में संकलित करेगा। इन डीसीयू और बीपीएल फ़ाइलों का उपयोग आईडीई (डिजाइन-टाइम) में घटक स्थापित करने के लिए किया जाएगा। इस बीच में मेरा 'project.dof' लाइब्रेरी पथ '.. \ घटक \ घटक \ src' का उपयोग करने के लिए संपादित किया जाएगा। प्रोजेक्ट टूल के निर्माण के दौरान इस निर्देशिका में देखेंगे और घटक की इकाइयां डीसीयू में बनाएंगे और उन्हें 'प्रोजेक्ट \ बिल्ड \ आउटपुट' पर स्टोर करेंगे। – Alik

+1

@ कॉन्स्टेंटिन मिखायलोव, "घटक स्थापित करें" पर आपका विचार थोड़ा सा हो सकता है। घटक पैकेज (डीसीपी) के रूप में स्थापित होते हैं, और स्थापित पैकेजों की केवल एक सूची है, सूची "प्रति परियोजना" नहीं है। जब आप कोई प्रोजेक्ट खोलते हैं तो घटक आईडीई में स्थापित नहीं होते हैं, और जब आप प्रोजेक्ट को बंद करते हैं और एक अन्य खोलते हैं तो वे बदले नहीं जाते हैं। वास्तव में डेल्फी आईडीई आपको एक साथ कई परियोजनाएं खोलने की अनुमति देता है! यही कारण है कि मेरे जवाब में मैं कहता हूं "कोई परियोजना तीसरे पक्ष के घटकों का मालिक नहीं है", इसलिए मैं उन्हें वास्तविक प्रोजेक्ट के साथ उसी निर्देशिका में संस्करण नियंत्रण के तहत रखने की अनुशंसा नहीं करता [...] –

3

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

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

3: प्रत्येक प्रोजेक्ट के लिए एक अलग आउटपुट निर्देशिका का उपयोग करना एक अच्छा विचार है, यह सशर्त संकलन का उपयोग करना अधिक आसान बनाता है। मैं डीबग और रिलीज के लिए अलग आउटपुट निर्देशिका का सुझाव दूंगा। लगभग तीसरे पक्ष बीपीएल के, वे परियोजना का भी हिस्सा नहीं हैं क्योंकि कोई भी परियोजना "उनका मालिक नहीं है"।

+0

मुझे संदेह है कि स्वचालित तरीके से घटकों को स्थापित करने के लिए कोई कानूनी बैरियर है। हम तृतीय पक्ष घटकों समेत सबकुछ पुनर्निर्माण के लिए फ़ाइनलबिल्डर का उपयोग करते हैं। फिर हमने उन्हें डेल्फी में स्थापित करने के लिए एक स्क्रिप्ट लिखी। सबसे बड़ा कारण तीसरे पक्ष के घटकों के संस्करणों को सिंक में रखा गया है 10 अलग-अलग डेवलपर्स अब वास्तव में आसान है ... एसवीएन अपडेट। फाइनलबिल्डर स्क्रिप्ट चलाएं। –

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