Re: TODO

[Bob Friesenhahn]

On Tue, 9 Nov 2004, Gary V. Vaughan wrote:

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

I thought that you had already incorporated this failing test case 
into HEAD.  A week ago you said that this particular issue was not 
critial enough to be considered for 2.0.  The problem is that libtool 
assumes that there is a ".libs" directory where libtool is executed. 
With libraries entirely built in a subdirectory, there is no assurance 
of a local ".libs" directory.

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

Fork() efficiency is important.  However, I get the impression that 
under MinGW/MSYS, environment variable and parameter transformation 
from Unix paths to Windows paths can take a long time.  This creates 
the appearance of a slow fork(). Performance can likely be improved by 
reducing the amount of junk that needs to be transformed to Windows 
form.

> 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

It seems like this solution would make libtool development less 
`interesting' since there would not be as much fun tracking down 
problems caused by bourne shell syntax differences. :-)

Various alternative shells (e.g. 'es', see 
http://www.webcom.com/~haahr/es/es-usenix-winter93.html) are quite 
small and efficient compared to bloated shells like bash.  Using a 
tiny (yet efficient) scripting tool seems fine.

Any approach which reduces the morass of m4 and bourne shell scripting 
seems better to me.  However, libtool needs to remain very small and 
able to build itself so it may be embedded in other packages.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen