Eclipse Community Forums: C / C++ IDE (CDT) » How to get indexer parsing subdirectory of include path properly ?

Home » Language IDEs » C / C++ IDE (CDT) » How to get indexer parsing subdirectory of include path properly ?

How to get indexer parsing subdirectory of include path properly ? [message #162174]

Sun, 22 January 2006 14:47

Eclipse User

Originally posted by: christof.frey.freesurf.ch

Hi,

first of all thanks the Eclipse team for this great product! (I use it
as cross-dev. environment)

Have read all the issues about the indexer in this group but did not
find a hint to my problem (?)
It appears that the indexer does not handle subdirectories in include
paths properly:

#include <c++/Motor.H> // indexer does not handle this directory
#include <c++/Sound.H> // not handled either
#include <conio.h> // works well
#include <unistd.h> // works well either

Above are system directories. Motor.H and Sound.H can be found
One level higher up than conio.h and unistd.h.
The subdirectory has header files only (inline C++ classes).
The parent has standard c header files.

What works:
Project builds and executable runs
browsing to standard c function declaration in libraries works

Problem:
browsing to C++ class declarations does NOT work

I am using:
- Eclipse 3.2.0
- CDT 3.0.1
- gcc (2.95.2) for Hitachi H8
- Standard Make

A work around is to copy the the folder with the c++ headers to the
project directory,
then the indexer finds all the reverences.

Have tried with both GCC per project / per file discovery with the same
effect. Also
adding all the include paths manually did not help.

Any help much appreciated
Chris

Re: How to get indexer parsing subdirectory of include path properly ? [message #162522 is a reply to message #162174]

Thu, 26 January 2006 05:09

Eclipse User

Hi Christof,

are you using a standard or managed make project?
When you expand the project's tree in the C/C++ view there should the an
"Include" container containing all the paths that are known to the indexer.
If the path to Motor.H and Sound.H is not there then you must make the path
known in the project's properties.

Besides I am not sure whether the upper case .H makes the indexer ignore the
file.

Does this help you?

Norbert Ploett

Re: How to get indexer parsing subdirectory of include path properly ? [message #162594 is a reply to message #162522]

Thu, 26 January 2006 13:41

Eclipse User

Originally posted by: christof.frey.freesurf.ch

Hi Norbert,

I use standard make.
When when I expand the "Includes" container the paths seem to be
correct, unless the
the indexer does not handle them recursively. (I mean the correct
indexed files are in the
container " ../include" whereas the not indexed headers are in
"../include/c++")
In the expanded container "../include/c++" I find the files Motor.H and
Sound.H

I noticed that the correct containers ("Includes") are generated
automatically when running
make.
I changed also the "Discovery Options" of "Automated discovery of paths
and symbols" from
"GCC per project scanner info profile" to "GCC per file scanner info
profile" without success.
Both options for Discovery profile are ticked and I added the correct
path for the GCC I use.

Upper case *.H affecting indexer:
Here I have some doubts since the files are indexed properly when I copy
them into the
project directory.

Thanks, but did not help so far.

Does anybode from the Eclipse developper team has an idea what is may
going wrong here ?

Thanks,
Christof

Norbert Ploett wrote:
> Hi Christof,
>
> are you using a standard or managed make project?
> When you expand the project's tree in the C/C++ view there should the an
> "Include" container containing all the paths that are known to the indexer.
> If the path to Motor.H and Sound.H is not there then you must make the path
> known in the project's properties.
>
> Besides I am not sure whether the upper case .H makes the indexer ignore the
> file.
>
> Does this help you?
>
>
> Norbert Ploett
>
>

Re: How to get indexer parsing subdirectory of include path properly ? [message #162601 is a reply to message #162594]

Thu, 26 January 2006 14:05

Eclipse User

Originally posted by: christof.frey.freesurf.ch

sorry about my last sentence, I guess you are part of the team Norbert...

Christof wrote:
> Hi Norbert,
>
> I use standard make.
> When when I expand the "Includes" container the paths seem to be
> correct, unless the
> the indexer does not handle them recursively. (I mean the correct
> indexed files are in the
> container " ../include" whereas the not indexed headers are in
> "../include/c++")
> In the expanded container "../include/c++" I find the files Motor.H and
> Sound.H
>
> I noticed that the correct containers ("Includes") are generated
> automatically when running
> make.
> I changed also the "Discovery Options" of "Automated discovery of paths
> and symbols" from
> "GCC per project scanner info profile" to "GCC per file scanner info
> profile" without success.
> Both options for Discovery profile are ticked and I added the correct
> path for the GCC I use.
>
> Upper case *.H affecting indexer:
> Here I have some doubts since the files are indexed properly when I copy
> them into the
> project directory.
>
> Thanks, but did not help so far.
>
> Does anybode from the Eclipse developper team has an idea what is may
> going wrong here ?
>
> Thanks,
> Christof
>
> Norbert Ploett wrote:
>
>> Hi Christof,
>>
>> are you using a standard or managed make project?
>> When you expand the project's tree in the C/C++ view there should the
>> an "Include" container containing all the paths that are known to the
>> indexer. If the path to Motor.H and Sound.H is not there then you must
>> make the path known in the project's properties.
>>
>> Besides I am not sure whether the upper case .H makes the indexer
>> ignore the file.
>>
>> Does this help you?
>>
>>
>> Norbert Ploett
>>
>>

Re: How to get indexer parsing subdirectory of include path properly ? [message #162624 is a reply to message #162594]

Fri, 27 January 2006 02:18

Eclipse User

Christof,

> I use standard make.
> the indexer does not handle them recursively. (I mean the correct

I do not think that paths are handled recursively. For a standard make
project try to

- open Project Properties,
- select C/C++ Include Paths & Symbols,
- click on Add External Include Path
- enter ../include/c++
- and OK all the dialogs.

Better now?

Norbert

Re: How to get indexer parsing subdirectory of include path properly ? [message #162686 is a reply to message #162624]

Fri, 27 January 2006 13:25

Eclipse User

Originally posted by: christof.frey.freesurf.ch

Norbert,

although the path now appears as a separate element of the container I
still get the message
"No declaration was found" in the status bar. Have made sure that the
indexer parses again
by means of opening / closing the project w/o success.

Christof
Norbert Ploett wrote:
> Christof,
>
>
>>I use standard make.
>>the indexer does not handle them recursively. (I mean the correct
>
>
> I do not think that paths are handled recursively. For a standard make
> project try to
>
> - open Project Properties,
> - select C/C++ Include Paths & Symbols,
> - click on Add External Include Path
> - enter ../include/c++
> - and OK all the dialogs.
>
> Better now?
>
>
> Norbert
>
>

Re: How to get indexer parsing subdirectory of include path properly ? [message #162716 is a reply to message #162686]

Mon, 30 January 2006 03:53

Eclipse User

Christof,

so the root of your problem was that "open declaration" does not work. I
sort of overlooked it when plunging into the include file setup stuff. "Open
declaration" is an unreliable feature in my experience and in that of other
colleagues of mine. And then there are again others who report that it works
fine. I do not yet have a clue why it fails in some setups. See also my
https://bugs.eclipse.org/bugs/show_bug.cgi?id=109506

Sorry, but I have no more ideas now.
Anybody?

Norbert

Previous Topic:	wxGTK integration in Eclipse 3.1.1 problems!
Next Topic:	Guide/Gymnast eclipse tools

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 08 15:44:43 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter