>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
* acspecific.m4 (AC_PROG_CPP): New macro.
Then
Fri May 15 00:57:01 1992 David J. MacKenzie ([EMAIL PROTECTED])
* 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 ([EMAIL PROTECTED])
* 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.
