> What I'm more concerned about is all the macros that will now be turned > into being AC_DEFUN_ONCE, and which users have been using for a long > time and won't expect to have their semantics changed. I hope this set > will be small. AC_PROG_* shouldn't be in it, for compatibility reasons.
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. Those that do pose problems are: 1) those that find target tools, such as compilers or ranlib. It is conceivable that they are placed in an if statement, though technically wrong. See indeed http://www.google.com/codesearch/p?hl=en#e_ObwTAVPyo/configure.in&l=299 -- what a needless complication! Not even the gcc configure scripts are so messy (besides, they use --host for --build and --target for --host wrong... this is their bug 475488 now). It is also conceivable that they are called multiple times, though tricky. My own ACX_PROG_CC_FOR_BUILD macro which is somewhere in the autoconf archive would fail miserably. 2) AC_PROG_CXX and for a different reason, which is because the lack of a C++ compiler will abort the configure script. This is a pity because PHP and Apache have the following: if test -z "$php_cxx_done"; then AC_PROG_CXX AC_PROG_CXXCPP php_cxx_done=yes fi and (if it wasn't for the above misfeature) it would work also for AC_DEFUN_ONCE'd AC_PROG_CXX{,CPP} with good savings on configure script size. 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). 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? Paolo
