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

[Paolo Bonzini]

> I still disagree. It does matter to have function support, and we
> don't care about LINENO at all. There are known environment where
> shell functions are not supported by default, e.g., Ultrix.

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.

> But anyway, my point was somewhat different: do you really want
> Autoconf to require shell functions?  I did not.
I see.  But I do, it is the only way to stop the bloating of configure 
scripts (I have more than two megabytes of them in GNU Smalltalk).  And 
by limiting the code duplication, it also paves the way for m4 loops, 
specialization and more cool stuff,  together with the patches I have to 
enable m4 lists and autoupdate them -- I did not send these patches 
because they are very delicate and I want to do more testing.

> 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.

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).

> 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.

Paolo