Why is the Eclipse CDT indexing a header file that is not in the path?

Question

I am using Eclipse CDT v4.3.2 from the ARM DS-5 v5.20.0 package to develop code and debug the Makefile project.

The make file is actually a hierarchy of mkefiles that create multiple targets in multiple configurations based on command line options.

To provide effective static analysis, I use the settings for the Paths and Symbols project to help Indexer find the various include files and highlight the necessary conditionally compiled code segments.

Our project contains a header file, which is included in many modules in the code tree. However, two variants of the header file are present in two neighboring directories, for conditional use with two assembly configurations:

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

The two options are mostly similar, but contain some differences. These headers contain several macro definitions and an enum erated typedef . In particular, the following parts of the samples are identical in both versions:

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

A typical code module includes one of these headers, depending on the configuration in the makefile, and contains references to SYMBOL and constant .

On the Paths and Symbols tab, I added only the My_Project/Include_1 list to the path list, so the My_Project/Include_1 should not be confused. I also turned off the Allow heuristic resolution of includes parameter in the menu Window → Preferences → C/C++ → Indexer (in fact, I turned off all the parameters of the indexer).

With all this, when I open the module.c file in the editor, the links to constant are marked with a wavy red underline and the Symbol 'constant' could not be resolved error is indicated. At the same time, references to SYMBOL have no error indications.

When I rename one of the header files to header_x.h , then the error indication will disappear.

1. Why am I getting these indexer readings?

2. How can I fix them?

3. Why only enumerations, not # define-s?

Answer 1

Eclipse CDT indexer in my experience will index the source files in the project directory, whether you like it or not. There is only one way to avoid your situation: to exclude them from the project, which can be done in my opinion in two ways:

• Select the resources, mark them as derivatives by right-clicking, then properties and as part of the resource check, and then rebuild the index
• Record an exclusive filter that excludes a resource.

Another thing you need to check is that you did not accidentally add the offending directory to PATH or other environment variables that could be taken into account by the index.

Besides what happens with CDT, it seems like you are doing something that is not best practice. You must put your listing in a separate header file with header protection and include it as needed.

However, this is a situation that can happen, and you may not have the luxury to act differently.

Answer 2

I can try to answer the second question.

2. How can I fix them?

I use eclipse-cdt for my development, and I also came across a similar observation. I always do one of the following, and it often worked for me.

• By default, eclipse-cdt will index unused header files as C ++ / C files. This would be regardless of whether you add them under paths & symbols . You can override this behavior through Project properties -> Indexer -> (un check) Index unused headers as C++ / C files . [However, based on your comment, you have already tried to disable the entire Indexer , I think this may not work in your case. However, I would say worth a try]
• Sometimes the Indexer does not start as soon as you perform a code change / header change. This is due to memory limitations and a large project with a large amount of source file, especially source files containing large LOC. In this case, you can try cleaning the project and force re-indexing to see the change.
• The last parameter that I often try to do is to close / delete the project (and not the contents of the project) and re-create the project myself (so that .cproject will only be created recently). It worked most of the time for me, but I don’t know the internal details. All of them are considered mainly on the basis of trial / error, exclusively for the perspective of the end user.