From: Akim Demaille <[EMAIL PROTECTED]>
Date: 25 Feb 2000 16:31:17 +0100
| However, I think we can all agree that there are machines which do not
| have shells which support functions. For example, SVR2 machines.
| Those machines are still running. Whether anybody runs autoconf
| generated configure scripts on them, I don't know. I've done it in
| the past, but not in the last several years.
I don't want to give the impression I don't trust your word here, but
I know by experience that in the Autoconf world there are many legends
and myths. I'd like to see someone really trying the various shells
on this machine and report the status of unset and of functions.
I've seen this argument before, but I don't entirely believe it.
There is a lot of autoconf lore that is the result of people reporting
problems. People then forget just what the problems were. But that
does not mean that the problems were not real.
I've been using autoconf since the beginning, and I've used a lot of
different Unix systems. If you have any specific questions, I'm
willing to take a stab at them.
My SVR2 example was not arbitrary. I've run autoconf generated
configure scripts on Z8000 based SVR2 systems. As of a couple of
years ago, those systems were still running, and I don't know of any
reason why they would not still be running today (well, I suppose they
might have been replaced due to Y2K concerns). (Those systems are so
old that they don't have setjmp/longjmp--they have a different
mechanism, called setret/longret.)
In addition, though I agree to be extremely oldish compatible, we
should not still fight for PDP11. Yet Autoconf, as we have recently
discovered is far from being really portable as compared to
Metaconfig. But in practice, AFAIK, *never* this has been reported.
I guess I don't understand what you mean here. I probably just didn't
read the messages. I mean, naturally nobody has reported that
autoconf is being used on a system which does not support shell
functions, because autoconf doesn't use shell functions.
People have certainly reported that programs which use autoconf are
not fully portable, but the fault generally lies not in autoconf, but
in how it was used. It's true that autoconf is quite difficult to use
correctly, but that is more a design problem than a bug.
But the fact that unset might be portable is completely different and
opens new horizons (the heck with CDPATH, LANG etc.).
Yes, good point.
Ian
