[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fortran projects (was: Compilation order)

From: Alberto Luaces
Subject: Re: Fortran projects (was: Compilation order)
Date: Wed, 8 Oct 2008 20:53:54 +0200
User-agent: KMail/1.9.9

Hello Ralf,

El Martes 07 Octubre 2008ES 22:34:49 Ralf Wildenhues escribió:
> Hello Alberto,
> * Alberto Luaces wrote on Mon, Oct 06, 2008 at 05:11:42PM CEST:
> > El Domingo 05 Octubre 2008ES 11:23:40 Ralf Wildenhues escribió:
> > > Before you implement manual dependency tracking in your own project:
> > > how about implementing it in Automake, so that all Fortran projects can
> > > benefit?
> >
> > Although I'm a automake newbie, I am interested. I'd be grateful if you
> > gave me those pointers.
> There are two projects for Automake lurking here:
> 1) support header dependencies for preprocessed Fortran.
> This should be a reasonably straightforward extension of side-effect
> dependencies currently implemented for C and C++, for example.  The key
> ideas are described here:
> <
> <
> Most that would be needed for ppfc, ppf77 is an adjustment of the
> depcomp script for the various ways that can header dependencies
> can be output.  And a couple of changes in to actually
> enable this for these languages, and tests to make sure this works.
> Norman Gray has done some prior work here IIRC.  Maybe we can just reuse
> some of his.
> 1.5) Well, there is at least one special case issue we should address
> separately.  Part of testing (1) would be to check that config.h
> inclusion as well as -D settings from DEFS work.
> Now, the IBM xlf/xlf90 compiler rejects -DDEFINE but accepts
> -WF,-DDEFINE instead.  This can be worked around, either by
> some clever substitutions in the makefile, or with a wrapper
> script a la `compile', let's call it fppcompile.
> (I think I even have a half-baked patch for this lying around somewhere,
> the solution strategy seems so familiar.)
> 1.75) (If there is need for '-c -o' emulation for deficient Fortran
> compilers, I definitely have a half-baked patch for that issue.)
> 2) Support for module dependencies.
> Prior external work:
> <>
> <>
> Problems: compiling foo.f may generate arbitrary modules bar.mod,
> baz.MOD, bla.vo.  So the rules may not be simple.  Or we may want to
> limit to some kinds of setups: either some compilers only, or some
> required naming strategy.  Anyway, the field is quite open here,
> but any kind of support would be cool.
> Some general comments: if you choose to contribute to Automake, be our
> guest, and welcome!  Please note that nontrivial contributions require
> copyright assignment (more off-list if you're interested), and please
> develop against the git master version of Automake.  Take a look at the
> HACKING file for some more helpful bits.

Thank you very much for the information, I'm currently perusing it. Is this 
the right list for asking implementation questions?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]