-----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 [EMAIL PROTECTED] -----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-----
