Hi Bob, others, * Bob Friesenhahn wrote on Thu, May 05, 2005 at 02:05:04AM CEST: > On Wed, 4 May 2005, Ralf Wildenhues wrote: > > > >Sorry for that. Compilation needs something like libtool-cache, if it > >is a bottleneck. BTW, choosing the right shell may also help a lot. > >Adapting Libtool to do this better for cases of interest might be a > >cheap way to get more speed quickly. > > > >>for all decent platforms, not win32), for the case of many objects. > > I think that the problem is that ltmain.c in the libtool directory > only contains: *snip* > If someone should care to finish this program, then libtool.m4 can > focus on creating the configuration file it needs.
I'd be happy to review your patches, time permitting. > Libtool has been around since 1996 but its implementation is still > fundamentally broken. Which part is _fundamentally_ broken? Being a shell script it can be slow, yes, and quoting is a pain, but you get that with `make', `autoconf' or `automake' as well, in slightly different settings. > We try to solve the problem by increasing the > amount of problem code (Microsoft approach). Where did we do that? You did not mean the roughly 50 lines I added for a 60% percent reduction in link time, right? Please show where we generate problem code. > Rather than chasing our > tails trying to make a moby shell script run faster, maybe we should > be thinking about creating a real program that runs quickly. I get your repeated point about ltmain.c. But let me tell you something about programming efficiency: if we can manage to put something like libtool-cache (but not broken) into libtool, let's say in roughly 30 hours work including testing, then I think that is reasonable. If you tell us that you can spend 300 hours implementing ltmain.c within the next few months, then I'll be happy that you found a sponsor and the time for doing this work. _And_ I'd still be amazed at your programming and testing speed. Note I am not trying to say this is futile, or a waste of time (actually I'm unsure about the latter). But I do know that incremental improvement of the current code base has so far been much more time efficient than a rewrite would be. Also I do believe that a continuation of this _can_ lead to libtool execution time to be negligible compared to compilation time, within a timeframe I can afford to spend on Libtool beside my thesis and job. Please also note that GCC has such kind of sponsoring (in different forms) necessary for such work. IOW: don't talk, start sending patches, just like I did when I saw which parts of Libtool needed work. And to undermine that, I will send another mail to this thread containing a first speedup patch. Regards, Ralf _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
