autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CPP determined incorrectly


From: Pavel Roskin
Subject: Re: CPP determined incorrectly
Date: Wed, 13 Jun 2001 12:12:35 -0400 (EDT)

Hello, Ralf!

[I'm dropping address@hidden since the discussion concentrates on
Autoconf.]

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

This brings an interesting idea. How about AC_LANG(none)? In this mode any
checks involving compilers will be disallowed. AC_PROG_CPP will default to
"cpp" in $PATH with "/lib/cpp" being the fallback.

Unfortunately this doesn't address the problem of declaring some compilers
optional, but it hopefully should allow merging AC_PROG_CPP and
AC_PROG_CC.

I.e. if the language is C then both AC_PROG_CPP and AC_PROG_CC call the
same private macro made of their current code. If the language is none
then AC_PROG_CPP sets CPP=cpp and AC_PROG_CC is not allowed (or it works
as if the language was C but emits a warning).

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

Right, but we have legacy code that calls AC_PROG_CPP before AC_PROG_CC in
assumption that header checks are allowed after this point.

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

CPP is used to check some properties of the C compiler that don't require
compilation to the object code. E.g. checks for existance of headers and
checks for defines.

This should have been done transparently for the user. I don't care what
confure does to ensure that I can include that header. But it wasn't
transparent from the beginning.

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

I agree. CPP here is just a checking tool. In fact I believe that
configure should use full compilation to the object files if "$CC -E"
doesn't work instead of resorting to a random "cpp".

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

Yes, it's a different usage. It may be a macro with a new name, e.g.
AC_PROG_C_PREPROCESSOR, or AC_PROG_CPP called after AC_LANG(none).

-- 
Regards,
Pavel Roskin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]