[Summarizing the relevant points of the past discussion, somewhat] Eric Blake wrote: > > But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC > so that it hooks in a call to AM_PROG_CC_C_O immediately after its > current definition, and thus still preserve desired ordering while > making the burden simpler for the configure.ac author.
I replied: > > This is true, but I'd have preferred to avoid this shenanigans with > macro redefinitions if at all possible. It seems it won't be really > possible though (see also my reply to the last message from Nick): > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47> > > So I think your proposal is the way to go, *right for Automake 1.13.2*, > since it offers a bug fix for the situation described in > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47> And then went on to implement the patch: > > Done with the patch below. The AC_PROG_CC redefinition is more of a > band-aid rather than a "proper" fix (the copy & paste done by the patch > is admittedly quite horrific), but that is no big deal IMHO, since we > will backport the features needed by Automake back into Autoconf, and > Automake 1.14 will just require the later Autoconf anyway, allowing us > to get rid of that copy & paste. > Now, Autoconf has been updated to do what we need: <http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html> The change above has been committed as 'v2.69-63-gce48964'. So here is a follow-up that removes the horrible hack introduced by the previous patch. Since it will require Autoconf 2.70, it is only meant to be applied to master of course; but sending it early to elicit reviews cannot hurt, can it? ;-) ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- >From ea80119488d2cd38ec3c81119c6019a4b6decb89 Mon Sep 17 00:00:00 2001 Message-Id: <ea80119488d2cd38ec3c81119c6019a4b6decb89.1357921799.git.stefano.lattar...@gmail.com> From: Stefano Lattarini <stefano.lattar...@gmail.com> Date: Fri, 11 Jan 2013 16:59:07 +0100 Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite Instead, only touch up AC_PROG_CC to distribute the 'compile' script and to rewrite $CC if a losing compiler is detected. We can do so because Autoconf 2.70 (which we now requires) has been so kind to implement the features we need (through a private hook made explicitly available to us), in commit v2.69-63-gce48964 of 2013-01-11, "AC_PROG_CC: also check whether $CC supports "-c -o" together": <http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html> * m4/init.m4 (AC_PROG_CC): Simplify, relying on the Autoconf hook. Signed-off-by: Stefano Lattarini <stefano.lattar...@gmail.com> --- m4/init.m4 | 42 ++++++++---------------------------------- 1 file changed, 8 insertions(+), 34 deletions(-) diff --git a/m4/init.m4 b/m4/init.m4 index c5af65c..9316c2c 100644 --- a/m4/init.m4 +++ b/m4/init.m4 @@ -126,42 +126,16 @@ m4_define([_AC_COMPILER_EXEEXT], m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])]) dnl We have to redefine AC_PROG_CC to allow our compile rules to use -dnl "-c -o" together also with losing compilers. -dnl FIXME: Add references to the original discussion and bug report. -dnl FIXME: Shameless copy & paste from Autoconf internals, since trying to -dnl play smart among tangles of AC_REQUIRE, m4_defn, m4_provide and -dnl other tricks was proving too difficult, and in the end, likely -dnl more brittle too. And this should anyway be just a temporary -dnl band-aid, until Autoconf provides the semantics and/or hooks we -dnl need (hint hint, nudge nudge) ... +dnl "-c -o" together also with losing compilers. We can do so using +dnl a private hook Autoconf has made available to us (since version +dnl 2.70). AC_DEFUN([AC_PROG_CC], +[AC_REQUIRE([AM_AUX_DIR_EXPAND])]dnl +[AC_REQUIRE_AUX_FILE([compile])]dnl +[m4_define([_AM_PROG_CC_C_O_HELPME], [1])]dnl Activate the private hook. +dnl This must *not* be quoted! m4_defn([AC_PROG_CC]) -[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl -AC_REQUIRE_AUX_FILE([compile])dnl -dnl FIXME The following abomination is expected to disappear in -dnl Automake 1.14. -AC_MSG_CHECKING([whether $CC understands -c and -o together]) -set dummy $CC; am__cc=`AS_ECHO(["$[2]"]) | \ - sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'` -AC_CACHE_VAL([am_cv_prog_cc_${am__cc}_c_o], -[AC_LANG_CONFTEST([AC_LANG_PROGRAM([])]) -# Make sure it works both with $CC and with simple cc. -# We do the test twice because some compilers refuse to overwrite an -# existing .o file with -o, though they will create one. -ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD' -rm -f conftest2.* -if _AC_DO_VAR(ac_try) && test -f conftest2.$ac_objext -then - eval am_cv_prog_cc_${am__cc}_c_o=yes -else - eval am_cv_prog_cc_${am__cc}_c_o=no -fi -rm -f core conftest* -])dnl -if eval test \"\$am_cv_prog_cc_${am__cc}_c_o\" = yes; then - AC_MSG_RESULT([yes]) -else - AC_MSG_RESULT([no]) +[if eval test \"\$ac_cv_prog_cc_${ac_cc}_c_o\" != yes; then # Losing compiler, so wrap it with the 'compile' script. # FIXME: It is wrong to rewrite CC. # But if we don't then we get into trouble of one sort or another. -- 1.8.1.rc3.192.g2d0029e
