Re: AC_USE_SYSTEM_EXTENSIONS should be AC_DEFUN_ONCEd

[Eric Blake]

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

According to Ralf Wildenhues on 1/26/2009 4:02 PM:
> * Eric Blake wrote on Mon, Jan 26, 2009 at 10:16:30PM CET:
>> Subject: [PATCH] Use AC_DEFUN_ONCE more liberally.
>>
>> * lib/autoconf/programs.m4 (AC_PROG_MAKE_SET): Switch to
>> AC_DEFUN_ONCE, since this is a one-shot macro.
>> (AC_PROG_AWK, AC_PROG_GREP, AC_PROG_EGREP, AC_PROG_FGREP)
>> (AC_PROG_INSTALL, AC_PROG_MKDIR_P, AC_PROG_LN_S, AC_PROG_RANLIB)
>> (AC_PROG_SED, AC_PROG_YACC): Likewise.
>> * lib/autoconf/headers.m4 (AC_HEADER_ASSERT): Likewise.
>> * lib/autoconf/lang.m4 (AC_LANG_WERROR): Likewise.
>> * lib/autoconf/c.m4 (AC_PROG_CC_C_O, AC_PROG_CPP)
>> (AC_PROG_CPP_WERROR, AC_PROG_CC_STDC, AC_PROG_CC_C89)
>> (AC_PROG_CC_C99, AC_PROG_GCC_TRADITIONAL, AC_PROG_CXXCPP)
>> (AC_PROG_CXX_C_O, AC_PROG_OBJCPP): Likewise.
>> * lib/autoconf/fortran.m4 (AC_PROG_F77_C_O, AC_PROG_FC_C_O)
>> (AC_F77_LIBRARY_LDFLAGS, AC_FC_LIBRARY_LDFLAGS, AC_F77_MAIN)
>> (AC_FC_MAIN, AC_F77_WRAPPERS, AC_FC_WRAPPERS): Likewise.
>> * lib/autoconf/libs.m4 (AC_PATH_X, AC_PATH_XTRA): Likewise.
>> * lib/autoconf/specific.m4 (AC_SYS_INTERPRETER)
>> (AC_SYS_LARGEFILE, AC_SYS_LONG_FILE_NAMES)
>> (AC_USE_SYSTEM_EXTENSIONS): Likewise.
>> * lib/autoconf/erlang.m4 (AC_ERLANG_SUBST_ROOT_DIR)
>> (AC_ERLANG_SUBST_LIB_DIR, AC_ERLANG_SUBST_INSTALL_LIB_DIR):
>> Likewise.
>> * lib/autoconf/general.m4 (AC_CANONICAL_BUILD)
>> (AC_CANONICAL_HOST, AC_CANONICAL_TARGET, AC_PRESERVE_HELP_ORDER)
>> (AC_DISABLE_OPTION_CHECKING):
> 
> So all of these macros are now incompatibly changed, silently.
> This looks like you're inventing a whole new language, where
> plain shell-conditional invocation of macros is completely forbidden,

No, plain shell-conditional invocation still works at the top-level (or
even in an m4_define'd macro):

if condition ; then
  AC_CANONICAL_HOST
fi

what is changed is doing it inside a defun'd macro:

AC_DEFUN([wrapper],
[if condition ; then
  AC_CANONICAL_HOST
fi])
wrapper

> and many tests cannot be conditionalized at all any more.  I wouldn't
> even know how to systematically check for all the little
> incompatibilites this can cause.
> 
> Is there no way this can be fixed with less churn?  If not, then I think
> all these macros (and what's more, any macros that require any of the
> above) should be marked as nonobvious-to-use in the manual, e.g. a set
> of macros in Automake and Libtool, too.
> 
> Sorry to sound so negative, but this seems quite dangerous to me.

Since you are worried about this change biting existing configure.ac, then
we can indeed be more conservative.  Of the above list, I know for a fact
that AC_USE_SYSTEM_EXTENSIONS needs to be changed (in order to better
interoperate with the deprecated AC_GNU_SOURCE, which is still in heavy
use in the wild).  Also, changing AC_PROG_MKDIR_P led to a sizable savings
of several kilobytes coreutils' makefile, meaning that even though the
macro was idempotent, it was being repeatedly expanded.

I already agree with your reasoning about changing macros that are not
idempotent being dangerous, which is why things like AC_FUNC_ALLOCA (which
depends on your current AC_LANG_PUSH settings) cannot be converted into a
one-shot macro.

I guess it boils down to identifying which macros must be changed to avoid
warnings, vs. which macros are reasonable to use inside a defun'd macro
without being hoisted.  And I'm willing to trim the above list down to a
much smaller list, especially when pointed to any example in the wild
where hoisting the macro would change the user's script.

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

iEYEARECAAYFAkl+bQAACgkQ84KuGfSFAYDWgwCg0s6ldpaUAdbbiZfZdj7uMRxd
EY0AniE5MPhZklnWRxEBRGBtcWJmvRx4
=hdL2
-----END PGP SIGNATURE-----