bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers

[Stefano Lattarini]

[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: <address@hidden>
From: Stefano Lattarini <address@hidden>
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 <address@hidden>
---
 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