Re: [PATCH] Add an XSI replacement for func_split_short_opt.

[Gary V. Vaughan]

Hallo Ralf,

On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 05:09:29PM CEST:
>> On 29 Jun 2010, at 21:03, Eric Blake wrote:
>>> Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
>>> support, but that will have to wait until after autoconf 2.66.
>> 
>> While that might turn out to be useful elsewhere (I wrote a quick esyscmd
>> to check for the things that Libtool needs, so it's not difficult in
>> principle), it's not useful for Autotools as things stand right now, since
>> m4sh generally runs on the developers machine to generate scripts that are
>> shipped and executed on the user's shell.
>> 
>> It might be nice if a future Autotools does the m4sh->sh generation from
>> some AC_macros that expand at distribution time but are still executed on
>> the user's machine - but then we are requiring that the user have modern
>> GNU m4 available, which might not be smart.
> 
> I think m4sh can simply use code like
> 
>  if ( eval '$smart_works' ) >/dev/null 2>&1; then
>    func_foo () { smart code; }
>  else
>    func_foo () { safe code; }
>  fi
> 
> for code run a handful of times, without need for extra m4 magic, it's
> just that libtool is easily run hundreds of times in a typical large
> software build so it warrants optimization.

In that case might the retarded shell choke and die as it parses 'smart
code;'?

I don't actually know whether retarded shells mostly ignore the code
during parsing, and can be reliably fed what they would otherwise consider
garbage as long they are never instructed to execute the garbage... but
it seems like something we'd need to be very careful about.

Cheers,
-- 
Gary V. Vaughan (address@hidden)