Re: [cdt-dev] Monthly Call

[Craig Rasmussen <crasmussen@xxxxxxxx>]

On May 4, 2005, at 9:36 PM, Derrick Keefe wrote:

>  
> Other items for tomorrow:
> 	1 	Update on debugger meeting in Chicago. Alain
> 	2 	CDT 3.0 review schedule, I don't really expect a change at this 
> point.
> 	3 	CDT 3.0 scope update  for M7(RC0) additions, deletions
> 	4 	confirmation on close out strategy for M7, DaveD posting
> 	5 	Release Plan next 12 months
> 	6 	CDT fall conference
>  
> BTW If any one else has agenda items please respond to this thread.
>  

I hope we have time to briefly discuss multi-language support (sorry
I missed last months telecon).  I believe the major decision to make
is whether to add partial support for new languages explicitly in CDT
or through extension points.

To start the discussion I suggest that languages are born infrequently
and so direct hooks can be placed in CDT for Fortran, ADA, ...  For,
example, one could:

1. Add to ParserLanguage.java

    public final static ParserLanguage FORTRAN = new ParserLanguage( 3 
);

2. Add ability to access new scanners to ParserFactory:

    if ( language == ParserLanguage.FORTRAN )
        configuration = new .....

3. Add to buildDefinitions.exsd (to attribute natureFilter)

    <enumeration value="clnature"/>
    <enumeration value="fnature"/>

4. Add common language nature, CLNature.java

5. Suppliment ITool with:

    public static final int FILTER_CL = 3;
    public static final int FILTER_FORTRAN = 4;

6. Fix filters to use CL_NATURE_ID when appropriate (e.g., in 
Configuration.java).
As I count, there are only 5 classes where getNatureFilter is used.  
The goal
is to make ManagedBuild projects be language neutral so that one can mix
C, C++, Fortran, ... files.  Make is language neutral so the MBS should 
be as well.

7. Add ability to associate a new icon with a file name extension.

A list of classes that may need to be modified (for language and nature 
changes):

TypeSearchScope.java
CoreModel.java
CCorePlugin.java     (change getCoreModel() to return ICoreModel to 
allow subclassing)
CModelBuilder.java
CModelManager.java
CProject.java
ParserFactory.java
ParserLanguage.java
CSearchScope.java
GCCSpecsRunSIProvider.java
PerProjectSICollecter.java
Configuration.java
ConfigurationV2.java
ManagedBuilderInfo.java
CPathPropertyPage.java
IncludeSymbolsPropertyPage.java

(There are other files but they are more language specific and
probably should be subclassed.)

Given the above simple changes, a Fortran IDE could then do the
real language specific things such as:  Editing, Parsing, refactoring, 
...

Perhaps these changes could be made via extension points?

Cheers,
Craig