Re: Improved Fortran support

[marq]

Hi again!

On  4 Feb, Tom Tromey wrote:
>>>>>> ">" == marq  <address@hidden> writes:
> 
>>> The last point is annoying, since it prohibits the use of any .F90
>>> or even .f95 files in any project that is maintained with automake:
>>> it simply doesn't generate the proper dependencies for a library or
>>> program - a .F90, .f95 or .F95 is never compiled, even if the
>>> Makefile.am contains handwritten rules for their generation.
> 
> Hmm... that sounds wrong.  Did you try adding the suffixes to the
> SUFFIXES macro?

Of course. The problem is that with

  bin_PROGRAMS = prog
  prog_SOURCES = some.f90 foo.f90 bar.F90

in Makefile.am, bar.o does not appear in the automatically generated
dependency list for prog. And is therefore not compiled. One could add
this dependency manually to Makefile.am, of course; but what is automake
good for, then?

>>>  - Files ending with .f90 are also handled this way; i.e. Fortran 77 (!)
>>>    targets are created for them - not really fine... :-(
> 
> I thought we were just following what the autoconf Fortran guys
> suggested.

I think I understand the rationale behind it: Even without Fortran 90
support in the autotools, you can force configure using the Fortran 90
compiler by something like

  F77=f90 ./configure

But really, IMHO this is just a simple hack to work around a missing
feature. Plus, .F90 should be added to the ppf77 part in order to be
consistent (my view).

>>> F90, F90FLAGS, F90LINK and F95, F95FLAGS, F95LINK,
>>> respectively. These somehow have to be generated by configure.in.
> 
> This part is a bit of a problem.  Ideally we would have a handy
> autoconf macro that users could just drop in.  Or at the very least we

Based on Martin's earlier scripts, I would try to provide some over the
next few days that work with the curent cvs version of autoconf.

> would warn if these are not defined (maybe we already do, with your
> patch?  I don't know).

I've added a .f95 to one of my projects without having any apprpriate
autoconf macro, and got this from the patched version:

  automake: Makefile.am: Fortran 95 source seen but `F95' not defined in 
`configure.in' 

>>> +sub lang_f90_finish
>>> +{
> 
> Since the body of this, lang_f95_finish, and lang_f7_finish are nearly
> identical, how about making a new subroutine which all three call with
> the appropriate arguments?  That would seem to make maintenance
> easier.

Hmm. As Martin pointed out a long while ago, F90 has a complex structure
when it comes to dependencies due to the existence of module files. In a
very basic support mode, the targets to be generated are indeed very
similar to the ones required by f77. But over time, if someone finds
ways to represent module appropriately in Makefiles, these routines
might differ substantially. I don't know what's the best way to start
this - what's your advice?

> One question I have about the Fortran support: is it really the case
> that there are projects with a mix of F77, F90, and F95 code?  What if

Well, yes. There are a lot of old, but very well tested (usually
numerical) libraries out there... look at http://www.netlib.org.  One
thing I often do (this is where I need autoconf/automake, for, actually)
is to provide a comfortable f90 interface to some of these, create a
library and use it in other f90 projects.

> we just assume the "F77" compiler is a poorly-named macro holding a
> generic "Fortran" compiler, and then let it handle the new prefixes as
> well?  Would that work?  I really don't know.

Theoretically, it should, as f77 (the standard) is a subset of f90. But
in reality, vendors for f77 compilers have added many extensions to the
standard - often uniquely over the industry. What if the f90 compiler
does not support some of these? One example I can immediately think of
(on Suns) is the BYTE data type, which is supported by Sun's f77 (and
even g77), but not by it's f90 counterpart.

> I'll need paperwork from you before I can check in this patch (or any
> variant of it).  I've been putting off figuring out how to do that,
> but I'll see if I can motivate this week.

Please let me know what I have to do.

> Tom

Regards,

  Chris.
  
-- 

  Christian Marquardt

  GFZ Potsdam, Div. 1             |       Tel.: (+49) 331-288-1168
  Am Telegrafenberg               |       Fax:  (+49) 331-288-1169
  D-14473 Potsdam                 |       Email: address@hidden