[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

speedy config.status (was: [PATCH] echo -n is not portable and used too much)

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-20 00:25:14 CET

On Fri, Feb 15, 2002 at 12:50:11PM -0800, Blair Zajac wrote:
> But I use it myself on my projects to automatically rebuild Makefile from
> Makefile.in if I modify Makefile.in. The good thing about updating Makefile
> using this build rule is that it saves typing by passing to config.status
> via the CONFIG_FILES environmental variable the only files to regenerate,
> so it can be faster. Since svn's config.status only updates three files,
> this isn't a big deal.

Our "three files" (which is actually two: you sometimes get a line saying
"svn_private_config.h is unchanged") was Yet Another Benefit of using a
single, top-level Makefile.

If you look at the Apache httpd configure process, you'll find a whole lot
of gunk called "FAST_OUTPUT" or somesuch. The intent there is to create a
system that replaces AC_OUTPUT() when you have a ton of files, and a ton of
symbols. The underlying problem is that 'sed' is used to do the AC_OUTPUT,
and when you have a gazillion symbols, then autoconf has to work extra hard
(read: it is extra slow) for *each* file.

So... to speed things up, Apache goes through a whole separate (!!)
mechanism to get reasonable speed when generating those output files. If it
moved to a single Makefile, then things would be much more bearable. There
is probably a good amount of symbol reduction that could be done, too (I
believe the mechanism was added before APR was created, so Apache had all
those gazillion platform test symbols).

In any case... Subversion wins big time in config.status by virtue of a
single Makefile. That is the only file listed in AC_OUTPUT().


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.