----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....