Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Indexer Requirements for 3.0 
I've created a buzilla to continue this discussion.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=82873

It's apparent that I didn't explain my suggestion well - hopefully the
bugzilla entry does a better job.

Leo

-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Alain Magloire
Sent: Friday, January 14, 2005 2:36 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Indexer Requirements for 3.0

> 
> Hi,
> 
> I have an idea to add to the discussion.
> 
> > Would it be better to index external headers separately from the
> normal=20
> > project indexing (this could apply to offline indexing as well).
> Maybe=20
> > 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?

A few.

The problem was raise a few times
but I do not think any PRs were created to address the problem.


The Managed Builder do not provide all the information to the CDT.
Some work been done by Sevoy: the managed builder can provide the
include paths.
But it knows much more, the source folders, the external libs, the
macros etc ...
The are ways to set this information(to integrate) to the CDT so the
parser/indexer/debugger and
other components can take advantage of it.

The point of entries are:

IPathEntry(in cdt.core):
	- setting of include paths
	- setting of source folders
	- setting of macro definitions
	- setting of external libraries/shared libraries

	Currently, the C/C++ project view will
		* show the include paths in a special
		  virtual folder "includes" so users could browse the
external headers.
		* show the external libraries, for example if one links
with libm.so etc ...
		  This allow browsing the symbols and in the future(we
should be able to "attach"
		  source code or participate in providing the indexer
new symbols)

	The Scanner Auto discovery mechanism takes advantage of this and
provide the information
	to the rest of CDT this way.

Resolver Model:
	- file(names/extensions) to language mapping.

	This is incomplete since we need to hookup to the Eclipse
ContenTypeManager,
	UI is in place for this, see property and preference page,
whether it remains
	will depend on the state of the ContentType in 3.1

Binary Parser:
	- Core/UI is already in place for this.


> Is there a "generic" concept here that could be used across CDT?  For

I'm not sure if this is what you have in mind when you wrote "generic
concept",
If you have other ideas or simply dislike what is already in place, lets
make a PR, I would like to tie some of this for 3.0 and need to make
some plan items.



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

Back to the top