RE: fast install released already?

[Duft Markus]

> 
> Hello Markus,
> 
> * Duft Markus wrote on Tue, Oct 21, 2008 at 11:51:26AM CEST:
> >
> > I just wanted to ask wether the fast install bits are available
> already
> > in a released automake version?
> 
> No, not yet.  A few questions (unrelated to fast-install) have turned
> out to be more work than expected, so the alpha release I was aiming
> for
> will be another couple of weekends at least.
> 
> > Is there a single big patch for a current version? I'd really like
to
> > start using this feature, since installing out software takes hours
> :)
> 
> You can grab the git version of Automake for now.  It is available
> here:
> <https://savannah.gnu.org/git/?group=automake>
> (you can browse the git history, there are "snapshot" links that give
> you a tarball to use, if you are not comfortable checking out with
> git).

Ok, i'll have a look at it. Actually I spend some time on this
yesterday, and quickly patched up our bootstrapping tool (confix
http://www.sf.net/projects/confix) to generate install rules for header
files itself, and not let automake do the work. This way I'm now about
factor 4 faster ;) still I would like automake to be fast, since I did
the job only for headers (ok, that's the fast majority right now, but
who knows...).

> 
> > we have approximately 10.000 files to install (headers (approx.
> 9000),
> > libs (approx. 700), scripts (a few :))).
> 
> Wow.  It would be interesting to see how much faster things get with
> the
> chances.  Are the libraries all created with libtool?  Because then I
> guess they will end up being the remaining bottleneck (that would be
> interesting to see, too).

The libs are all static right now, but i already prepared for switching
to libtool. All libs have been built with libtool already, and yes,
you're right, it is somewhat slow. It even is too slow, so that my boss
said "don't enable this, it will make our nightly build times explode".
I will have to find a solution for this. Actually I narrowed down the
performance issues in libtool to the .la file handling. Since Confix
puts all dependent libs on the command line, I was thinking about
disabling that completely, and treat all libs like there where no .la
files around.

Another thing to note, is that those 700 libs are our main software
only. There is a "toolsbox" which contains tons of other software, which
makes up another approximately 1000 libs. This bunch is made up of many
open source packages (gcc, autotools, pkg-config, orbit2, glib, etc.)
and many of our own packages. This whole thing uses libtool throughout,
with (still) a few exceptions.  So there is much more to tune :)

> 
> > If interested, I could also do some performance measurements with
and
> > without this...
> 
> Yes, that would be cool.

It will take some time though, since building our software is not too
fast, and I have tons of other work to do. Performance tuning is kind of
a hobby at work ;)

> 
> > we currently use automake 1.9.6, and it would be best if
> > we don't have to touch any of our files (autoconf 2.59, libtool
> 1.5.24,
> > m4 1.4.4), is this possible?
> 
> That's a bit tough.  What prevents you from updating to
>   Autoconf 2.63
>   Automake 1.10.1
>   Libtool 2.2.6
>   M4 1.4.12
> 
> which are the current versions?

Phew... this is quite a big jump for our rather old stuff. I've seen in
gentoo that there _are_ quite a few issues when switching to libtool 2,
so I'd really like to stick with 1.5.* in this version of our software.
I think there where also issues when switching autoconf, but I don't
think too many, so maybe I'll give it a try. M4 should be ok, I guess.
Shouldn't this be more or less compatible?

Cheers, Markus

> 
> Note that all incompatibilities between git Automake and older
releases
> should be listed in the NEWS file.
> 
> Hope that helps.
> 
> Cheers,
> Ralf