[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Patch to create ICoreModel interface
|
: >>
: >
: > 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.