Re: CPP determined incorrectly

[Ralf Corsepius]

Akim Demaille wrote:
> 
> | >         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).
> 
Well, it depends on how to interpret your question.

No, I do not have an actual example, but I have been using this
proceedure for my own work approximately 10 years ago. 

Furthermore, there exist several tools which (implicitly,
indirectly) apply _a_ cpp without directly needing a cc, eg.
* imake
* xrgb
* rpcgen
...

It also is fairly simple to construct such examples, e.g.
* applying imake to configure a sub-package of an otherwise
autoconfiscated collection of packages. 
* *.S -> *.o, applying /lib/cpp and $target-as (This case is a hack,
but it is not as seldom as you might assume!).

> | * 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.
Though I agree that this is a work around to get this functional, I
am inclinded to call this behavior broken. 
It is at least not what users will expect from using AC_PROG_XXX. 

They will assume AC_PROG_XXX to be specialized checks for XXX -
Here: A check for CPP and not for CC.
 
> | * 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.

Right, but this is not what I am talking about. I am talking about:
* Is AC_PROG_CPP a specialized check for a cpp? If yes, it must not
require cc.
* Is AC_PROG_CPP a subroutine of AC_PROG_CC|CXX? If yes, it should
not be public.
* Do AC_PROG_CPP require CC? If yes, the logic is twisted, IMO.
* Do we need to split AC_CHECK_CPP (checking for _a_ cpp) from a
AC_CHECK_CC_CPP (checking for the cpp required by a particular cc)?
At least I think so.

More generalizing:
* Is using AC_CHECK_PROG(<prog handled by other autoconf checks>)
legitimated/legal? My answer: No, unless you know what you are
doing.
* How to destinguish using [g]cc from directly using a particular
tool (Here gcc -E vs. cpp; more general also gcc -c vs. gcc -S,
$(AS) .. )

Ralf