Re: [cdt-dev] Patch to create ICoreModel interface

["Alain Magloire" <alain@xxxxxxx>]

: >>
: >
: > I would go the opposite not renaming but extending.
: >
: > interface ICProject extends ICLProject {
: > 	// contains specific methods for C/C++
: > }
: >
: 
: Excellent.
: 
: >
: > Question:
: > - how do fortran see the resources(folder, files, binaries ...) ?
: 
: In very much the same way.  I can't think of a way that we view
: them differently.  Perhaps linking is an issue in a similar way that
: the C++ linker should be used if there are C++ files in a project.
: The Fortran linker should be used if there are Fortran files
: in a project.  If there are C++ and Fortran files in a project,
: the rule is, use the C++ linker and cross your fingers.
: 

Good!!
Something to look for after CDT-3.0

: > - Any special use of the resources ?
: >    For example in Java, folders are special, i.e  java.lan.InputStream
: >    must be in folders java/lang/InputStream.{java,class} so the the 
: > folders
: >    map to the packagenames.
: 
: Probably nothing substantial.  Minor issues arise regarding the text 
: and icons
: describing resources.  For example, we want to display an "F" rather 
: than a "C"
: in an icon representing a Fortran file.
: 

That should be trivial, we are actually moving to what Eclipse offers
when describing the content-types(See the IContentTypeManager framework
in eclipse-3.1)

: A more complicated question is what about icons for projects.  We see 
: projects
: as containing source files from multiple languages (one language per 
: file,
: of course).  So it is not really simply a "C" project or simply a 
: "Fortran" project.
: 

In Eclipse, project icons are associated by the nature.

: > - Any other (external)files should be visible from the model ? 
: > libraries(*.so, *.a), jar(*.jar) ?
: 
: Fortran compilers produce *.mod files at the time of compilation.
: These files contain information about Fortran modules (similar to C++
: namespaces) and probably should be treated like *.o files from a CDT
: perspective, although they won't be archived in a library.  Otherwise,
: the same *.so, *.a files.  In general, libraries will contain object 
: files
: from C, C++, and Fortran.
: 

Allright, The binary Parser should be able to handle this.

: >
: > For example the Fortran factory(ICoreModel) could create an hierachy,
: >  - ICLModel
: >    - ICLProject  --> [IProject with Fortran nature]
: >    - ICLTranslationUnit -> IFile with *.f extensions
: >    ....
: >
: > The C Model Factory(ICoreModel)
: >   - ICLModel
: >      ICLProject --> ICProject [IProject with with C/C++ nature]
: >
: > So if we could agree on the model resources, that's a good start.
: > Refactoring the ICProject, ICContainer,... to be on top on the new 
: > hierarchy
: > should not be a big deal or not even necessary in some cases.
: >
: 
: I agree.  Although I want to experiment with the possibility of an 
: ICLProject
: containing both Fortran and C/C++ natures.  From the perspective of
: Make and ManagedMake, adding a Fortran nature to a project is not
: much more than having the proper compiler information in the toolchain 
: and
: adding an additional rule in the makefile transforming a *.f file to a 
: *.o.
: 

I am assuming that FDT, will have a perspective, a fortran editor
and some other extra views.

For post cdt-3.0, maybe the goal should be to find the common core denominators
and refactor them out.  For the UI, it will be more tricky and we should be
ready to accept a lot clone/duplication for the first iterations.

: > (2) How we view the language.
: >
: > ... but this email is already too long ...  8-)
: >
: 
: Right, at this point we Fortran folk will have to do some work 
: ourselves.  We can't
: let CDT developers have all of the fun :-)
: 

8-)
The folks here are busy with CDT-3.0 but some of the things we talk
can be done in parallel.