Re: config.sub/config.guess using nonportable $(...) substitutions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 9, 2021 at 5:00 PM Tim Rice <tim@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 9 Mar 2021, Warren Young wrote:
> > On Mar 9, 2021, at 1:26 PM, Paul Eggert <eggert@xxxxxxxxxxx> wrote:
> > Solaris 10 dates from early 2005.  We gave it 16 years of direct support, and now it’s on a sort of “extended” support if you point Autoconf configure scripts at a reasonable shell.
>
> The thing is, it is not even necessary to point Autoconf configure
> scripts at a reasonable shell. The configure script will find a capable
> shell and run itself with that shell.
>
> UnixWare has a /bin/sh as crufty as Solaris 10. I just pulled the
> latest config.guess and config.sub into my OpenSSH tree and configure
> was just as happy as before. Like Solaris /bin/sh, UniWare's does
> not handle $(...) either.

N.B. I changed Autoconf's "find us a better shell" logic in 2.70 to
include checking for $(...) _specifically because of_ the change being
debated here.  Configure scripts themselves still use `...`
nigh-exclusively.

I don't want to either tear down or defend Ben's change, but it's my
personal opinion that use of $(...) is a lot more defensible in a
configure script than in config.{sub,guess}, because it _has_ that
"find a better shell" step at the beginning.  Also, configure would
get more out of being able to use $(...) than config.{sub,guess} do,
just because its code is typically more complicated, and configure
scripts tend to pull in third-party code from all over the place that
may or may not ever have been tested on anything old.  For these
reasons I probably wouldn't revert the Autoconf change even if the
config.{sub,guess} change were reverted.

zw





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux