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

2

6

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?

Exordium answered 10/11, 2015 at 19:33 Comment(6)
I don't know the answer to this question, but if you don't get a good answer here on SO, you might try to cross post to the CDT community forum: eclipse.org/forums/index.php/f/80 alternatively if you are using DS5 is a commercial product, I would request help from ARM directly as the license fee includes support.Seringa
@JonahGraham - thanks. My experience with the Eclipse forums is not so great. Often, SO (and SE in general) are the best place for asking non-mainstream questions. I did use the ARM help a couple of times in the past (and in fact, their current release includes at least two bug fixes reported by me!). I thought this problem is not ARM specific that other CDT users may have encountered that. Anyway, it will probably be my next stop.Exordium
I agree with you on all points, just offering some second stops in case you don't get much response here. I hope ARM are willing to fix CDT bugs too though! PS, if you stick a MCVE on GitHub, I'd be happy to have a look (I have been doing CDT dev for quite a while, just don't immediately have an answer on your issue)Seringa
@JonahGraham - thanks. What's an MCVE?Exordium
MCVE: stackoverflow.com/help/mcveSeringa
@JonahGraham - Oh, I know this term as SSCCE: sscce.org Since this is a big project, I don't know how much work it will require to minimally reproduce this behaviour, but I may give it a try in the future.Exordium
B
6

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.

Barkeeper answered 20/11, 2015 at 0:27 Comment(4)
Thanks. First, a comment regarding the style. I wish people accept that sometime it is impossible or required not to make changes according to what they consider as best practice. Just take the situation for what it is. Specifically here, the header files in question are given from external sources and we have minimal to no flexibility in changing them. Then, I am the only one in team to use Eclipse for code dev, so the project is not changing due to my problem. Although your opinion on the matter is valuable and appreciated, maybe it should have been put at the end of the answer.Exordium
Second, no, the enums are identical. Eclipse regularly indexes the headers, but as I noted, I explicitly asked it not to, by unchecking that option. Third, excluding one of the headers is an idea which made me slap my head saying "why didn't I think about this weeks ago...". Although still a bug in Eclipse, the exclusion solved my problem, but I had to first disable and re-enable the indexer for this to take effect. You earned my bounty!Exordium
@Exordium , it seems that what you say is very often true, but not everyone accepts this. I am using CDT since a long time ago on large SW projects, and there is always a problem with the indexer not getting something properly. You just have to accept that and avoid spending too much time on having your project polished. CDT improves with time but it is a slow process. Though, other alternatives are missing the features that eclipse has.Barkeeper
Mark as derived did not work. Thanks for the hint though, I had to choose "C/C++ build" and check "Exclude resource from build" and this worked.Hildegard
A
3

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.
Amiamiable answered 19/11, 2015 at 19:0 Comment(1)
Thanks. First, it is oddly good to know that the problem is not particular to my case. It gives a hope that it will be fixed in the Eclipse project itself. Now, relating to your points: 1. Just to clarify, I did not disable the entire Indexer, just all the available options. 2. During the course pf development, I have to clean the project before doing every other build, because it is a Makefile project, to force the rebuild of libraries. I also tried explicit re-index numerous times. 3. Had to recreate the project due to other problems, but it did not change this behaviour. +1 for suggestingExordium

© 2022 - 2025 — McMap. All rights reserved.