RE: [cdt-dev] Indexer Requirements for 3.0

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

Hi,

I have an idea to add to the discussion.

> Would it be better to index external headers separately from the
normal 
> project indexing (this could apply to offline indexing as well).
Maybe 
> this header-only index could then be shared across a workspace?

The Managed Build System uses information provided by a "tool-chain
integrator" in the plugin.xml file.  Right now, this is primarily the
definitions of tools and tool options.

Is there a "generic" concept here that could be used across CDT?  For
example, could a GNU integration provide CDT with a pre-generated index
for its header files?  Could a GNU integration provide other information
needed by the scanner (e.g. the list of built-in compiler macros, the
list of environment variables (bin, lib, include, etc..) needed for a
build).  I'm sure that there are other pieces of per-tool-chain,
CDT-wide, information that could be provided by the person who wants to
integrate the tool-chain into CDT, rather than by every user.  An
example I was thinking about last night is having a customizable file
extension to tool mapping.  CDT already has this for C/C++ files, but
what if I want to provide support in my tool-chain for lex & yacc and a
user uses a custom file extension for their yacc source files?

Comments?
Leo


-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Chris Wiebe
Sent: Friday, January 14, 2005 1:25 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Indexer Requirements for 3.0

Douglas Schaefer wrote:
> There are a couple of problems with parsing all header files on the 
> include path:
> 
> 1) Scalability. The number of files on an include path is somewhat 
> unbounded. Parsing is expensive and we would need to control how much
we 
> do.

Would it be better to index external headers separately from the normal 
project indexing (this could apply to offline indexing as well).  Maybe 
this header-only index could then be shared across a workspace?

> 2) Correctness. Parsing a header file on it's own does not always
work. 
> And in the world of Windows development and precompiled headers, it is

> generally guaranteed not to work. If the user doesn't require full 
> accuracy, then it should be possible to do a ctags kind of thing to
get a 
> general hint at what is in the header files. Or if the user promises
to 
> ensure that all header files will behave like translation units, then
they 
> could use the parser based indexer.

I think 100% correctness is probably near impossible to achieve, nor is 
it required.  The high-runner case seems to be things like type 
navigation (eg open type, type hierarchy), class wizard (eg let me pick 
a base class from all known classes) and code completion (eg add
include).

> All this points back to the user configurability of the indexer to
make 
> sure we are doing the right thing for their environment.

Doing the right thing - it's not as easy as it sounds... ;)

Chris
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev