हमारी टीम कई वर्षों से डेल्फी 6 का उपयोग कर रही थी, फिर 2006 साल पहले डेल्फी में स्विच कर दी गई थी। दोनों संस्करणों के साथ हमारे पास निम्न समस्या है: अक्सर संकलक एक इकाई के बारे में शिकायत करता है जिसे माना जाता है कि का उपयोग किया जाता है। यह इकाई एक 40k एलओसी इकाई है जो लगभग 1 मिलियन एलओसी (तीसरी पार्टी शामिल) वाली परियोजना के मूल में है।गलत परिपत्र संदर्भ त्रुटि
त्रुटि संदेश गलत है: प्रोजेक्ट पर एक पूर्ण निर्माण हमेशा काम करता है। दुर्भाग्यवश, त्रुटि संदेश हमें नहीं बताता है कि अनुमानित परिपत्र संदर्भ, केवल उस इकाई का नाम है। कभी-कभी यह भी होता है कि वैध त्रुटि संदेशों को 2-4 बार सूचीबद्ध किया जाता है जब तक कि परिपत्र संदर्भ समस्या "नहीं" होती है। स्पष्ट रूप से संकलक यहां एक सर्कल में चल रहा है। उस परियोजना के आकार के कारण मैन्युअल रूप से समस्या को ढूंढना मुश्किल है। इसलिए मैंने एक उपकरण बनाया जो साबित करता है कि वास्तव में कोई परिपत्र संदर्भ नहीं है (उपकरण इकाइयों का निर्देशित निर्भरता ग्राफ बनाता है और उस ग्राफ में समेकन घटकों को निर्धारित करता है - अगर मैं जानबूझकर कुछ डालता हूं तो कोई भी नहीं है)।
यह न केवल एफ 9 संकलन को प्रभावित करता है बल्कि कोड समापन/अंतर्दृष्टि भी जो अधिकतर समय काम नहीं कर रहा है। कभी-कभी यह काम करता है जब मैं दूसरी बार ctrl-space दबाता हूं ...
कोई विचार हम समस्या को अलग या कैसे ठीक कर सकते हैं? ध्यान दें कि 40k LOC इकाई को छोटे से विभाजित करना बहुत मुश्किल होगा क्योंकि इसमें लगभग 15 बड़े वर्ग होते हैं जो इंटरफ़ेस अनुभाग में एक दूसरे पर निर्भर करते हैं (मुझे पता है कि यह बुरा है लेकिन वैसे भी काम करना चाहिए)।
अद्यतन
हम लगातार पुनर्रचना कर रहे हैं, लेकिन इस refactor करने के लिए क्योंकि सब कुछ सब कुछ पर निर्भर करता है, लगभग एक कठिन इकाई है। इंटरफेस के माध्यम से इसे पाने की कोशिश कर रहे हैं, लेकिन हम 100 वर्गों और गुणों के साथ कुछ कक्षाओं के बारे में बात कर रहे हैं। और यह धीमा होगा।
डी 200 9 में अपग्रेड करना सड़क के नीचे एक विकल्प हो सकता है लेकिन अभी हम डी 2006 (यूनिकोड सामान और मूल्य टैग यहां दो स्टॉपर्स हैं) के साथ फंस गए हैं। प्रश्न वैसे भी है अगर इससे मदद मिलेगी क्योंकि समस्या कम से कम डी 6 के बाद से है।
उपयोग खंडों को ट्रिम करने के बारे में, हम अक्सर इसे इकरस के साथ कर रहे हैं। लेकिन इससे अब तक मदद नहीं मिली। हम अब इंटरफ़ेस अनुभाग में 90 कस्टम इकाइयां हैं। हालांकि, एक वास्तविक परिपत्र संदर्भ के साथ समस्या किसी भी इकाई में हो सकती है। डीपीआर में सभी इकाइयों को जोड़ने की भी कोशिश की।
परियोजना अन्य परियोजनाओं के साथ बहुत सारे कोड साझा करती है, और कुछ आईएफडीईएफ हैं। हालांकि, परिभाषा परियोजना विकल्पों में स्थापित नहीं हैं लेकिन एक आम फ़ाइल के माध्यम से शामिल हैं। इसलिए सभी मॉड्यूल को एक ही परिभाषा देखना चाहिए। साथ ही, किसी अन्य प्रोजेक्ट पर स्विच किए बिना पूर्ण पुनर्निर्माण के तुरंत बाद समस्या फिर से शुरू हो जाती है।
ठीक है, हम सभी परियोजनाओं (और अधिक) पर पूर्ण बिल्ड स्क्रिप्ट में dcc32 का उपयोग करते हैं। मैं वास्तव में आईडीई संकलन के प्रतिस्थापन के रूप में इसका उपयोग करने की उम्मीद नहीं कर रहा हूं; यह कोड अंतर्दृष्टि के साथ मदद नहीं करेगा और कौन जानता है कि इसके लिए कितनी बार आवश्यकता होगी। लेकिन शायद यह समस्या का निदान करने का एक तरीका है? आदर्श रूप से dcc32 incremental एक ही समस्या में चला जाएगा और इसका आउटपुट कुछ विचारों को ट्रिगर करता है ... –
हां, यह वही है जो मैं सुझाव देने की कोशिश कर रहा था, शायद मैं इसे स्पष्ट करने में सफल नहीं हुआ था :-(क्षमा करें। Dcc32 का उपयोग करना चाहिए देखें कि कौन सी फाइलें कई बार संकलित की जाती हैं, और जिसके बाद यह फ़ाइल बंद हो जाती है। जब तक आईडीई कंपाइलर और डीसीसी 32 वास्तव में अलग नहीं होते हैं, लेकिन यह मुझे नहीं लगता। – mghie