| > 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).
Do you know such places? (A cpp and no cc).
| * In rare occasions, only a functional cpp is required, but a broken
| cc is tolerable (eg. to process *.S -> *.o)
I don't think we need AC_PROG_CPP here, all you need is an
AC_CHECK_PROG, or somewhat improved if needed. But AC_PROG_CPP is
much more than this, and is completely bound to CC. E.g.,
AC_CHECK_HEADERS is addressed by CPP, not CC etc.
| * Some OS do not have a functional cc, but have a functional
| /lib/cpp
| (IIRC, Solaris-2.7 by default has the infamous /usr/ucb/cc script,
| but has a functional /lib/cpp).
Again, I believe that you just want an AC_CHECK_PROG(CPP), not
something so closely bound to the C language.
