[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Indexer Requirements for 3.0
|
I think the basic philosophy here is to "outsource" data gathering in
those cases where it can better be provided by the toolchain. As Alain
pointed out, this concept is already somewhat integrated in the CDT
framework (IPathEntry, Resolver, Binary Parser, etc). So maybe now it's
time to "take it to the next level." :)
So, in theory, what else could be a candidate for "outsourcing"?
- indexer
- search? (eg "grep" ;)
- refactoring
- code formatting
As an example I'm thinking of folks like SlickEdit etc - how
easy/seamless is it to hook in their own code management tools into CDT?
Chris
Treggiari, Leo wrote:
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
