Re: CPP determined incorrectly

[Pavel Roskin]

Hello, Ralf!

> >         How about merging AC_PROG_CPP and AC_PROG_CC together?
> >
> >         What's the point of keeping the two of them?
> * Some tools (eg. imake) apply cpp as macro-processor, even if cc is
> not available on a particular installation. Other tools might want
> to apply these tools even if not using *.c at all (Eg. using Imake
> with non-c-languages).

Strictly speaking, it's another problem. In most cases if CPP is needed
the best choice is "$CC -E". Testing for CC may be useful even if there
are no C files in the project or they aren't used in the core of the
project, i.e. lack of working CC is tolerable.

I don't care much if we test for CC and don't use it. But I do care that
the failure to find CC (CXX, F77) can be tolerated if the package
maintainer wants it.

In fact, it's not unreasonable to have examples in C++ for a library
in C. Typical examle is ncurses. I even remember two (!!!) ways to
override the "fatality" of the compiler tests I saw in some projects
(don't remember their names, sorry):

1) Use parentheses:

(AC_PROG_CXX)

2) Redefine AC_MSG_ERROR. Something like this:

define([save_AC_MSG_ERROR], defn([AC_MSG_ERROR]))
define([AC_MSG_ERROR], defn([AC_MSG_WARN]))
AC_PROG_CXX
define([AC_MSG_ERROR], defn([save_AC_MSG_ERROR]))

You are right in the sence that calling AC_PROG_CC (i.e. what it is now)
form AC_PROG_CPP may force even more people to use such hacks. But it's
not what we are discussing.

Preprocessor in an integral part of the compiler. Testing the compiler
without preprocessor makes no sence. Testing the preprocessor without
testing for a working compiler is reasonable, but in many cases "$CC -E"
is preferred over /lib/cpp, so it's a good idea to test for the compiler
anyways.

> * In rare occasions, only a functional cpp is required, but a broken
> cc is tolerable (eg. to process *.S -> *.o)

If a broken cc is tolerable then you should have a mechanism to instruct
configure not to abort. This is quite orthogonal to the preprocessor test.

-- 
Regards,
Pavel Roskin