On 9/25/23 10:24, Zack Weinberg wrote:

It is ultimately ldv's call, but Jacob's experiment is not good enough
for me to approve.

So I saw Jacob's research as not demonstrating using functions is *definitely* OK, but that has indicating it *might* be OK. Does that sound better?

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.
Agreed. My change is does mean dropping support for borne shell without functions. The question (not something I know yet!) is whether anyone is still using such a system.
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).

Sure. If they show up, we can definitely revert it. But what happens if they *don't* show up? What do you think in that case?

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.

Agreed, either we should always use functions or never use functions. (I am not worried about that overhead of functions, however.)

I strongly recommend you pursue the possibility of generating config.*
from a more flexible source language
Rest assured, I certainly with that as "Plan B" if we cannot include shell functions.
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.

It is unclear to me whether bourne-ish shells that were new in March 13 1992 that still didn't support shell functions, or whether there were simply older shells still floating around in widespread use.

I think at some point it is fine to drop support for older things: Autotools should transition from "we support everything since 1984" to "we support the last <N> decades of computers", but I make no claims as to what N should be :).

Cheers,

John

Reply via email to