Re: 01-as-require-shell-fn.patch

[Akim Demaille]

 > I seriously doubt that any of the still existing Ultrix box sysadmins
 > don't have a better shell at hand.  I fail to believe that there are
 > newbies playing with Ultrix who cannot download bash 1.x.

I wholeheartedly agree: "I seriously doubt".  But this Autoconf: my
opinion, nor do most opinions, doesn't matter: if it happens that some
non-negligible bug reports are sent to maintainers because their
configure do not run on some exotic machines, then be ready to spend a
bad time.

We first have to have spy before committing Autoconf (and its users)
to such a risk.


 >> If everybody agrees we can use shell functions, then let's proceed.
 >> This is quite an audacious change.  Given the popularity of changes in
 >> Autoconf, I quite fear it...
 >> 
 > I did not mean to use shell functions in the short term.  I did not
 > put in shell functions with a FYI, I would understand if you ripped
 > off my write privileges :-) if I did something like that.  I put in
 > (after approval) a macro which has no ramification whatsoever on the
 > produced configure scripts.

But by making this move, you prevent real scale tests such as in
Autotest, or via a spy in Autoconf, to real check what matters: shfn
support, and not "shfn support amongst shells supporting LINENO".  If,
out of chance, there happens to be a shell that supports LINENO but
not shfn, then we have to go through another full cycle, and this
LONG... :(


 > The first usage I planned was to add a shell function to match a
 > string according to a glob pattern.  This would be useful to simplify
 > AT_XFAIL_IF invocations, matching your plan of using shell functions
 > on Autotest at first.

 >> I do not believe that the set of people/env running make check on
 >> Autoconf is related in anyway with the set of people/env running
 >> configure.
 >> 
 > AFAICT, the set of programs using Autotest is so small, that the
 > people running make check on autoconf is about the same as the same
 > people running Autotest (as much as I like Autotest).

You miss my point: Autoconf, the package, is _not_ a faithful test for
configure scripts.  There is very few maintainers working on an
obsolete environment, but there are still many machines out there
where Autoconf'ed packages are installed.


 >> But this goes against this patch.
 >> 
 > I don't understand how, sorry.  Adding a m4sh feature does not mean
 > that everybody will use it -- especially since m4sh is so largely
 > undocumented, which is something I intend to fix one day.

I admit I understood your patch as the first step towards using shfn
in Autoconf, but I'm wrong, sorry.  Nevertheless, it seems to me that
this is an incorrect path to our ultimate goal: use shfn asap in
Autoconf.  To this end, we need to measure the availability of shfn
support, not the shfn support amongst LINENO supporting shells.

I'm eager to use shfn, I'm eager to see your patches applied.  But
this is Autoconf: we can't hurry.