bug-automake
[Top][All Lists]
Advanced

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

bug#8635: Some Fortran files don't have the extensions automake wants


From: Stefano Lattarini
Subject: bug#8635: Some Fortran files don't have the extensions automake wants
Date: Mon, 9 May 2011 21:40:09 +0200
User-agent: KMail/1.13.5 (FreeBSD/8.2-RELEASE; KDE/4.5.5; i386; ; )

On Monday 09 May 2011, Peter Williams wrote:

> Hi Stefano,

>

> Thanks for your prompt reply.

>

> On Mon, 2011-05-09 at 14:11 +0200, Stefano Lattarini wrote:

> > severity 8635 wishlist

> > thanks

> >

> > On Saturday 07 May 2011, Peter Williams wrote:

> > > I'm working on wrapping a large, preexisting piece of Fortran code with

> > > an Autotools-based build system. The code is written in Fortran 90 and

> > > uses ".for" for the file extension. Unfortunately, automake ...

> > >

> > I assume you are using automake 1.11.1, right?

>

> Yes.

>

> > Please try the attached patch (against the v1.11.1 tag in the automake git

> > repository). I *think* it should solve your problem for what concerns

> > automake. However, note that the GNU Fortran Compiler will still consider

> > `*.for' files to be Fortran 77 by default, so you'll have to instruct it

> > to explicitly assume free-form Fortran 90 input, with .e.g.:

> >

> > $ ./configure FCFLAGS='-ffree-form -x f95' LDFLAGS='-x none'

> >

> > This solution is probably not the best one, and is certainly not pretty,

> > but it should work. If you can come up with a more general one, I'd be

> > happy to hear about it.

>

> This does work. Do you think this change would be applied to released

> versions of automake, though?

>

Certainly no; the current automake behaviour w.r.t. the `.for' extension

has been in place for a long time, and it matches gfortran expectations,

so there's no reason to just change it. But making it configurable could

be a useful improvement.

> I don't think developers would be too

> happy about needing to run a custom-patched version of automake.

>

That's understandable. Unfortunately, the lack of easy extesibility is

a known problem of Automake, and IMHO its major shortcoming.

> I was thinking that there could be an Autoconf macro called

>

> AM_ALIAS_SOURCE_EXTENSION([.for],[.f90])

>

> that would mutate the %extension_map variable to treat .for files the

> way that .f90 files are normally treated. It looks like this could

> happen in &scan_autoconf_traces. I don't have a good enough

> understanding of the automake internals to know whether this would be a

> simple change or whether that would affect a lot of other things,

> though.

>

Hmm... I don't like this solution either; it still sounds a little too

hackish, and to me it seems wrong to have to declare project policy

decisions that are system-independent and relevant only for automake (in

this case, the policy decision being "use the `*.for' extension for

Fortran 90 sources") in the configure.ac file.

OTOH, some times ago a patch has been proposed which would allow user

extensions to the languages handled/understood by Automake:

<http://lists.gnu.org/archive/html/automake/2010-09/msg00003.html>

IMHO, resurrecting it (and possibly improving it to naturally serve your

user case) would be the best way to fix your problem (and similar ones)

in the long run.

Regards,

Stefano


reply via email to

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