[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Towards a more language neutral CDT
|
On Mar 9, 2005, at 10:44 AM, Craig Rasmussen wrote:
The rationale behind having a singleton (like the ResourcesPlugin)
for our Core
and UI is that we had thought that there wasn't a need for this to be
extensible.
What would make more sense (to me, at least) is that perhaps all of
the static
registries that are assuming that everything is CNature/CPPNature
should take an
additional parameter (a nature, perhaps) that would serve as a key
into a table of sorts.
Greg and I had also kicked around something similar as well. But this
has a larger
impact on the API so we weren't sure how well it would be accepted.
Why don't we
go away and look at this carefully and come up with another proposal
along these
lines.
That being said, we need to decide as to how the extension
architecture is going to look.
Does FDT register another language/nature into the CDT or does FDT
plan to clone/own the CDT's
structure and thus wants some base classes to start out with?
Ultimately we don't believe that cloning is the answer. Hopefully we
can register an
fnature with the CDT and work from there. However, there will be
some, very language specific
stuff (parser, for instance) that needs to be separate, but this
should be a small percentage
of the code. Perhaps the Photran folk could add their perspective on
this as well.
Being able to register another language with CDT is the ultimate goal,
but what we need right now is a strategy for getting to this point. One
suggestion is to choose some 'low hanging fruit' that are obviously
language independent, and modifying these so they work with both CDT
and the FDT clone. Once the components are integrated back into CDT,
FDT can then use the CDT version. This way we can tackle a large job,
piece by piece, without overwhelming CDT with changes. Both managed
build and the make support are obvious candidates, but there are also a
number of other possibilities.
Here are a couple of questions for the CDT community. First, is this an
acceptable approach? If so, how can we start this process so that it
will have minimal impact on CDT (in particular, minimally impact on CDT
API's)? If the setDefault() approach isn't palatable, is there another
way we can achieve the same goal?
We're happy to put the effort into making this idea work, but need a
starting point that is going to work for everyone.
Regards,
Greg
