Hello, Akim!
> | By the way, shouldn't we change the syntax of AC_LANG to
> |
> | AC_LANG(C, COMPILERS, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
> |
> | and go ahead if no C compiler has been found but ACTION-IF-NOT-FOUND is
> | given?
>
> What advantage would that bring? How do you deal with th
| Hello, Ralf!
| > checking how to run the C preprocessor... cc -E
| > checking for sh-rtems-gcc... sh-rtems-gcc
|
| It's a separate problem that needs to be addressed before 2.50.
| AC_PROG_CPP should require AC_PROG_CC.
Right.
| Maybe we should go as far as to make both AC_PROG_CPP and AC_PR
Hello, Ralf!
> checking how to run the C preprocessor... cc -E
> checking for sh-rtems-gcc... sh-rtems-gcc
It's a separate problem that needs to be addressed before 2.50.
AC_PROG_CPP should require AC_PROG_CC.
Maybe we should go as far as to make both AC_PROG_CPP and AC_PROG_CC
obsolete in favo
Akim Demaille wrote:
>
> Thanks for the report, it's a known bug. In fact this bug is not new,
> what is new is that the core machinery now correctly catches it.
With your patch, it seems to be hidden, but present, again.
I.e. your patch solves part of the problem, but another one remains.
>
Thanks for the report, it's a known bug. In fact this bug is not new,
what is new is that the core machinery now correctly catches it.
The problem is related to the fact that AC_PROG_CC can be expanded
twice, and since the first expansion expands AC_PROG_CPP, the second
expansion of AC_PROG_CC w
