Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Patch to create ICoreModel interface 

On Apr 1, 2005, at 7:44 PM, Alain Magloire wrote:


Now, the questions:

- Is the current ICElement hierarchy correct for you ?
  - if not ... how do you see the hierachy.



...

In fact, I would suggest changing the names of some interfaces to
represent this.
For example (CL stands for Common/Compiled Language):

ICModel -> ICLModel
ICProject -> ICLProject
ICContainer -> ICLContainer



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.


- 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.
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.
- 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.



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. 


(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 :-)

Cheers,
Craig

Back to the top