एक्लिप्स सीडीटी इंडेक्स एक हेडर फ़ाइल क्यों है जो पथ में नहीं है?

Question

मैं कोड विकास और Makefile प्रोजेक्ट के डीबग के लिए एआरएम डीएस -5 v5.20.0 पैकेज से एक्लिप्स सीडीटी v4.3.2 का उपयोग कर रहा हूं।

मेकफ़ाइल वास्तव में मकेफाइल का पदानुक्रम है जो कमांड लाइन विकल्पों के आधार पर एकाधिक कॉन्फ़िगरेशन में एकाधिक लक्ष्य बनाता है।

प्रभावी स्थिर विश्लेषण की अनुमति देने के लिए, मैं प्रोजेक्ट की सेटिंग Paths and Symbols का उपयोग करता हूं ताकि इंडेक्सर को विभिन्न फाइलों को ढूंढने में मदद मिल सके और सही सशर्त रूप से संकलित कोड सेगमेंट को हाइलाइट किया जा सके।

हमारे प्रोजेक्ट में एक हेडर फ़ाइल है जो कोड पेड़ के कई मॉड्यूल में शामिल है। हालांकि, हेडर फाइल के दो वेरिएंट दो निर्माण विन्यास के साथ दो आसन्न निर्देशिका में मौजूद, सशर्त उपयोग के लिए कर रहे हैं:

My_Project 
    | 
    +-- Include_1 
    | | 
    | +-- header.h 
    | 
    +-- Include_2 
    | | 
    | +-- header.h 
    | 
    +-- Source 
    | | 
    | +-- module_1.c 
    | 
    +-- makefile 

दो वेरिएंट ज्यादातर समान हैं, लेकिन कुछ मतभेद होते हैं। इन शीर्षकों में कुछ मैक्रो परिभाषाएं और enumtypedef मिटा दी गई हैं। विशेष रूप से, निम्न नमूना भागों दोनों वेरिएंट में समान हैं:

// header.h 
#define SYMBOL 0x1 
typedef enum { 
    constant = 0x2 
} enum_t 

एक ठेठ कोड मॉड्यूल इन हेडर में से एक, makefile में कॉन्फ़िगरेशन के आधार पर शामिल है, और SYMBOL और constant के संदर्भ हैं।

paths and Symbols टैब में, मैंने पथ सूची में केवल My_Project/Include_1 जोड़ा, इसलिए सूचकांक को भ्रमित नहीं होना चाहिए। मैंने Window - Preferences ->C/C++ ->Indexer मेनू में वास्तव में Allow heuristic resolution of includes विकल्प अक्षम कर दिया है - वास्तव में, मैंने सभी इंडेक्सर विकल्पों को अक्षम कर दिया है)।

है, उन सभी के साथ

, जब मैं संपादक में module.c फ़ाइल को खोलने, constant के लिए संदर्भ लहरदार लाल रेखांकन के साथ चिह्नित कर रहे हैं, और एक Symbol 'constant' could not be resolved त्रुटि दर्शाई गई हैं। उसी समय, SYMBOL के सन्दर्भ में कोई त्रुटि संकेत नहीं है।

जब मैं हेडर फ़ाइलों में से किसी एक को header_x.h पर पुनर्नामित करता हूं तो त्रुटि संकेत गायब हो जाता है।

1. मुझे इन इंडेक्सर त्रुटि संकेत क्यों प्राप्त होते हैं?

2. मैं उन्हें कैसे समाप्त कर सकता हूं?

3. केवल enums और # परिभाषित क्यों नहीं?

Answer 1

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

1. संसाधनों का चयन करें, यह सही है तो गुण क्लिक करके ली गई चिह्नित करने और भीतर संसाधनों व्युत्पन्न की जांच , और फिर सूचकांक
2. पुनर्निर्माण संसाधन को छोड़कर एक विशेष फ़िल्टर लिखें।

एक और बात यह है कि आप जांच करने की आवश्यकता है कि आप पथ या अन्य वातावरण चर कि इंडेक्सर द्वारा विचार किया जा सकता में शामिल नहीं किया है गलती से हमलावर निर्देशिका है।

सीडीटी के साथ क्या गलत हो रहा है इसके अलावा ऐसा लगता है कि आप ऐसा कुछ कर रहे हैं जो सर्वोत्तम अभ्यास नहीं है। आपको अपने एनम को हेडर गार्ड के साथ एक अलग हेडर फ़ाइल में रखना चाहिए और आवश्यकतानुसार इसे शामिल करना चाहिए।

हालांकि यह एक ऐसी स्थिति है जो हो सकती है और आपके पास अलग-अलग कार्य करने की लक्जरी नहीं हो सकती है।

Answer 2

मैं दूसरे प्रश्न का उत्तर देने का प्रयास कर सकता हूं।

2. मैं उन्हें कैसे समाप्त कर सकता हूं?

मैं अपने विकास के लिए eclipse-cdt का उपयोग करें और मैं भी अवलोकन इस तरह भर में आ गए हैं। मैं हमेशा निम्नलिखित में से एक करता हूं और यह अक्सर मेरे लिए काम करता है।

1. डिफ़ॉल्ट eclipse-cdt अप्रयुक्त हेडर फ़ाइलों को सी ++/सी फ़ाइलों के रूप में सूचीबद्ध करेगा। यह चाहे आप उन्हें paths & symbols के तहत जोड़ते हैं, भले ही यह होगा। आप Project properties -> Indexer -> (un check) Index unused headers as C++/C files के माध्यम से उस व्यवहार को ओवरराइड कर सकते हैं। [हालांकि आपकी टिप्पणी के अनुसार, आप पहले से ही पूरे Indexer को अक्षम करने का प्रयास कर चुके हैं, मुझे लगता है कि यह आपके मामले में काम नहीं कर सकता है। फिर भी, मैं एक लायक कोशिश करता हूं]
2. कभी-कभी, Indexer जैसे ही आप कोड परिवर्तन/हेडर परिवर्तन करते हैं, उतना ही नहीं चलेंगे। यह मेमोरी बाधा और बड़ी परियोजना के साथ बड़ी परियोजना के कारण होता है, विशेष रूप से बड़ी फाइल वाले स्रोत फाइलें। ऐसे मामले में, आप cleaning the project आज़मा सकते हैं और परिवर्तन को देखने के लिए मजबूती से पुन: अनुक्रमण शुरू कर सकते हैं।
3. अंतिम विकल्प जो मैं अक्सर कोशिश करता हूं, परियोजना को बंद/हटा देना (परियोजना सामग्री नहीं) और अकेले प्रोजेक्ट को फिर से बनाना है (ताकि .cproject नया बनाया जाएगा)। इसने मेरे लिए ज्यादातर बार काम किया है, हालांकि इसके पीछे के आंतरिक विवरणों को नहीं जानते हैं। ये सभी परीक्षण-त्रुटि आधार पर पूरी तरह से प्रयास किए जाते हैं, पूरी तरह से अंत उपयोगकर्ता परिप्रेक्ष्य पर।