-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Paolo Bonzini on 1/27/2009 1:03 AM: > I think that only the following macros must absolutely be defined with > AC_DEFUN_ONCE: AC_CANONICAL_*, AC_USE_SYSTEM_EXTENSIONS. > > Regarding AC_PROG_* macros, I think most of them pose no problems, but I > agree that this should be left to a future version N years down the > road.
OK, on the argument that it is not fixing a bug, but just optimizing performance (even for things like AC_PROG_MKDIR_P, where I've already proven that it shrinks the size of coreutils), I will not change any of the AC_PROG on this go-around. I'll post my revised patch for review soon. > Two other points. First, it's interesting that AC_PROG_LEX is already > defined with AC_DEFUN_ONCE, and since 2001-08-22 for that matter (I > don't really understand why). Yes, I noticed that one myself. > Second, Eric, I have a doubt: does this idiom work with the new > AC_DEFUN_ONCE? > > AC_PROVIDE_IFELSE([AC_PROG_CXX], > [_AM_DEPENDENCIES(CXX)], > [m4_define([AC_PROG_CXX], > m4_defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl > > I think so, but I'd rather ask you? If AC_PROG_CXX has already been expanded, then expand just _AM_DEPENDENCIES(CXX); otherwise, redefine AC_PROG_CXX so that the next guy to actually expand it is now expanding the original plus an additional _AM_DEPENDENCIES(CXX). I don't see anything wrong with that construct (other than a potentially missing [] prior to _AM_DEPENDENCIES in case AC_PROG_CXX originally ended in something that looks like a potential macro name), or any reason why its semantics would have changed. - -- 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/BNQACgkQ84KuGfSFAYB5IACfaA3lOMbK5pb0+U8F86vOytIH LfYAn0b5pegyoy68k5xyBmhXc8pbcU36 =Jlpo -----END PGP SIGNATURE-----
