Skip to main content

[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

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.



Back to the top