Re: CPP determined incorrectly

[Akim Demaille]

>>>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

Ralf> This thought however raises another question: Why does
Ralf> AC_PROG_CPP exist at all?

Ralf> I would assume: * Some autoconf-users wanted to use CPP without
Ralf> CC (I have even seen cases were a host's native cpp have been
Ralf> applied to preprocess *.S to be processed with cross-assemblers
Ralf> :) ).  

MHO is just that at some time there was no reason to have them in a
single macro.  Today, Autoconf supports more languages, tests CPP and
CC much more carefully etc.  It's becoming a problem in itself.

If you look at the archive, you'll see that we struggled a lot on
these two guys.  Yet it's not over.

The former model, where is was `free' to have two macros, no longer
applies.

But again, this thinking is just based on my believing this is the way
AC_PROG_CPP was born.  ChangeLog is of no use, AFAICS.


(That's the *first* ChangeLog entry :)

Fri Apr 24 10:08:21 1992  David J. MacKenzie  (address@hidden)

        * acspecific.m4 (AC_PROG_CPP): New macro.

Then

Fri May 15 00:57:01 1992  David J. MacKenzie  (address@hidden)

        * acspecific.m4 (AC_PROG_CPP): Don't evaluate $CC until called.
        Try $CC -E before /lib/cpp.

Then

Mon Jun 15 21:27:49 1992  David J. MacKenzie  (address@hidden)

        * acgeneral.m4 (AC_REQUIRE, AC_PROVIDE): New macros.
        (AC_HEADER_EGREP, AC_PROGRAM_EGREP, AC_TEST_CPP): Use them.
        * acspecific.m4 (AC_PROG_GCC, AC_GCC_TRADITIONAL, AC_PROG_CPP,
        AC_PROG_FLEX, AC_INLINE): Ditto.


Ralf> * History (Probably stemming from dependency-tracking)

You envisioned it too :)


Ralf> Anyway, I am inclined to think we actually might be facing two
Ralf> issuses simulaneously:

Ralf> * CPP to be used by CC. Here, I do not understand why CPP is
Ralf> needed and available to users as a separate autoconf check at
Ralf> all. Unless I am missing something, IMHO, an implicit check
Ralf> inside of AC_PROG_CC etc. probably would be sufficient to
Ralf> provide an CCCPP or similar.  AFAIU, this is what Akim and you
Ralf> have in mind.

Yep!


Ralf> * CPP to be used as general tool. This is no way different from
Ralf> checking for and using any other arbitrary tool in
Ralf> autoconfizcated configurations.  However, presence of
Ralf> AC_PROG_CPP in autoconf's set of specialized tool-checking
Ralf> macros causes users to apply it as such (i.e. "I want CPP,
Ralf> AC_PROG_CPP exists, now I'll use it" :). IMO, this is a
Ralf> different usage than what I think you have in mind.

I think _this_ is a bad problem.

It's not clear how to be backward compatible, but for instance, I'd
like to merge AC_PROG_CPP into AC_PROG_CC, and then define
AC_CHECK_CPP as a mere PATH walk to find cpp.

All the heavy tests on CPP performed by AC_PROG_CPP are there *only*
to have AC_CHECK_HEADERS and so on work properly.