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 
> 
> Being able to register another language with CDT is the ultimate goal,=20=
> 
> but what we need right now is a strategy for getting to this point. One=20=
> 
> suggestion is to choose some 'low hanging fruit' that are obviously=20
> language independent, and modifying these so they work with both CDT=20
> and the FDT clone. Once the components are integrated back into CDT,=20
> FDT can then use the CDT version. This way we can tackle a large job,=20
> piece by piece, without overwhelming CDT with changes. Both managed=20
> build and the make support are obvious candidates, but there are also a=20=
> 
> number of other possibilities.
> 
> Here are a couple of questions for the CDT community. First, is this an=20=
> 
> acceptable approach? If so, how can we start this process so that it=20
> will have minimal impact on CDT (in particular, minimally impact on CDT=20=
> 
> API's)? If the setDefault() approach isn't palatable, is there another=20=
> 
> way we can achieve the same goal?
> 
> We're happy to put the effort into making this idea work, but need a=20
> starting point that is going to work for everyone.
> 

Isolate the functionnality/service/component and by iterations get the changes
as we move along we get a better grasp of the problem.
Let's take an example,.. say the indexer:
 - Does it have an API that is flexible for your needs? if not ...
 - Can you overload the default implementation ?
   For example by defining an extension point, that could be tied to a nature
   So when asking the indexerManager:
     IIndexerManager manager = CCorePlugin.getIndexerManger(IProject);
     or
     IIndexerManager manager = IndexerManager.getIndexer(IProject project);
   The nature of the project can be check and the right indexer created.

Like John, I'm not sure that having a CCorePlugin.setDefault() is the right thing todo.
So I would like to know which services that are of interest ... maybe the solution is to move
those services out in neutral plugins.. and the cdt.core will just be the C/C++ flavor.

Back to the top