Hi Bob! Bob Friesenhahn wrote: > On Tue, 9 Nov 2004, Peter O'Gorman wrote: > >> Hi, >> I just want to get some possibilities out there into the ether. Feel >> free to add more bits/say which bits are silly. >> >> Post 2.0: > > i) Fix building libraries in subdirectories. The package I maintain > continues to be dead in the water until this functionality works.
Can you commit a test case for this to HEAD? I have several hours each way on a plane next week where I should have time to make a fix and port it into branch-2-0 before the final release... >> 5. Think about speed, compile mode needs to be as fast as possible, >> can it be faster than it is? > > > This particularly valuable under Windows. I have more gray hair now. My impression is that fork() is half the problem here. Would making some sort of uber-shell, with more builtins (say a sed command for example) help out? A few years back I made some noise about retargeting the libtool script to a custom shell with less bogosity than bourne shell, and which could be bytecompiled. The sources for the bytecode interpreter would then be shipped along with the (much simplified) ltmain and m4/lt*.m4... the advantage of going along this road is that autoconf too could stop jumping through shell hoops by targetting a new, sane bytecompilable command script... Also Bruce Korb had a play with a compilable libtool in C generated by his autogen project. Things in Libtool have moved along enough that it would probably be easier to take this approach rather than my convoluted idea. I am certainly not against the idea of translating ltmain.m4sh into C, we just need to freeze changes to ltmain while it is underway. I think we can tackle it in stages: 1. call the existing ltmain.m4sh in a C wrapper 2. convert the compile and runtime infrastructure to compensate 3. pick a small mode 4. convert it to C from the top down 5. pick another mode and repeat until done I don't honestly think there is any point in trying to parallel maintain and/or generate both shell and C versions at all. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool