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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
