| 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.
Yes, I agree. Maybe I'm giving the impression I feel that you didn't
trust me on this one while you may have but :)
Yes, of course I'm well aware there are real problems which mandated
weird solutions that I might understand today. But I can also show
you things which were programmed in a very bizarre way, which at first
sight was due to a portability issue, and actually were not.
I'm *extremely* cautious when touching Autoconf. I don't mean to
break something.
But, I'm also critic wrt not-established portability axioms. Trusting
blindly whatever piece of old code does not seem better to me than
trusting blindly new code. I'm talking of a balance.
| 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.
OK. Can you tell me why the heck the cache looks like this:
ac_cv_path_M4=${ac_cv_path_M4=/usr/bin/m4}
ac_cv_path_PERL=${ac_cv_path_PERL=/usr/bin/perl}
ac_cv_path_install=${ac_cv_path_install='/usr/bin/install -c'}
ac_cv_prog_AWK=${ac_cv_prog_AWK=mawk}
ac_cv_prog_gnu_m4=${ac_cv_prog_gnu_m4=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
and not like this:
: ${ac_cv_path_M4=/usr/bin/m4}
: ${ac_cv_path_PERL=/usr/bin/perl}
: ${ac_cv_path_install='/usr/bin/install -c'}
: ${ac_cv_prog_AWK=mawk}
: ${ac_cv_prog_gnu_m4=yes}
: ${ac_cv_prog_make_make_set=yes}
| 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.)
Wow :) Never heard of these guys. Still, you didn't answer my
question: there are *no* shells on these machines which support
functions?
| 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.
Yep, but for instance Metaconfig does not use `#' for comments, but
`:', because it is not portable. And Autoconf's configure scripts
cannot run on Eunice, while Configure does. How Eunice and SVR2
compare in terms of age?
This is just a few examples. There is no doubt in my mind that
Metaconfig's Configure are more portable than Autoconf's configure,
there is no doubt in my mind that I don't care (until someone
convinces me `#' is hell).
Akim
