Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » Indexer workaround for partial includes
icon3.gif  Indexer workaround for partial includes [message #901906] Wed, 15 August 2012 00:32 Go to next message
Jay Dolan is currently offline Jay Dolan
Messages: 2
Registered: August 2012
Junior Member
Hi CDT community,

When I upgraded from Helios to Juno, my CDT project suddenly had thousands of unresolved symbols. After a lot of unsuccessful experimentation with the Builder, Indexer, and the Preprocessor settings in Eclipse, Google finally turned up this on the CDT wiki:

http://wiki.eclipse.org/CDT/designs/Overview_of_Parsing#Indexing

Quote:
When a header file is included in a source file it is subject to any macros that have been defined at that point. Some library headers use macros in conjunction with preprocessor conditionals (#ifdefs) to partially include a header file. Sometimes such a header file is included more than once in a project, if the macros that the header depends on are different each time the header is included then different parts of the header may be included in different source files. Neither indexer will be accurate in this scenario because it will only index the header the first time it is encountered.


Bummer! The old full indexer worked beautifully for my code, which does a lot of partial includes for limiting visibility; e.g.:

foo.h
#ifndef __FOO_H__
#define __FOO__H__

void foo_public(void);

#ifdef __FOO_LOCAL_H__
void foo_private(void);
#endif

#endif


foo_local.h
#ifndef __FOO_LOCAL_H__
#define __FOO_LOCAL_H__

#include "foo.h"

#endif


Code including foo_local.h would suffer from unresolved symbols for everything conditionalized in foo.h, which is clearly incorrect, but a consequence of the new "fast" (*cough* lazy) indexer Wink

My workaround is to provide an __ECLIPSE__ symbol via the Paths and Symbols settings, and then update all of my headers like so:

foo.h
#ifndef __FOO_H__
#define __FOO__H__

void foo_public(void);

#if defined(__FOO_LOCAL_H__) || defined(__ECLIPSE__)
void foo_private(void);
#endif

#endif


The only significant shortcoming of this approach is that Eclipse will actually resolve *more* symbols than what are really available to you, making the code assist a little busier than it should be. But it's certainly better than having thousands of unresolved symbols in your code!

FYI, my project is an open source 3D video game, Quake2world [quake2world.net]

And you can checkout the source code here if you'd like to see how I set the project files up in Eclipse/CDT:
svn://quake2world.net/quake2world/trunk

Feedback welcome! If there's a better way to do this, or if the old full indexer is scheduled to make a return, I'm all ears!
Re: Indexer workaround for partial includes [message #902160 is a reply to message #901906] Thu, 16 August 2012 07:36 Go to previous messageGo to next message
Harald    is currently offline Harald
Messages: 34
Registered: July 2009
Member
Jay Dolan wrote on Tue, 14 August 2012 20:32
Hi CDT community,

My workaround is to provide an __ECLIPSE__ symbol via the Paths and Symbols settings, and then update all of my headers like so:



You could create a build configuration only for the indexer. In that you can define all defines that are needed to parse the includes complete. In your example __FOO_LOCAL_H__. The next step is to set this configuration for your parser. Unfortunately this setting is not stored correctly in the project settings (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=205299) Sad

--Harald
Re: Indexer workaround for partial includes [message #902654 is a reply to message #902160] Sun, 19 August 2012 02:28 Go to previous message
Jay Dolan is currently offline Jay Dolan
Messages: 2
Registered: August 2012
Junior Member
Thanks Harald. I tried this approach today and didn't have much luck. I will give it another shot with fresh eyes this week.
Previous Topic:Prebuilt C/C++ Library in an Android App
Next Topic:Long argument list
Goto Forum:
  


Current Time: Sat Oct 25 17:05:19 GMT 2014

Powered by FUDForum. Page generated in 0.01956 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software