2009-02-27 10 views
6

मेरे पास लगभग 10 निर्देशिकाओं में लगभग 500 फाइलों का स्रोत कोड है। मुझे निर्देशिका संरचना को दोबारा करने की आवश्यकता है - इसमें निर्देशिका पदानुक्रम बदलना या कुछ निर्देशिकाओं का नाम बदलना शामिल है।सी ++ निर्देशिका पुनर्गठन

मैं svn संस्करण नियंत्रण का उपयोग कर रहा हूं। रिफैक्टर करने के दो तरीके हैं: एक एसवीएन इतिहास को संरक्षित करना (svn move कमांड का उपयोग करना) और दूसरे को संरक्षित किए बिना। मुझे लगता है कि एसवीएन इतिहास को संरक्षित करना पुन: उपयोग करना ग्रहण सीडीटी और एसवीएन प्लगइन का उपयोग करना बहुत आसान है (दृश्य स्टूडियो निर्देशिका पुनर्गठन के लिए बिल्कुल फिट नहीं है)।

लेकिन अभी कोड जारी नहीं होने के बाद, हमारे पास इतिहास को संरक्षित करने का विकल्प नहीं है।

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

+0

उम्मीद है कि आपका कोडबेस स्रोत पेड़ की जड़ से #sclude "शायद/कुछ/stuff.h" के आधार पर पथ का उपयोग करता है और सापेक्ष पथ जैसे #include "../../../stuff.h"। – bk1e

+0

@ बीके 1e, हाँ यह करता है। –

उत्तर

3

यदि आपको ऐसा करने के लिए #include एस को फिर से लिखना है, तो आपने यह गलत किया है। चारों स्तरों को गहराई से और केवल आर्किटेक्चर या ओएस निर्भरताओं (जैसे sys/types.h) को व्यवस्थित करने के लिए केवल दूसरे स्तर का उपयोग करके, एक बहुत ही सरल निर्देशिका संरचना का उपयोग करने के लिए अपने सभी #includes को बदलें।

फिर -I का उपयोग करने के लिए अपनी मेक फाइलें बदलें पथ शामिल करें।

वोला। इसके लिए आपको फिर से कोड को हैक करना पड़ेगा, और कुछ गलत होने पर संकलन तुरंत उड़ाएंगे।

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

ओह, और आपके पास अच्छे परीक्षण हैं, और आप इसे जारी करने के साथ सही नहीं कर रहे हैं, है ना?

+0

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

+0

"फिर अपनी मेक फाइलों को उपयोग करने के लिए बदलें- मैं पथ शामिल करता हूं" - इसमें बहुत गहराई नहीं होनी चाहिए लेकिन मैं जटिल नहीं करना चाहूंगा- मैं पथ। निर्देशिका के लिए "facades" प्रदान करने वाली प्रत्येक निर्देशिका के शीर्ष स्तर पर रैपर होना चाहिए। बूस्ट काम करता है जिस तरह से; इसका उपयोग केवल एक निर्देशिका सहित जरूरी है। –

+0

मुझे नहीं लगता कि यह बहुत महत्वपूर्ण है कि आप इसे कैसे करते हैं, लेकिन रैपर फ़ाइल का मतलब है कि निर्माण को समझने के लिए आपको कोड पढ़ना होगा; मैं मेकफ़ाइल में सबकुछ ढूंढने में सक्षम हूं। –

2

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

इतिहास निम्न उपयोगकर्ताओं के लिए बनाया जा सकता है संरक्षण के खिलाफ तर्क:

  • अपने कोड शर्मनाक बातें, अश्लील और डेवलपर्स के बीच लड़ाई की तरह
  • आप के इतिहास के लिए प्रतिबद्ध के बारे में परवाह नहीं है हो सकता है आपका कोड, क्योंकि यह भविष्य में बदलने या बनाए रखने के लिए नहीं जा रहा है

मैंने पिछले कोड की तरह हमारे कोड बेस पर कुछ निर्देशिका रीफैक्टरिंग की है। यदि आपका कोड शुरुआत में उचित रूप से संरचित है, तो आप अपनी पसंद की भाषा में लिखी गई स्क्रिप्ट का उपयोग करके लगभग 75-90% काम कर सकते हैं (मैंने पर्ल का उपयोग किया था)। मेरे मामले में, हम नामों के आधार पर नेस्टेड निर्देशिकाओं की एक श्रृंखला में, फ़ाइलों को एक बड़ी निर्देशिका में ले जा रहे थे। तो, एक फ़ाइल जिसने कक्षा प्रोटोकॉल घोषित किया :: serialization :: SerializerBase src/प्रोटोकॉल/क्रमबद्धता/SerializerBase में स्थित था। पुराने नाम से नए नाम पर मैपिंग छोटा था, ताकि पेड़ में प्रत्येक स्रोत फ़ाइल में # अंतर्निहित खोज और प्रतिस्थापन करना छोटा हो, हालांकि यह एक बड़ा बदलाव था।कुछ अजीब किनारे के मामले थे जिन्हें हमें हाथ से ठीक करना पड़ा, लेकिन हाथ से सबकुछ करने या अपने स्वयं के सी ++ पार्सर लिखने से कहीं ज्यादा बेहतर लग रहा था।

2

svn चाल करने के लिए एक खोल स्क्रिप्ट को हैक करना छोटा है। tcsh में फ़ोरैच एफ ($ FILES) ... फ़ाइलों का एक सेट समायोजित करने के लिए समाप्त करें। पर्ल & पायथन बेहतर उपयोगिता प्रदान करते हैं।

यह वास्तव में इतिहास को बचाने के लायक है। विशेष रूप से जब कुछ विदेशी बग को ट्रैक करने की कोशिश कर रहा है। जो लोग इतिहास से सीख नहीं है यह, या कुछ इस तरह के जंक दोहराने के लिए अभिशप्त कर रहे हैं ...

सभी फाइलों को बदलने के लिए के रूप में ... वहाँ एक ऐसी ही सवाल पर सिर्फ दूसरे दिन समाप्त हो गया था:

https://stackoverflow.com/questions/573430/ c-include-header-path-change-windows-to-linux/573531#573531

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