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

[Stefano Lattarini]

On 01/10/2013 02:33 PM, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
> 
> On 01/08/2013 08:27 PM, Stefano Lattarini wrote:
>> On 01/08/2013 04:29 PM, Eric Blake wrote:
>>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>>>> That would be overkill, since AM_PROG_CC_C_O is only required by
>>>> projects doing C compilation.  Also, IIRC, that macro needs to be
>>>> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
>>>> before AC_PROG_CC.
>>>
>>> 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.
>>>
>> 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>
>> :-(
>>
>> [SNIP]
>>
>> 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>
>>
> 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.
> 
> In addition, with this change, the 'compile' script will be required
> in *all* projects using C compilation (even if they don't use the
> 'subdir-objects' option); but this should be noticeable only by
> packages not using 'automake --add-missing' (and they should be the
> great majority), and easily fixable by the other packages anyway.
> 
> OK to push to maint?  I'll wait up to a week to push, since I'd really
> like a review on this ...
>
In fact, we don't need to define the 'NO_MINUS_C_MINUS_O' preprocessor symbol,
nor should we use the 'ac_cv_prog_cc_${ac_cc}_c_o' cache variable (that is
owned by the autoconf macro AC_PROG_CC_C_O).  So consider the below squashed
in.  Let me know if you want me to send a fixed complete patch too.

Regards,
  Stefano

-*-*-*-

diff --git a/NEWS b/NEWS
index e87d267..09bfc1e 100644
--- a/NEWS
+++ b/NEWS
@@ -70,7 +70,10 @@ New in 1.13.2:

   - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op
     now.  Future Automake versions might start warning that this
-    macro is obsolete.
+    macro is obsolete.  For better backward-compatibility, this macro
+    still sets a proper 'ac_cv_prog_cc_*_c_o' cache variable, and
+    define the 'NO_MINUS_C_MINUS_O' C preprocessor symbol, but you
+    should really stop relying on that.

 * Obsolescent features:

diff --git a/m4/init.m4 b/m4/init.m4
index db77a96..c5af65c 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -141,9 +141,9 @@ 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; ac_cc=`AS_ECHO(["$[2]"]) | \
-                      sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
-AC_CACHE_VAL([ac_cv_prog_cc_${am_cc}_c_o],
+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
@@ -152,13 +152,13 @@ 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 ac_cv_prog_cc_${ac_cc}_c_o=yes
+  eval am_cv_prog_cc_${am__cc}_c_o=yes
 else
-  eval ac_cv_prog_cc_${ac_cc}_c_o=no
+  eval am_cv_prog_cc_${am__cc}_c_o=no
 fi
 rm -f core conftest*
 ])dnl
-if eval test \"\$ac_cv_prog_cc_${ac_cc}_c_o\" = yes; then
+if eval test \"\$am_cv_prog_cc_${am__cc}_c_o\" = yes; then
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -168,8 +168,6 @@ else
   # A longer-term fix would be to have automake use am__CC in this case,
   # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
   CC="$am_aux_dir/compile $CC"
-  AC_DEFINE([NO_MINUS_C_MINUS_O], [1],
-            [Define to 1 if your C compiler doesn't accept -c and -o 
together.])
 fi
 ])

diff --git a/m4/minuso.m4 b/m4/minuso.m4
index 6cb574e..17fa8c9 100644
--- a/m4/minuso.m4
+++ b/m4/minuso.m4
@@ -15,4 +15,11 @@ dnl Make sure AC_PROG_CC is never called again, or it will 
override our
 dnl setting of CC.
 m4_define([AC_PROG_CC],
           [m4_fatal([AC_PROG_CC cannot be called after AM_PROG_CC_C_O])])
+# For better backward-compatibility.  Users are advised to stop
+# relying on this cache variable and C preprocessor symbol ASAP.
+eval ac_cv_prog_cc_${am__cc}_c_o=\$am_cv_prog_cc_${am__cc}_c_o
+if eval test \"\$ac_cv_prog_cc_${am__cc}_c_o\" != yes; then
+  AC_DEFINE([NO_MINUS_C_MINUS_O], [1],
+            [Define to 1 if your C compiler doesn't accept -c and -o 
together.])
+fi
 ])