On Fri, Sep 22, 2023, at 5:14 PM, John Cotton Ericson wrote:
> On 9/21/23 22:31, Jacob Bachmeyer wrote:
>> Zack Weinberg wrote:
>>>
>>> Um. I don't think you can use shell functions in this file (or in
>>> config.guess), for the same reason you can't use $(...).
>>
>> It may be worth noting that the Solaris 10 sh does not support $(...)
>> but *does* support at least simple shell functions; I just tested
>> this at gcc210 on the GCC compile farm. Similarly, the "bsh" AIX
>> shell on gcc111 also supports functions but not $(...); the default
>> "ksh" login shell on gcc111 supports both, as does the default "bash"
>> login shell on gcc210.
>>
>> I think we *can* use shell functions in these files, since even the
>> Solaris 10 and AIX7.1 Bourne shells support them despite lacking
>> support for $(...); I do not have convenient access to anything more
>> ancient at the moment for further testing.
>
> Oh whew, that's good to hear Jacob. [...]
It is ultimately ldv's call, but Jacob's experiment is not good enough
for me to approve.
The thing is that config.sub and config.guess need to work *even when
nothing else works*, because if they don't work on some ancient system
that gets in the way of submitting an actionable bug report.
The other thing is that they need to do as little work as possible,
because they sometimes get called dozens of times in a row in e.g. CI
orchestration that doesn't have the capability to cache the result
("every line is its own independent sh -c invocation" situations) --
this means that I wouldn't endorse copying Autoconf's code to find a
shell that *does* support functions (_AS_DETECT_BETTER_SHELL) into
config.sub and config.guess, either.
And the third thing is that based on what happened when we *tried*
to start using $(...) in these functions, I fully expect proud present-day
users of, I dunno, 4.2BSD-era One True Bourne Shell or something to
descend upon this mailing list the moment the patch lands (but not
before).
I strongly recommend you pursue the possibility of generating config.*
from a more flexible source language, and continuing the policy that
the code actually *in* these scripts is supposed to work with /bin/sh
as old as the introduction of `#` comments, instead.
zw
