autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: possibly undefined macro: dnl (Was: Autoconf 2.50 is released)


From: Lars J. Aas
Subject: Re: possibly undefined macro: dnl (Was: Autoconf 2.50 is released)
Date: Tue, 22 May 2001 14:48:57 +0200
User-agent: Mutt/1.2.5i

On Tue, May 22, 2001 at 02:37:33PM +0200, Akim Demaille wrote:
: >>>>> "Lars" == Lars J Aas <address@hidden> writes:
: Lars> Since this error message always uses the line-number of the
: Lars> first macro and not the failed macro, couldn't we change scheme
: Lars> to insert a line like the following in `configure' for each
: Lars> top-level macro invocation (hopefully easy to detect)?:
: 
: Lars> #line configure.ac:43
: 
: Lars> Then we can scan for the last line of that kind before the first
: Lars> occurence of the macro name in `configure' and output that the
: Lars> problem is somewhere below that point.
: 
: That would considerably slow down Autoconf, not to mention the
: difficulty to implement this without polluting genuine output.

I don't mind a slow autoconf, only slow configure scripts.  However, I
agree Autoconf should be as fast as we can make it too.

: In addition, I don't understand why you limit this to top level
: invocations.

If you don't, you would have to trace your way into aclocal.m4, and
aclocal.m4 would have to know which files it was made up of.  Just knowing
the general area in configure.ac is a big help - not knowing (and actually
being misinformed by Autoconf) can be a big problem.

Anyhow, maybe Autoconf could have a "speedy" best-case run-through that
will generally generate the configure script, but if it fails Autoconf
does a slow tracing/instrumenting run-through that will enable it to pin-
point problems more precisely than what the best-case run can do?

  Lars J
-- 
(list->string '(#\l #\a #\r #\s #\a #\@ #\s #\i #\m #\. #\n #\o))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]