[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TODO
From: |
Bob Friesenhahn |
Subject: |
Re: TODO |
Date: |
Tue, 9 Nov 2004 10:02:16 -0600 (CST) |
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
- Re: TODO, (continued)
- Re: TODO, Gary V. Vaughan, 2004/11/09
- Re: TODO, Bruce Korb, 2004/11/09
- Re: TODO, Bob Friesenhahn, 2004/11/09
- Re: TODO, Gary V. Vaughan, 2004/11/09
- Re: TODO, Bob Friesenhahn, 2004/11/09
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO, Bob Friesenhahn, 2004/11/10
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO, Bob Friesenhahn, 2004/11/10
- Re: TODO, Gary V. Vaughan, 2004/11/10
- Re: TODO,
Bob Friesenhahn <=
- Re: TODO, Gary V. Vaughan, 2004/11/09
Re: TODO, Ralf Wildenhues, 2004/11/09
Re: TODO, Ralf Wildenhues, 2004/11/09
Re: TODO, Scott James Remnant, 2004/11/10
Re: TODO, Alexandre Duret-Lutz, 2004/11/09
- Re: TODO, Bob Friesenhahn, 2004/11/09
- Re: TODO, Alexandre Duret-Lutz, 2004/11/10