Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Monthly Call

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

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,

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 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): (change getCoreModel() to return ICoreModel to allow subclassing)

(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?


Back to the top