My experience with developing software is that unless software has been tested, it is unlikely to actually work. While we may pretend that libtool supports 20 year old systems, the reality is that no one is testing to verify that libtool can actually execute on these systems. Exceedingly few of these 20 year old systems exist. Just running configure may take several days on a 20 year old system. There is very little value remaining to support 20 year old systems.
It can be safely assumed that libtool does not work on 20 year old systems. Bob On Thu, 7 Nov 2002, Boehne, Robert wrote: > Jan, > > That actually brings up a big issue. I *assumed* that the win32 patches > using shell functions that were checked in would only have shell functions > when running under windows. I later saw this was not the case. There has > been a large amount of debate over this in the Autoconf list, which I do > not care to repeat here. There are systems that do not have shell functions > in their bourne shells, this is a known fact. The decision to support them > was made a long time ago, and as time progresses it seems to make less sense > to support aging systems like this. However, I do not want Libtool to get > out of sync with Autoconf, suddenly not running on systems where Autoconf > does run. Frankly, I don't see the point of shell functions in this case > because we use m4. The solution I would propose is to turn your shell > functions > into m4 macros where possible, and any WIN32 specific code can be only > included > when WIN32 is detected at run time > (via ". some_here_document_containing_win32_shellfuncs") > Until all the Autotool maintainers decide to abandon support for non-shell > function > bourne shells we need to support them as well. The Autoconf maintainers > recently > decided against this, and keeping compatibility with Autoconf is a primary > concern. > I vote to revert the patches that use shell functions, preferring to > include > them only on systems known to use them (like win32). The patch resolving > name > conflicts in archive libs could be converted to m4, or just included in > the necessary spots. > Considering the relative ease that these changes could be done with, I > don't > think it makes sense to drop any platform for this reason. > > Ok, let the flame wars begin... > > Robert > > -----Original Message----- > From: Jan Kratochvil > [mailto:rcpt-robert.boehne.AT.ricardo-us.com@;jankratochvil.net] > Sent: Thursday, November 07, 2002 9:19 AM > To: Boehne, Robert > Cc: [EMAIL PROTECTED] > Subject: Re: solving of name conflicts in included .a > > > Robert, > > On Thu, 07 Nov 2002 15:52:10 +0100, Boehne, Robert wrote: > ... > > I haven't gone over your patch with a fine-toothed comb, but > > the idea works for me. > > Akim Demaille noted the problematic use of shell functions but one function > was > already there before my patch anyway. BTW I found out you are using the same > code many times over the code - would not it be better to preprocess the > file(s) with some preprocessor if you want to prevent shell functions? > > > > I checked but couldn't find your name > > in the copyright assignment list. Would you be willing to > > assign the copyright for your changes over to the FSF? > > I agree to assign my copyright / authorship of my patch identified by > MD5 55fe631a9b5a634f1366a8e4f68f7a1c (with LF newlines) to FSF. > This contract is concluded according to U.S. law. > (The laws of Czech Republic do not permit authorship assignment and > therefore > it must be done by special contract about rights extensions/restrictions of > the > involved two parties on the specified subject (program).) > > > > Regards, > Lace > ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
