CODEWITHSUNDEEP
cincludeeclipse-cdtindexer
ysap
ysap

Reputation: 8115

Why does Eclipse CDT index a header file that's not in the path?

I am using Eclipse CDT v4.3.2 from the ARM DS-5 v5.20.0 package for code development and debug of a Makefile project.

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

In order to allow effective static analysis, I use the project's setting Paths and Symbols to help the Indexer find the various include files and to highlight the right conditionally compiled code segments.

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

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

The two variants are mostly similar, but contain some differences. These headers contain a few macro definitions and an enumerated typedef. Specifically, the following sample parts are identical in both variants:

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

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

In the paths and Symbols tab, I added only My_Project/Include_1 to the paths list, so the indexer should not get confused. I also disabled the Allow heuristic resolution of includes option in the Window->Preferences->C/C++->Indexer menu (in fact, I disabled all Indexer options).

With all of that, when I open the module.c file in the editor, the references to constant are marked with the wavy red underline, and a Symbol 'constant' could not be resolved error is indicated. At the same time, references to SYMBOL don't have an error indication.

When I rename one of the header files to header_x.h then the error indication disappears.

1. Why do I get these Indexer error indications?

2. How can I eliminate them?

3. Why only the enums and not the #define-s?

Upvotes: 6

Views: 2798

Answers (2)

g24l
g24l

Reputation: 3125

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

  1. Select the resources, mark it derived by right clicking then properties and within resources check derived , and then rebuild the index
  2. Write an exclusive filter that excludes the resource.

Another thing that you need to check is that you have not added accidentally the offending directory in PATH or other environment variables that may be considered by the indexer.

Apart from what is going wrong with CDT it seems that you are doing something that is not a best practice. You should put your enum in a separate header file with header guards and include that as needed.

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

Upvotes: 6

kspviswa
kspviswa

Reputation: 657

I can try to answer the second question.

  1. How can I eliminate them?

I use eclipse-cdt for my development and I have also come across this kind of observation. I always do one of the following and it often worked for me.

  1. Be default eclipse-cdt will index unused header files as C++ / C files. This would be irrespective of whether you add them under paths & symbols . You can override that behavior via Project properties -> Indexer -> (un check) Index unused headers as C++ / C files. [However going by your comment that, you had already tried disabling the entire Indexer, I guess this might not work in your case. Nevertheless, I would say a worth try]
  2. Sometimes, Indexer wouldn't run as soon you do a code change / header change. This happens due to memory constraint and big project with lot of source file, specifically source files containing large LOC. In such case, You can try cleaning the project and forcefully start the re-indexing to see the change.
  3. The last option that I often try would be, is to close / delete the project ( not the project content ) and re-create the project alone ( so that the .cproject will be created newly ). This has worked for most of the times for me, however don't know the inner details behind it. All these are tried mostly on trial / error basis, purely on the end-user perspective.

Upvotes: 3

Related Questions