----Original Message----
>From: Joe Buck
>Sent: 03 May 2005 23:04
> On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
>> At this point, it doesn't feel like switching to 1.5.16 is worth the
>> effort. 2.0 should be far more maintainable, and hopefully
>> significantly more efficient on hosts where the use of shell functions
>> optimized for properties of the build machine and/or the host
>> machine can bring us such improvement.
>
>> Thoughts?
>
> Richard Henderson showed that the libjava build spends 2/3 of its time
> in libtool, and that his hand-hacked (but not portable) modification to
> invoke the appropriate binutils commands directly gave a huge speedup.
> To me, 300% overhead means major breakage, so we need a better libtool.
> However, this better libtool might not yet exist.
Ok, here's a really *nasty* kludge: libtool is basically a big script
that generates command lines for the other tools based on passed-in args and
local configure settings, yeh? And a lot of the time it's used for lots and
lots and lots of library files one after another in exactly the same way,
yes?
So couldn't quite a lot of its uses be replaced in the makefile machinery
with something that invokes it just once (for a given batch of library
source files in a single build object subdir), and records the command line
that it generates, and just uses sed to duplicate all the different source
and object file names into the right places in many repetitions of it?
I did a little experiment. I took a recent build directory of HEAD. I
keep all the output from the build process in a script file, so I fetched
all the lines that invoke libtool with
grep -B0 -A1 libtool build.log | grep -v -- ^-- > libt.txt
This hopefully gets the libtool invocation and the command line that
libtool generates. It also gets a few false positives, such as mentions in
configure output, but they're a small number. The output contains 761
lines, 744 of which are unique.
[EMAIL PROTECTED] /gnu/obj-HEAD> grep -B0 -A1 libtool build.log | grep -v --
^-- >
libt.txt
[EMAIL PROTECTED] /gnu/obj-HEAD> wc -l libt.txt
761 libt.txt
[EMAIL PROTECTED] /gnu/obj-HEAD> sort < libt.txt | uniq | wc -l
744
[EMAIL PROTECTED] /gnu/obj-HEAD>
Then I use sed to replace all the names of source and object files I can
find with dummy text:
[EMAIL PROTECTED] /gnu/obj-HEAD> sed < libt.txt -e 's/[-a-zA-Z0-9_]*\.cc/SRC/g'
-e '
s/[-a-zA-Z0-9_]*\.o/OBJ/g' -e 's/[-a-zA-Z0-9_]*\..o/OBJ/g' -e
's/[-a-zA-Z0-9_]*
\.c/SRC/g' -e 's/[-a-zA-Z0-9_]*\.f90/SRC/g' -e 's/[-a-zA-Z0-9_]*\.m/SRC/g'
>lib
t2.txt
Now look what that does!
[EMAIL PROTECTED] /gnu/obj-HEAD> wc -l libt2.txt
761 libt2.txt
[EMAIL PROTECTED] /gnu/obj-HEAD> sort < libt2.txt | uniq | wc -l
63
[EMAIL PROTECTED] /gnu/obj-HEAD>
If I manually edit out the false positives from that, there are only 41
lines.
Now, libjava wasn't included in this build because it seems to be disabled
on cygwin target, but it's probably much the same. So ISTM that vast
swathes of libtool invocations could be replaced by a far simpler generation
of command lines from templates, with a bit of help from libtool to generate
the templates. Give libtool an option where it only generates the command
line instead of invoking it, pass it args that look like "-c SRC" and "-o
OBJ", and then postprocess it to substitute real names in.
Is there some terrible gotcha that I don't understand libtool well enough
to see here?
cheers,
DaveK
--
Can't think of a witty .sigline today....
