Re: Dropping CPP for AC_CHECK tests? (Was: CPP determined incorrectly)

[Pavel Roskin]

Hello, Akim!

> My feeling is that CPP, here, was used only for performance issues.

Yes, this was my point. The whole idea of dealing with preprocessor was to
speed up checks for tests, _not_ to find CPP that the user should run
directly.

However, it was abused later. Header checks were used to identify the host
system (see e.g. AC_AIX and AC_MINIX). Thus CPP became a tool for that,
competing with config.guess and the "--host" option.

I believe that there were attempts to use that information while choosing
the flags for that compiler, but they were dropped because of the
chicken-and-egg problem.

In fact, it should be easy to solve this problem if the internal
implementation is not exposed to the user.

How the "big" AC_PROG_CC could work:

1) find $CC
2) find $CPP from "$CC -E" ... "/lib/cpp" (not sure about the last one)
3) check properties of the host (MINIX, AIX etc)
4) adjust $CC (add host-specific flags)
4) adjust $CPP (add host-specific flags that affect preprocessing)

> But it's weakening the quality of the tests.

I don't understand this point. Do you mean that a header can have a code
that doesn't compile (e.g. invalid C constructs)?

The problem here is that many headers depend on other headers without
explicitly including them. It's not the case for GNU libc, but it's quite
common for other libraries, including non-GNU libc.

Some of those headers would not require any other headers to valid for the
proprocessor. But the validity as C code may require additional
dependencies.

We cannot switch from preprocessing to compilation without seriously
breaking backward compatibility.

-- 
Regards,
Pavel Roskin