libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO


From: Gary V. Vaughan
Subject: Re: TODO
Date: Tue, 09 Nov 2004 15:18:01 +0000
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

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      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]