Re: CPP determined incorrectly

[Ralf Corsepius]

Pavel Roskin wrote:
> 
> Hello, Ralf!
Hi Pavel,
 
> > >         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.
ACK.

> 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]))

Another "hack" is not to use AC_PROG_* but to write own checks.

> 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.
Hmm, I would not sign this sentence :) 

As a matter of fact, on some systems /lib/cpp is shipped
independently from the compiler (Solaris)

> Testing the compiler
> without preprocessor makes no sence.
ACK.
 
> 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.
Hmm, my opinion is different: If CC is required and works, then
checking for CPP="$CC -E" is a good idea, but IMHO the other way
round is doubious.

I.e.
Using CC implies using CPP.
Using CPP does not imply using CC.


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

I would assume: 
* Some autoconf-users wanted to use CPP without CC (I have even seen
cases were a host's native cpp have been applied to preprocess *.S
to be processed with cross-assemblers :) ).
* There might exist toolchains which require explicitly calling cpp
instead of CC -E (This would imply having to check for a working CC
-E first and falling back to trying cpp if this fails).
* History (Probably stemming from dependency-tracking)

> > * 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.

What I had in mind was as configure.in containing something like
this:

AC_PATH_PROGS(CPP,cpp /lib/cpp)
AC_PATH_PROG(AS,as)

vs. a configure.in containing:
AC_PROG_CPP
AC_PATH_PROG(AS,as)

The second example however will fail if CPP is coupled to CC,
because AC_PROG_CPP somehow will have to require CC. If this is done
by using AC_PROG_CC, it will check for a working CC. I.e. on a
Solaris system this configure will fail.


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

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

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


Ralf