It seems like it would be logical to have AC_PROG_CC always run before
AC_PROG_CPP (since this turns out to be `$CC -E' in lots of cases).
In aclang.m4, there is:
dnl FIXME: can't do this because then AC_AIX won't work due to a
dnl circular dependency.
dnl AC_BEFORE([$0], [AC_PROG_CPP])
Why is
AC_TRY_CPP only looks at stderr of the result from the preprocessor,
not at stdout. Solaris' broken cc, aka /usr/ucb/cc, prints a message
to stdout to say that it's actually not installed, so you end up
trying to run that instead. The patch for looking at both stdout and
stderr is appended at en
On 7 Aug 2000, Assar Westerlund wrote:
> AC_TRY_CPP only looks at stderr of the result from the preprocessor,
> not at stdout. Solaris' broken cc, aka /usr/ucb/cc, prints a message
> to stdout to say that it's actually not installed, so you end up
> trying to run that instead. The patch for loo
Mo DeJong <[EMAIL PROTECTED]> writes:
> A better question would be "is it wise to fallback on /lib/cpp even
> if it does not exist?"
Since `it does work' is a stricter test than `it does exist', and
that's the test that's performed for the other choices in AC_TRY_CPP,
I think that's the right ans
What's the best way to handle getting header template stuff from a local
macro into acconfig.h?
It looks like aclocal does not scan acinclude.m4, which seems to be a
logical place to look if one doesn't want to have to maintain local "check"
information in 2 places...
H
