Re: [photran-dev] Questions about 7.0

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

On Mon, Jun 13, 2011 at 9:09 AM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
>
> On Jun 10, 2011, at 8:36 PM, Doug Schaefer wrote:
>
>> On Fri, Jun 10, 2011 at 5:28 PM, Jeffrey Overbey <overbey2@xxxxxxxxxxxx> wrote:
>>> Hi Greg,
>>>
>>>> 1. When I open the properties of a Fortran project, I see the C/C++ Build and General properties along with the Fortran ones. Is this expected?
>>>
>>> Yes. Every Fortran project is also a C project, but not every C
>>> project is a Fortran project.
>>>
>>>> 2. When I open a .h file in the project, I see codan errors in the files.
>>>
>>> Yes. CDT assumes that .h files are C, not Fortran.
>>>
>>> I've seen some projects use .fh or .Inc for Fortran include files, but
>>> nothing is quite as standardized as in C.
>>
>> That's something we should talk about. Right now we use cnature to
>> mean CDT project and to signify that it's a C project. We should
>> probably separate out those concepts and introduce a new nature for
>> the C aspects, like interpreting header files in a certain language.
>> Thoughts?
>
> The problem is that a Fortran program is very rarely "pure" Fortran. In a lot of cases they include some C code, and often this gets linked into the Fortran executable. It's also apparently very common to use the C preprocessor on Fortran code. The code I'm looking at right now has C and Fortran code mixed in the the same directory, and worse, a bunch of .h files some of which contain C code and some Fortran code. It seems like a blanket C nature or Fortran nature is too coarse grained for this type of project. I think it would be necessary to be able to designate the language used by individual files.

We have the same issues with C++, of course, where C code is mixed
with C++. As a result, the language specific aspects of the cnature is
actually very limited. The nature only controls what default language
to use to parse the header files. And it is also used by toolchains to
pick which linker to use (C versus C++). And that's pretty much it.
Mixing of languages is fine as long as the parsers can deal with it,
and we have some hooks now that can associate parsers with toolchains
to give you more control.

I guess my point is that I always wanted Photran to be a close
extension to CDT from the day I was introduced to it many EclipseCons
ago. We'd be happy to accommodate what ever change to the CDT is
necessary to make that happen, with the good news being that it
shouldn't be much at this point.

Doug