We do something similar in our product,
but what we use is what’s call a Path Container in CDT, this path type is
a single raw path, which when the paths are resolved by the path manager can
turn into a set of more the one path, which is retrieve via extension point.
What you do is create a container path entry whose path is of the form “container.id</optional
string which you container could use>”, and set that as a raw path
entry. Then, when the paths are resolved, by the path manager it will call the
contributing container whose id in the extension point matches the “container.id”
of the path. The API for the extension is through an abstract class call PathEntryContainerInitializer,
when the initialize methods is call your container initializer creates a ICPathContainerEntry
(you implement) and set this on the project via CoreModel.setPathEntryContainer()
Then the path manager will query this interface whenever is needs the paths
that your container is contributing. Some example code in CDT which uses
this is the path Discovery mechanism, it should be enough to guide you through
the details which I may have missed (like the UI side when editing a container
entry), if not just ask.
Dave Inglis
QNX Software Systems.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of cebarne2@xxxxxxxxxxxxxxxxxxx
Sent: Friday, February 03, 2006
9:33 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] CDT Include
PathEntry Management
Good morning (and good evening to some),
We've
developed a wrapper around the Standard Make CDT project that generates company
standard makefiles for our developers. As well as generating makefiles,
it also auto-populates the CDT project properties including error parsers,
binary parsers, make command, include paths, etc.
Unfortunately,
our tool over-writes the CDT include paths whenever the user makes a change to
our wrapper's settings. In many cases, it would be desirable for the user
to add CDT include paths manually and expect them not to be removed by our
automated tool. Our automated tool simply clears the existing includes
and populates the list with its own.
Is
there a way to define an include PathEntry subtype that still works as an
include path for the CDT, but can easily be identified by our tool as
removable.
Currently
we use:
IIncludeEntry
include = CoreModel.newIncludeEntry(...);
ICProject.setRawPathEntries({include...});
Is
it possible, or allowed, to somehow implement IIncludeEntry as our own include
type... but still be compatible with the CDT? And, later, only remove
those include paths that are based on our own implementation? Scanning
the CDT code, I see the implementation of IIncludeEntry, IncludeEntry, is
internal and extends an internal APathEntry.
Would
it be safe to simply extend IncludeEntry to give it a new type name (no actual
changes to the methods) even though it is internal?
public
class RCIncludeEntry extends IncludeEntry { }
Then,
we can add include paths to the CDT properties using this type, and
subsequently manage only our type of include entry, leaving the base CDT stuff
alone.
Thanks
for your thoughts,
Chad
Barnes
Rockwell
Collins, Inc.
|
