> The only downside to this patch is the fact that
> AC_PROG_CC and AC_PROG_CXX now rely on the
> AC_CHECK_TOOL_PREFIX macro which depends on
> AC_CANONICAL_HOST and AC_CANONICAL_BUILD.
I think this is abnormal: since AC_CHECK_TOOL is only interested in
user's input, in theory there is just no re
I realize the patch is not very readable. Sorry about this, here are
the most interesting differences:
BEFORE:
< # AC_CANONICALIZE(THING)
< # --
< # Canonicalize the appropriate THING, generating the variables THING,
< # THING_{alias cpu vendor os}, and the associated cache
Has anyone ever run into a problem like this before?
I ran autoconf and it started sucking up all my CPU
time. Here is the configure.in that causes the problem.
mo(~)% autoconf
/usr/bin/m4: memory exhausted
AC_INIT(foo)
AC_DEFUN(FOO, [
foo_cmd="$FOO $FOO_FLAGS arg"
echo $foo_cmd
])
FO
Perhaps I am just doing something stupid here, but I just can
not figure out why autoconf is printing a warning for this
configure.in file.
% cat configure.in
AC_INIT(foo)
AC_DEFUN(FOO, [
foo_cmd="$JAVAC $JAVAC_FLAGS Test.java"
echo $foo_cmd
])
FOO
% autoconf
autoconf: undefined macro
On May 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> AC_DEFUN(FOO, [
> foo_cmd="$FOO $FOO_FLAGS arg"
After expanding FOO, it will look at the expansion to see if there's
any macro to be expanded. It finds FOO, and goes expand it, and so
on.
--
Alexandre OlivaEnjoy Guaraná, see http
On May 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> autoconf: undefined macros:
> configure.in:5:foo_cmd="$JAVAC $JAVAC_FLAGS Test.java"
Note the occurrence of `AC_[_A-Za-z0-9]*' in the output. I think we
should arrange for the macro to match only if AC is in the beginning
of a line or
