Re: 1,000 year backward compatability of tools
Paul Eggert wrote: Alex Hornby [EMAIL PROTECTED] writes: On a related note, does the restriction of not using shell functions in autoconf macros still remain, For Autoconf itself, we still avoid shell functions. But of course you can use shell functions in your own macros, if you don't care about porting to shells that lack shell functions. Personally I'm becoming more inclined to start using shell functions. Perhaps in Autoconf 3. If my memory serves, GCC has finally said, Enough with KR already! but everyone is still saying, You first. and No, after you. It's silliness. The only people squawking are the ones jealously looking out for someone who maybe might be using the stuff. Sweating KR-isms and copying shell text to avoid functions is a waste of developer time. Even if money isn't paid, there's still a big cost. It's past time. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
On Wed, 19 Feb 2003, John W. Eaton wrote: But now? Do we really have to worry about these old systems? If people enjoy the vintage hardware, then is it that bad if they can only use vintage software on it as well? To install modern software on one of these vintage systems would be like putting chrome mag wheels on a Rolls Royce. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
On Wed, 19 Feb 2003, Bob Friesenhahn wrote: On Wed, 19 Feb 2003, John W. Eaton wrote: But now? Do we really have to worry about these old systems? If people enjoy the vintage hardware, then is it that bad if they can only use vintage software on it as well? To install modern software on one of these vintage systems would be like putting chrome mag wheels on a Rolls Royce. :-) to complete the analogy, with autoconf 2.57, the tires are forgotten in the rush to admire the wheels. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
Charles Wilson wrote: I think the winning argument was as follows: for archaic systems whose shell does not support shfuncs, 'somebody' should create a snapshot of bash with a frozen autotool version That's the argument that has been put forth over and over for years. I couldn't remember if it was finally accepted or not. It was deemed insufficient for so many years Recall that just because NEW autotools will/may use shell functions, that doesn't retroactively break all existing packages that are already out there. So, the poor Ultrix user will only need bootstrap bash However, AFAIK, nobody has actually created that bootstrap bash package, or if they have, it has not been widely publicized. That's because the few hobbiests maintaining the museum pieces manage to cope and all the remaining antiquarians are either theoretical or silent. The people speaking up seem to be those who worry about the theoreticals instead of people with real problems It's time to move on. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
I guess it's time for me to chime in. Dave Mills expect NTP to compile on anything he can get his hands on. I've been lucky so far in that some of the older gear he has is breaking. I do, however, still support SunOS4.1 and Ultrix. And NTP will still use ansi2knr where needed. I am also working toward implementing a configuration management mechanism that lets me keep multiple versions of software packages available. So as long as there is *some* way for me to deal with ancient hardware I'm happy. As far as recent versions of automake and autoconf go, as long as the last version of automake and autoconf that build with ancient tools actually work I'm probably set. The big gap after autoconf-2.13 and automake-1.4 was Difficult for me, as I had to use CVS versions to get patches I needed. On another note, right around Y2K I had a client call when they discovered an old Pyramid box (an active mail server) hidden in a room. They knew they couldn't turn it off and they knew it was never going to be Y2K compatible. I had *remarkable* time finding a way to find/compile something to handle their problem (I ended up with a simple TCP proxy that forwarded SMTP traffic to a new machine, and this software was simple enough that it could be compiled with the native compiler; I was unable to get any of my Old versions of gcc to build on that box.) H ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
Bruce Korb wrote: Paul Eggert wrote: Alex Hornby [EMAIL PROTECTED] writes: On a related note, does the restriction of not using shell functions in autoconf macros still remain, For Autoconf itself, we still avoid shell functions. But of course you can use shell functions in your own macros, if you don't care about porting to shells that lack shell functions. Personally I'm becoming more inclined to start using shell functions. Perhaps in Autoconf 3. If my memory serves, GCC has finally said, Enough with KR already! but everyone is still saying, You first. and No, after you. It's silliness. The only people squawking are the ones jealously looking out for someone who maybe might be using the stuff. Sweating KR-isms and copying shell text to avoid functions is a waste of developer time. Even if money isn't paid, there's still a big cost. It's past time. I think libtool went first. I submitted a patch a few months ago to help re-enable building DLLs on cygwin; that patch contained a shell function. This spawned a huge debate which meandered across the various autotool lists (this debate, I note, seems to crop up about every six months on one autotool list or another...) Eventually, the patch was accepted, and libtool (CVS HEAD) now has a shell function in it. I think the winning argument was as follows: for archaic systems whose shell does not support shfuncs, 'somebody' should create a snapshot of bash with a frozen autotool version. then, if you needed to use new autotools on that ancient system, then simply download and install the bootstrap bash package, and then use that. Recall that just because NEW autotools will/may use shell functions, that doesn't retroactively break all existing packages that are already out there. So, the poor Ultrix user will only need bootstrap bash if she wants to compile new software that uses new autotools -- otherwise, she's fine as is. However, AFAIK, nobody has actually created that bootstrap bash package, or if they have, it has not been widely publicized. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
Harlan Stenn wrote: I guess it's time for me to chime in. Dave Mills expect NTP to compile on anything he can get his hands on. That's very nice. Why does he need to do this? I mean, the compelling reason? I've been lucky so far in that some of the older gear he has is breaking. I do, however, still support SunOS4.1 and Ultrix. ... So as long as there is *some* way for me to deal with ancient hardware I'm happy. ... On another note, right around Y2K I had a client call when they discovered an old Pyramid box (an active mail server) hidden in a room. They knew they couldn't turn it off and they knew it was never going to be Y2K compatible. I had *remarkable* time finding a way to find/compile something to handle their problem (I ended up with a simple TCP proxy that forwarded SMTP traffic to a new machine, and this software was simple enough that it could be compiled with the native compiler; I was unable to get any of my Old versions of gcc to build on that box.) Including the 2.7.2? I would think compelling need would mean: 1. You can't get GCC 2.7.2 up (with a precompile or from source) 2. You can't get an old bash up (likewise) 3. You can't then do rolling upgrades till you're up-to-date enough to build the product you're interested in If any of those are true, then compelling need is shown when: 4. You have the time to spend on it. It might be nice to set up an internet archive of installable binaries for these things while you can still find the platforms around at all. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
