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
])
