Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 18 Jul 2002 02:08:34 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
To: dev@apr.apache.org
Subject: Experimental libtool replacement?
Message-ID: <20020718090834.GB17660@apache.org>
Mail-Followup-To: Justin Erenkrantz <jerenkrantz@apache.org>,
	dev@apr.apache.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i

Last week, I got really frustrated at how slow the builds were on
my TiBook.  So, I started playing around with libtool and discovered
that on Darwin, it is taking about 30-45 seconds to *parse* the
arguments list when compiling any shared libraries.  Ugh.

I tried to narrow it down to a specific problem in libtool and
I couldn't (tried their CVS snapshots too).  I also tried to
replace my shell with various alternatives (such as /bin/bash
which is what 10.2 will make /bin/sh).  Just pure suck.

So, I started taking a jackhammer to our aplibtool.c and tried
to get it to work on Darwin.  I've now managed to get it to build
and link successfully as a drop-in replacement to GNU libtool.

To give you an idea of the performance improvement in compilation
times of just the APR library itself:

make all  14.16s user 11.00s system 71% cpu 35.270 total
make all  197.29s user 85.93s system 80% cpu 5:53.41 total

The first number is with my custom libtool replacement and the
second one is with GNU libtool.  (I'm not kidding.)  Yes, a
clean full build now takes as long as it took libtool to parse
its options.

I've also managed to get it working on Linux, but Linux doesn't
have the same performance problems as Darwin.

However, I said it built and linked successfully.  My problem now
is getting it to install the right libraries.  What we need to do
is relink once more at install time.  Actually, I think we could
link twice at link stage - one with our fake rpaths and another
one with the 'real' rpaths.

Yet, this has gotten to be more than I can handle with my current
load.  I also think I've stretched the limits of the current
aplibtool.c infrastructure (and I've replaced a fair amount of the
code).  So, my question is whether anyone is interested in my
changes and willing to further it.

I would be willing to commit what I have to APR's repository and
add-in the various patches I've been using to get it to compile
(minor oversights in our build system and autoconf option).  I
won't try and hide the fact that what I have isn't pretty.  It's a
hack.  And, I'm not going to spend the time to clean up the code.
It might be better to start from scratch.  But, I can't do that now.

You may find the necessary patches and source code at:

http://www.apache.org/~jerenkrantz/jlibtool/

If no one is interested, I will attempt to finish it on the side.
But, I hope I've whetted my fellow Darwinites appetite for
faster builds.  It's possible.  I've been to the promised
land.  -- justin