Hash :
e90126cf
Author :
Date :
2013-05-15T10:14:46
AM_PROG_CC_C_O: don't rely on AC_PROG_CC_C_O, re-implement similar logic
** Theoretical problems of AC_PROG_CC_C_O:
Both cc and $CC are checked to see if they support the '-c' and '-o'
options together.
This behaviour is highly inconsistent with that of the other macros
related to C compiler checks -- which test only $CC.
It can also cause unwarranted uses of the 'compile' script on systems
where the default 'cc' is inferior, but the user is compiling with a
proper, different compiler (e.g., gcc).
** Practical problems with our previous implementation of C support m4
macros in Automake:
- AM_PROG_AR must now be called *before* AC_PROG_CC; this wasn't the
case before, and it turns out there are packages in the wild that
relied on the old behaviour.
- The cross-referenced requirements and macro rewrites juggled among
AC_PROG_CC, AC_PROG_CC_C_O and AM_PROG_CC_C_O caused warnings in
autoconf; for example, in our test 't/libobj3.sh', we could see
warnings like these (here slightly tweaked for legibility):
configure.ac:5: AC_REQUIRE: `AC_PROG_CC' expanded before required
autoconf/c.m4:567: AC_PROG_CC_C_O is expanded from...
autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
m4sugar/m4sh.m4:639: AS_IF is expanded from...
autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
aclocal.m4:70: AM_PROG_AR is expanded from...
configure.ac:5: the top level
** Fix all of that:
We fix all of the described issues with a new internal m4 macro
_AM_PROG_CC_C_O (inspired to, but not based on, AC_PROG_CC_C_O) that
gets tacked on to AC_PROG_CC automatically (this is done in the
Automake-generated aclocal.m4) and that takes care of checking and
adjusting '$CC' for "-c -o" support.
The macro AM_PROG_CC_C_O is still present, but is now just a thin
wrapper around such Automake-enhanced AC_PROG_CC.
It is worth noting that the present patch causes three slight
*backward-incompatibilities*:
1. The name cache variable used by AM_PROG_CC_C_O is no longer
computed (at configure runtime!) from the content of '$CC',
but is statically defined as 'am_cv_prog_cc_c_o'.
2. 'cc' is no longer checked by AM_PROG_CC_C_O, only '$CC' is.
3. AM_PROG_CC_C_O no longer AC_DEFINE the C preprocessor symbol
'NO_MINUS_C_MINUS_O'.
Given however that the third change can easily be worked around, that
the first two changes can be legitimately seen as bug fixes, and that
the new semantics introduced by such changes will simplify the transition
to Automake 2.0 (when the 'subdir-objects' will always be enabled
unconditionally), we believe they are acceptable to be shipped with
Automake 1.14.
With this patch, we also revert some of the testsuite adjustments done
in previous commit v1.13.2-178-g9877109 of 2013-05-24 (compile: rewrite
AC_PROG_CC with AM_PROG_CC_C_O contents). Such adjustments are no longer
needed.
* m4/minuso.m4 (_AM_PROG_CC_C_O): New internal macro, basically and
adjusted version of a merge between Autoconf-provided AC_PROG_CC_C_O
and our old implementation of AM_PROG_CC_C_O.
(AM_PROG_CC_C_O): Redefine as a simple wrapper around AC_PROG_CC.
* m4/init.m4 (AC_PROG_CC): Append _AM_PROG_CC_C_O, not AM_PROG_CC_C_O,
to the pre-existing expansion of this macro.
* m4/ar-lib.m4 (AM_PROG_AR): No longer require it to be expanded after
AC_PROG_CC.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after AC_PROG_RANLIB
and AM_PROG_AR invocations. Things should work this way too (as they
used to).
* t/subobj-clean-lt-pr10697.sh: Likewise.
* t/alloca.sh: Move AC_PROG_CC invocation after AM_PROG_AR invocation.
* t/condlib.sh: Likewise.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after LT_INIT and
AM_PROG_AR invocations. Make autoconf and autoheader warnings fatal.
* t/am-prog-cc-c-o.sh: Adjust to the new semantics, enhance a little,
and reduce code duplication.
* t/ccnoco.sh: Make autoconf warnings fatal.
* t/subpkg.sh: Likewise.
* t/ccnoco-lib.sh: Likewise, and fix a comment.
* t/link_cond.sh: Enhance a couple of error messages.
* configure.ac: Drop "nullification" of AM_PROG_CC_C_O.
* NEWS: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168
#! /bin/sh
# Copyright (C) 1998-2013 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Removing subdir objects does not cause too much 'rm' invocations.
# Also, if we rename a source file in a subdirectory, the stale
# compiled object corresponding to the old name still gets removed
# by "make mostlyclean". See automake bug#10697.
# This is the libtool case. Keep this test in sync with sister test
# 'subobj-clean-pr10697.sh', which deals with the non-libtool case.
required='cc libtoolize'
. test-init.sh
cat >> configure.ac << 'END'
AM_PROG_AR
AC_PROG_LIBTOOL
AC_PROG_CC
AC_OUTPUT
END
oPATH=$PATH
ocwd=$(pwd) || fatal_ "getting current working directory"
# An rm(1) wrapper that fails when invoked too many times.
mkdir rm-wrap
max_rm_invocations=6
count_file=$ocwd/rm-wrap/count
cat > rm-wrap/rm <<END
#!$AM_TEST_RUNNER_SHELL -e
count=\$((\$(cat '$count_file') + 1))
if ! test \$count -le $max_rm_invocations; then
echo "rm invoked more than $max_rm_invocations times" >&2
exit 1
fi
echo "\$count" > '$count_file'
PATH='$oPATH'; export PATH
exec rm "\$@"
END
chmod a+x rm-wrap/rm
echo "0" > rm-wrap/count
cat > Makefile.am <<'END'
.PHONY: sanity-check-rm
sanity-check-rm:
rm -f 1
rm -f 2
rm -f 3
rm -f 4
rm -f 5
rm -f 6
rm -f x && exit 1; :
echo "0" > rm-wrap/count
AUTOMAKE_OPTIONS = subdir-objects
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = \
sub1/a.c \
sub1/b.c \
sub1/c.c \
sub1/d.c \
sub1/e.c \
sub1/f.c \
sub2/a.c \
sub2/b.c \
sub2/c.c \
sub2/d.c \
sub2/e.c \
sub2/f.c \
main.c
END
mkdir sub1 sub2
echo 'int libmain (void)' > main.c
echo '{' >> main.c
for i in 1 2; do
for j in a b c d e f; do
echo "void $j$i (void) { }" > sub$i/$j.c
echo " $j$i ();" >> main.c
done
done
echo ' return 0;' >> main.c
echo '}' >> main.c
cat main.c # For debugging.
libtoolize
$ACLOCAL
$AUTOCONF
$AUTOMAKE -a
./configure
# The use of this variable is only meant to keep us better in sync
# with the sister test 'subobj-clean-pr10697.sh'.
OBJEXT=lo
$MAKE
# This must go after configure, since that will invoke rm many times.
PATH=$ocwd/rm-wrap$PATH_SEPARATOR$PATH; export PATH
$MAKE sanity-check-rm || fatal_ "rm wrapper doesn't work as expected"
$MAKE mostlyclean
ls -l . sub1 sub2
for i in 1 2; do
for j in a b c d e f; do
test ! -e sub$i/$j.o
test ! -e sub$i/$j.obj
test ! -e sub$i/$j.lo
test -f sub$i/$j.c || exit 99 # Sanity check
done
done
PATH=$oPATH; export PATH
rm -rf rm-wrap
$MAKE clean
$MAKE
test -f sub1/a.$OBJEXT
test -f sub2/d.$OBJEXT
$sleep
mv -f sub2/d.c sub2/x.c
rm -f sub1/a.c
sed -e '/ a1 ()/d' main.c > t
mv -f t main.c
sed -e '/sub1\/a\.c/d' -e 's|sub2/d\.c|sub2/x.c|' Makefile.am > t
mv -f t Makefile.am
using_gmake || $MAKE Makefile
$MAKE
test -f sub2/x.$OBJEXT
# The stale objects are still there after a mere "make all" ...
test -f sub1/a.$OBJEXT
test -f sub2/a.$OBJEXT
# ... but they get removed by "make mostlyclean" ...
$MAKE mostlyclean
test ! -e sub1/a.$OBJEXT
test ! -e sub2/d.$OBJEXT
# ... and do not get rebuilt ...
$MAKE clean
$MAKE all
test ! -e sub1/a.$OBJEXT
test ! -e sub2/d.$OBJEXT
# ... while the non-stale files do.
test -f sub1/b.$OBJEXT
test -f sub2/x.$OBJEXT
: