Re: FFLAGS & FCFLAGS

[Eric Blake]

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

According to Alfred de Wijn on 11/17/2008 6:44 PM:

Hi Alfred,

> I guess I am putting myself in a fragile position.  My code wants to
> know if FFLAGS or FCFLAGS was set by the user.  I can't check them
> directly, because they may be (and are) set by some autoconf macro
> earlier, and I want to override those cases.  So I decided to check if
> $ac_test_FFLAGS or $ac_test_FCFLAGS was set.

Yep, a very fragile position.  After all, we could have implemented things
via a subshell, such that modifications to FCFLAGS in the subshell don't
leak back to the parent, and only modifying FCFLAGS in the parent if the
subshell was successful - if we did that, the parent does not have to use
either ac_save_FFLAGS or ac_test_FFLAGS (regardless of Fortran dialect).
[Note the "could have" - it turns out that saving things into temporaries
is more efficient than forking a subshell, so this alternate
implementation is more of a rhetorical discussion.]

> I now just do some checks early to see which *FLAGS environment
> variables are set.  This way I'm independent of autoconf internals, and
> so it's probably a good idea anyway,

Yep, that is the portable solution that should work across all autoconf
versions.  In general, if you want to test if a variable was in use, then
it is safest to add shell code to do that check right after AC_INIT and
prior to calling any macros that might also care about the variable (a
similar case is using $@ within configure.ac - a user that wants to save
the original command-line arguments must grab them immediately after
AC_INIT, since many other autoconf macros liberally use 'set').

> A test is attached, for what it's worth.  mutt should behave better than
> Mail.app when it comes to attachments.

Yep, the patch came through much nicer.

Here's my thoughts: I don't want to apply the testcase (I don't want to
lock autoconf into having to provide ac_test_FCFLAGS indefinitely; since
that is supposed to be an internal detail that might change in a future
under-the-hood implementation, and the testsuite should only be testing
things that we guarantee in the documentation).  But your argument about
consistency in the C vs. C++ case is somewhat convincing.  On the other
hand, I don't want to apply any patches until we get at least one more
person commenting on this thread, and I am willing to apply the testcase
if someone else can chime in with an argument in favor (on more than one
occasion, we have ended up documenting previously internal details, if
only because someone was able to point to enough uses of that feature in
the wild which would break if we changed internal behavior).

So, a plea to all bug-autoconf readers - any preferences on whether I
should apply 0, 1, or 2 of Alfred's patches?  If I don't hear anything by
Friday, then I'll apply just the first patch, for the sake of consistency
with C/C++.

- --
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

iEYEARECAAYFAkkiL5UACgkQ84KuGfSFAYCpoQCfWWa1U3zMzEFs1B6muapVYg8D
E/sAnRrABrHKzAQPXyaeHICj1t8UdWx3
=PW2h
-----END PGP SIGNATURE-----