bug-autoconf
[Top][All Lists]
Advanced

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

Re: FFLAGS & FCFLAGS


From: Eric Blake
Subject: Re: FFLAGS & FCFLAGS
Date: Mon, 17 Nov 2008 06:34:10 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Alfred G. de Wijn on 11/15/2008 11:15 AM:
> Hi!

Hello Alfred, and thanks for the report.

> 
> While generalizing some code from FFTW to check for compiler flags from
> C to Fortran, I ran into an issue with autoconf.  It seems that
> ac_test_FCFLAGS and ac_save_FCFLAGS are never set because in fortran.m4
> it is hardcoded as:
> 
> ac_test_FFLAGS=${[]_AC_LANG_PREFIX[]FLAGS+set}
> and
> ac_save_FFLAGS=$[]_AC_LANG_PREFIX[]FLAGS

I don't yet see how this is a problem.  It should't matter if the
temporary macro names are hardcoded, so long as the original macro is
restored correctly when the test that needed a temporary reassignment of
the original is complete (for that matter, we could have done something like:

ac_foo=${_AC_LANG_PREFIX[]FLAGS+set}
ac_bar=$_AC_LANG_PREFIX[]FLAGS

provided that we later do:

if test "$ac_foo" = set ; then
  _AC_LANG_PREFIX[]FLAGS=$ac_bar
fi
)

I guess what I am asking is why you need a temporary variable to be named
exactly ac_save_FCFLAGS, seeing as how that is supposed to be an internal
implementation detail and is not part of the documented API.  If your
configure.ac is depending on an undocumented autoconf feature, you are
putting yourself in a fragile position, since we are free to change that
implementation in a future autoconf release; you are better off using only
public API (and that includes convincing us to document something that was
previously private API, when needed).  Do you have an actual testcase
where this caused problems?

All that said, your patch looks reasonable (this is one of the more
complete bug reports we have received); if you can provide just a bit more
justification why your patch is important, I will probably apply it.

> patch is attached, as is testsuite.log.  With a bit more time, I can
> probably provide a test as suggested in README-hacking, too.

Indeed, at this point, an addition to the testsuite would be the
justification I'm looking for.  And next time, can you convince your
mailer to send patches with a text content type, rather than Content-Type:
application/octet-stream, so that I can review them inline rather than
having to save off the file?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkhctIACgkQ84KuGfSFAYB3/ACgv4P3SoBq0l+Tmdd/AH7eKFHM
Xy8AnRiLHgS2zKDrg8FvVeSEgH3v7gx5
=I6mp
-----END PGP SIGNATURE-----




reply via email to

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