GNU bug report logs -
#8635
Some Fortran files don't have the extensions automake wants
Previous Next
To reply to this bug, email your comments to 8635 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Sat, 07 May 2011 17:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Williams <pwilliams <at> astro.berkeley.edu>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Sat, 07 May 2011 17:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 thinks that
".for" files are Fortran 77 code, so the wrong compiler gets used and
chokes on the F90 constructs.
It's not practical for me to rename the files -- tracking upstream would
become impossible. Would it be possible to provide a way for me to tell
automake that my .for files are actually Fortran 90, not Fortran 77? As
far as I can tell, this mapping is simply hardcoded
in /usr/bin/automake. It wouldn't be the most pleasant, but it'd suffice
if there were some global variable that I could set that would say "hey,
Automake, .for files are F90". One could imagine more generic solutions
as well, but Fortran is probably the only language that has these kinds
of problems.
Thanks,
Peter
--
Peter Williams / pwilliams <at> astro.berkeley.edu
Department of Astronomy, UC Berkeley
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Mon, 09 May 2011 12:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 8635 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
> ... thinks that ".for" files are Fortran 77 code, so the wrong compiler
> gets used and chokes on the F90 constructs.
>
> It's not practical for me to rename the files -- tracking upstream would
> become impossible. Would it be possible to provide a way for me to tell
> automake that my .for files are actually Fortran 90, not Fortran 77? As
> far as I can tell, this mapping is simply hardcoded in /usr/bin/automake.
>
You're right.
> It wouldn't be the most pleasant, but it'd suffice
> if there were some global variable that I could set that would say "hey,
> Automake, .for files are F90". One could imagine more generic solutions
> as well, but Fortran is probably the only language that has these kinds
> of problems.
>
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.
> Thanks,
>
> Peter
>
HTH,
Stefano
[fortran.patch (text/x-patch, inline)]
diff --git a/automake.in b/automake.in
index e934c5f..23392a8 100755
--- a/automake.in
+++ b/automake.in
@@ -939,7 +939,7 @@ register_language ('name' => 'f77',
'lder' => 'F77LD',
'ld' => '$(F77)',
'pure' => 1,
- 'extensions' => ['.f', '.for']);
+ 'extensions' => ['.f']);
# Fortran
register_language ('name' => 'fc',
@@ -957,7 +957,7 @@ register_language ('name' => 'fc',
'lder' => 'FCLD',
'ld' => '$(FC)',
'pure' => 1,
- 'extensions' => ['.f90', '.f95', '.f03', '.f08']);
+ 'extensions' => ['.for', '.f90', '.f95', '.f03', '.f08']);
# Preprocessed Fortran
register_language ('name' => 'ppfc',
Severity set to 'wishlist' from 'normal'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 09 May 2011 12:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Mon, 09 May 2011 18:36:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 8635 <at> debbugs.gnu.org (full text, mbox):
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? I don't think developers would be too
happy about needing to run a custom-patched version of automake.
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.
Peter
>
> > Thanks,
> >
> > Peter
> >
>
> HTH,
> Stefano
--
Peter Williams / pwilliams <at> astro.berkeley.edu
Department of Astronomy, UC Berkeley
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Mon, 09 May 2011 19:34:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 8635 <at> debbugs.gnu.org (full text, mbox):
* Stefano Lattarini wrote on Mon, May 09, 2011 at 02:11:53PM CEST:
> --- a/automake.in
> +++ b/automake.in
> @@ -939,7 +939,7 @@ register_language ('name' => 'f77',
> 'lder' => 'F77LD',
> 'ld' => '$(F77)',
> 'pure' => 1,
> - 'extensions' => ['.f', '.for']);
> + 'extensions' => ['.f']);
>
> # Fortran
> register_language ('name' => 'fc',
> @@ -957,7 +957,7 @@ register_language ('name' => 'fc',
> 'lder' => 'FCLD',
> 'ld' => '$(FC)',
> 'pure' => 1,
> - 'extensions' => ['.f90', '.f95', '.f03', '.f08']);
> + 'extensions' => ['.for', '.f90', '.f95', '.f03', '.f08']);
>
> # Preprocessed Fortran
> register_language ('name' => 'ppfc',
Sorry, but this is not a good change, and it is backward-incompatible
(even if .for might not have been used much in practice).
My intention with the recent Autoconf Fortran changes was to go ahead
and let Automake grab those extensions for $(FC) for which an
AC_FC_SRCEXT was issued. And assume preprocessing for those where
AC_FC_PP_SRCEXT was issued for. But that is a bigger change.
Cheers, and sorry for my really slow catchup
(also, all of my mail from yesterday got stuck somewhere...)
Ralf
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Mon, 09 May 2011 19:41:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 8635 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Mon, 09 May 2011 19:44:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 8635 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ralf.
On Monday 09 May 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Mon, May 09, 2011 at 02:11:53PM CEST:
> > --- a/automake.in
> > +++ b/automake.in
> > @@ -939,7 +939,7 @@ register_language ('name' => 'f77',
> > 'lder' => 'F77LD',
> > 'ld' => '$(F77)',
> > 'pure' => 1,
> > - 'extensions' => ['.f', '.for']);
> > + 'extensions' => ['.f']);
> >
> > # Fortran
> > register_language ('name' => 'fc',
> > @@ -957,7 +957,7 @@ register_language ('name' => 'fc',
> > 'lder' => 'FCLD',
> > 'ld' => '$(FC)',
> > 'pure' => 1,
> > - 'extensions' => ['.f90', '.f95', '.f03', '.f08']);
> > + 'extensions' => ['.for', '.f90', '.f95', '.f03', '.f08']);
> >
> > # Preprocessed Fortran
> > register_language ('name' => 'ppfc',
>
> Sorry, but this is not a good change, and it is backward-incompatible
> (even if .for might not have been used much in practice).
>
Sorry if I hadn't been clear: my intention was *not* for this patch to be
applied to the automake official repository; it was just intended as a quick
workaround for Peter. See also my other mail in this thread.
> My intention with the recent Autoconf Fortran changes was to go ahead
> and let Automake grab those extensions for $(FC) for which an
> AC_FC_SRCEXT was issued. And assume preprocessing for those where
> AC_FC_PP_SRCEXT was issued for. But that is a bigger change.
>
My fortran fu is pretty weak, so I'm happily going to follow your lead
here.
> Cheers, and sorry for my really slow catchup
> (also, all of my mail from yesterday got stuck somewhere...)
>
Too bad :-(
> Ralf
>
Regards,
Stefano
[Message part 2 (text/html, inline)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#8635
; Package
automake
.
(Tue, 10 May 2011 18:12:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 8635 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2011-05-09 at 21:40 +0200, Stefano Lattarini wrote:
> 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.
Thanks for your thoughts. I'm willing to do a little bit of work to get
this bug fixed, but I don't have the time to make a major revision to
automake's internals, which it sounds this patch would entail. (Though
as a longtime automake user I definitely agree that more extensibility
would be awesome.)
Ralf, I think I understand what you mentioned about AC_FC_SRCEXT, and
that sounds like a nice approach. Is work actively being done on hooking
up those macros to Automake's language-choosing apparatus? If I wanted
that to happen, would I realistically have to do it myself?
Thanks,
Peter
>
> Regards,
>
> Stefano
--
Peter Williams / pwilliams <at> astro.berkeley.edu
Department of Astronomy, UC Berkeley
This bug report was last modified 14 years and 37 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.