-----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 [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 iEYEARECAAYFAkl+bQAACgkQ84KuGfSFAYDWgwCg0s6ldpaUAdbbiZfZdj7uMRxd EY0AniE5MPhZklnWRxEBRGBtcWJmvRx4 =hdL2 -----END PGP SIGNATURE-----
