Re: [rth@redhat.com: libjava build times]
On Thu, 5 May 2005, Ralf Wildenhues wrote: 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. I did not mean to offend ... by fundamentally broken I mean that it is impossible for a shell script to reach the performance levels of compiled code. There is a philosophical issue which is currently forcing libtool into this model. Libtool is doing things that it doesn't need to do. There are perceived requirements which are not actual requirements. Interposing libtool beween 'make' and the compiler/linker shouldn't consume more than 1% of the time or so. On some systems (e.g. Microsoft Windows) it seems to consume 80-90% of the build time. 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. I didn't claim it was easy, however, a thousand mile journey starts with a single step. At the moment, there is not even the start of a plan. By making the libtool binary a tool that you install in advance (similar to 'make') a huge amount of the effort can be relieved. Each package would then only need to provide a small bit of configuration information. Each package would configure and build much faster. Some small packages would be much smaller due to elimination of most of the configure script. It is not uncommon for most of the configure script run time to be consumed with libtool-related processing. We already assume that the user has been able to procure/install make, a C compiler, and many other tools. It doesn't seem like a big deal for packages to require that libtool be installed. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [rth@redhat.com: libjava build times]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | I'm pretty sure I can get it quite a bit faster even. The patches need | cleanup so that they use allowed file names and work properly in corner | cases as well, but those don't scale with the number of objects, so they | matter less. | + $ECHO $oldobjs | $SP2NL | $SED -n -e '/./p' _objs Ralf, you really rock! I do worry about this echo though. How big is $oldobjs? Will we exceed the max_cmd_len if echo is an external program? Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQnoN67iDAg3OZTLPAQKGAgP/dqzSt23v4QA/90LDmCrIoGdSpHsLilj/ ffrjmDHEVhRwHySb1YCnO7YsXwvGnXyKfNAxCHB3GsD1LQjIIkrVtX3gx/Vr7y1W gJ03CggYBpNn8ft4DVPFcigduJ4aTHne8+ND0oBPVLpiYrO7UFJcNlzHGVnLaTLG zctQUdZrgac= =5dvv -END PGP SIGNATURE- ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [rth@redhat.com: libjava build times]
Hi Joe, others, * Joe Buck wrote on Mon, May 02, 2005 at 08:01:49PM CEST: We really need something done about this problem, as it interferes with our ability to efficiently develop GCC. How many objects does libjava contain? Rather 100 or 1000? Do you need relinking because of command line length? From: Richard Henderson [EMAIL PROTECTED] *snip* I began by building the whole of libjava, and then using find to delete all of *.o *.lo *.a *.la. I then timed rebuilding the library: *snip* Now, unless I've done something drastically wrong, it appears as if we are spending 2/3 of our time in the libtool script. I know. I worked on that for Libtool HEAD and fixed it mostly (that is, for all decent platforms, not win32), for the case of many objects. Fixing win32 will require incorporation of something like Robert Ögren's libtool-cache. It's my plan to do this (in the HEAD branch) after other pending work has settled. You could use libtool-cache as a temporary workaround. It's not foolproof, but for development that should be ok -- not for release. Using libtool HEAD should also work, but integration of that into gcc will require some work. You could help by convincing the other maintainers to allow me to backport my changes from HEAD to branch-2-0 (after Libtool-2.0.0 is out), or help with integration of a fool-proof libtool-cache like caching mechanism. Regards, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
