Hello, Akim!
> Are there any reasons not to merge AC_PROG_CPP into AC_PROG_CC? I'm
> in the process of having the test suite correctly run AC_PROG_CC
> before all the tests that need a compiler, that is, I am
> AC_LANG_COMPILER_REQUIRE for all the test that compile, link and/or
> run.
I agree (in principle) that it is better to have a big macro that checks
the compiler for the current language.
Maybe some checks will be useless for some small packages, but having some
basic tests bundled together increases the probability that they are used
properly and in the right order.
> I still face failures for macros using AC_TRY_CPP which do require
> AC_PROG_CPP, but since AC_PROG_CPP does not require AC_PROG_CC it ends
> up using ac_cpp='a-broken-cc -E', hence fails.
In this particular case you may want to wait for my patch for AC_PROG_CPP
(it's coming soon). My patch checks every preprocessor that it can
distinguish between missing and existing includes. Even if CPP if
specified, the sanity check is still performed.
Broken preprocessors that always fail or never produce warnings are
rejected.
> I see no advantage in keeping the macros separated, and in fact, I'd
> like to move the body of AC_PROG_CPP into AC_PROG_CC, and AU_DEFUN
> AC_PROG_CPP to nothing. Would that be wrong?
Maybe AC_PROG_CPP should expand to AC_PROG_CC (if it hasn't been used
before), so that CPP is not undefined between AC_PROG_CPP and AC_PROG_CC?
> I suppose the only real question is: are there any packages that use
> AC_PROG_CPP but not AC_PROG_CC? Can it make sense?
I cannot think of anything of that type. But still AC_PROG_CPP should not
be ignored - if it becomes part of AC_PROG_CC, then AC_PROG_CC should be
used.
Regards,
Pavel Roskin
