On Wed, Aug 01, 2001 at 07:40:38PM +0200, Akim Demaille wrote:
: 2. Everything is on top of autom4te, which is a Perl 5.5 script.
[...]
: fileutils-4.1 % time autoconf2.50; time autoheader2.50
: autoconf2.50 20,65s user 1,35s system 78% cpu 27,876 total
: autoheader2.50 21,40s user 2,23s system 75% cpu 31,483 total
:
: fileutils-4.1 % time autoconf; time autoheader
: autoconf 21,49s user 1,21s system 88% cpu 25,785 total
: autoheader 3,27s user 1,44s system 88% cpu 5,308 total
Wow, I just tried autoconf 2.52b and the speed improvement was incredible,
especially after I wrapped the aclocal-invokation in my bootstrap script
like this:
rm -f aclocal.m4.old
test -f aclocal.m4 && mv aclocal.m4 aclocal.m4.old
aclocal -I $MACRODIR
if test -f aclocal.m4.old; then
if cmp -s aclocal.m4 aclocal.m4.old; then
echo "aclocal: aclocal.m4 is unchanged"
rm -f aclocal.m4
mv aclocal.m4.old aclocal.m4
else
rm -f aclocal.m4.old
fi
fi
Then even the autoconf run was down to mere seconds when I didn't cause
any change to aclocal.m4.
The way autom4te works now, it recreates the cache every time aclocal.m4
is timestamped fresher than the current cache. Since I always bootstrap
with a script (and I know a lot of other guys out there do too), I always
run aclocal and therefore always have to recreate the cache. The above
trick fixes it of course, but I haven't studied the side-effects it may
have on automake Makefiles etc. yet.
I'm therefore proposing the following:
1) if the above approach is safe, that fuctionality is built into aclocal
the way autoheader preserves config.h when there's no change.
2) if it is unsafe (messes up for make rules?), a checksum system is built
into autom4te so it can compare the checksum of the aclocal.m4 file the
cache was created for with the checksum of the current aclocal.m4 file,
and choose to just "touch" the cache when the checksum is the same.
The downside to this speedup is that Autoconf 2.53 will make Automake look
bad :)
Lars J
