CPP determined incorrectly

[Pavel Roskin]

Hello!

First of all, sorry for cross-posting, but as you will see it's hard to
decide whether Automake or Autoconf is guilty.

I have noticed Automake testsuite failures in distname.test, subobj5.test
and subobj6.test on OpenBSD 2.7 with the CVS head versions of Autoconf and
Automake.

It turns out that configure probes for preprocessor when $CC is empty.
/lib/cpp is the last fallback, but OpenBSD doesn't have it. The same tests
would pass on Linux, but configure will erroneously set CPP=/lib/cpp.

How to reproduce the problem:

$ cat <<EOF >configure.in
AC_INIT
AM_INIT_AUTOMAKE(nonesuch, 0.23)
AC_PROG_CC_C_O
AC_OUTPUT
EOF
$ aclocal; automake -a; autoconf
$ ./configure | grep /lib/cpp
====> checking how to run the C preprocessor... /lib/cpp

The problem goes away if Automake 1.4 is used (actually, aclocal from
Automake 1.4).

It appears that AM_INIT_AUTOMAKE does something with AC_PROG_CC so that
the later cannot be AC_REQUIRE'd. This configure.in would exhibit the
problem as well:

AC_INIT
AC_DEFUN([AC_FOO], [AC_REQUIRE([AC_PROG_CC])])
AM_INIT_AUTOMAKE(nonesuch, 0.23)
AC_FOO
AC_OUTPUT

I don't know whether Autoconf should be more robust or Automake should
take less (or more?) hackerish approach.

Since Autoconf-2.50 has been released, it would be fair to drop support
for Autoconf-2.13 and use new facilities for attaching dependency code to
AC_PROG_CC (provided that they exist and I understand the problem
correctly).

-- 
Regards,
Pavel Roskin