[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [patch] faster Makefile.in -> Makefile translation
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-04-01 17:36:29
[Download RAW message or body]

Michael Matz wrote:
> 
> Hi (esp. coolo, David and people interested in configure),
> 
> as everybody knows, the most time in configure-ing a package is taken by
> the process to substitute all @xx@ variables from Makefile.in into the
> actual values in Makefile. Unfortunately this affects not only developers,
> but also users which compile from source (or are using snapshots).
> (I'm talking about 'creating <path>/Makefile')
> 
> Last night I had finally enough, and decided to rewrite the main loop from
> config.status in perl. After some battling with autoconf there was a
> result, which you can find in the attached patch.
> 
> Timings for one config.status run (wich recreates all Makefiles, and is
> also run by configure):
> package        old config.status    new config.status
> kdelibs        2m59.425s            0m12.920s
> kdebase        6m17.323s            0m21.872s
> kdemultimedia  1m6.419s             0m4.454s
> kdegraphics    1m2.160s             0m3.785s
> 
> So it's nearly 18 times (!) as fast.
> Of course I had tested the generated Makefiles, if they differ with this
> new method. No differences. I've tried it with srcdir!=blddir. The
> create_makefile script also works with the new method (and is real fast
> now ;).
> 
> To try it, just apply the patch into kde-common. Then normally
> 'make -f Makefile.cvs' . There is a new configure switch
> (--enable-fast-perl), which activetes the new behaviour.
> 
> If this switch is not given, the old method is invoked. Beware, that you
> must have perl in PATH by the time you run configure or config.status, and
> that .../admin/config.pl is accessible, if you want use this switch.
> This would also have to be distributed with snapshots and sources.
> 
> To integrate the script into the configure mechanism I had to hack two
> methods from autoconf (AC_OUTPUT and AC_OUTPUT_FILES, now called
> KDE_OUTxxx). I used autoconf 2.13 as base. I'm interested if there are any
> problems with other autoconf versions. Basically instead of using
> AC_OUTPUT in configure.in you now use KDE_OUTPUT. I've changed
> Makefile.common to generate configure.in this way. The problem is, that
> automake depends on AC_OUTPUT to find the Makefile.am's, so right now
> Makefile.common generates AC_OUTPUT, and just before autoconf is called it
> replaces it with KDE_OUTPUT. (Hacky, I know. But one can't simply redefine
> autoconf methods, if the frozen version of autoconf is used, which is the
> case most times).
> 
Well, I wanted to do this since ages - be asured. A KDE_OUTPUT is no
problem,
we already abstract from pure automake/autoconf syntax enough ;)

I would even make it default and check for perl - I'll review your patch
tonight and commit it then.

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

[prev in list] [next in list] [prev in thread] [next in thread]