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: Ralf Corsepius
Subject: Re: possibly undefined macro: dnl (Was: Autoconf 2.50 is released)
Date: Wed, 23 May 2001 02:54:43 +0200

"Lars J. Aas" wrote:
> 
> 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. 
Hmm, IMHO, autoconf already has reached a point where any further
regression in speed is hardly bareable for developers.

A real-world example:

A deep source tree with autoconf/automake-based configuration:
* w/o auto*-generated files:
148 configure.ins
976 Makefile.ams
~8400 source-files.
# du -b -s
51308544

* With autoconf-2.13 and automake-1.4:
# time bootstrap
real    7m28.684s
user    6m21.420s
sys     0m31.700s
# du -b -s
77718016

* With autoconf-2.49f and automake-1.4:
# time bootstrap
real    14m50.798s
user    13m3.660s
sys     1m3.860s
# du -b -s
83329536

=> autoconf is ~factor 2 slower.
=> 32MB of auto* generated files instead of 26MB (In comparison to
51MB actual source code)


* Running a sample configuration w/ ac-2.13/am-1.14
real    5m1.000s
user    3m31.820s
sys     0m52.450s

* Running a sample configuration w/ ac-2.49f/am-1.14
real    3m45.728s
user    2m2.400s
sys     1m11.910s

=> ~1/3 faster

Compare the orders of these figures. The regression in bootstrapping
the configuration by far outweights the improvements in
configuration speed. Admitted, this is an extreme case and normal
users rarely will bootstrap the configuration, but .. this is on a
slow to medium fast Linux-PC with local disks. You really do not
want to know what happens under Cygwin, Old Sparcs IIs or if using
nfs-mounted filesystems. 

> However, I
> agree Autoconf should be as fast as we can make it too.
Definitely.

Ralf



reply via email to

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