GNU bug report logs - #8635
Some Fortran files don't have the extensions automake wants

Previous Next

Package: automake;

Reported by: Peter Williams <pwilliams <at> astro.berkeley.edu>

Date: Sat, 7 May 2011 17:14:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Williams <pwilliams <at> astro.berkeley.edu>
Cc: 8635 <at> debbugs.gnu.org
Subject: bug#8635: Some Fortran files don't have the extensions automake wants
Date: Mon, 9 May 2011 21:40:09 +0200
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

This bug report was last modified 14 years and 38 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.