Re: [PATCH] Use getopt.m4sh to generate libtool option parser.

[Gary V. Vaughan]

Hallo Ralf,

On 22 Jun 2010, at 12:48, Ralf Wildenhues wrote:
>> On 12 Jun 2010, at 17:45, Ralf Wildenhues wrote:
>>> * Gary V. Vaughan wrote on Sat, Jun 12, 2010 at 12:34:04PM CEST:
>>>> That's quite an invasive change, since the core of the M4SH_GETOPTS
>>>> generated code will then rely on the XSI functions you add to libtool at
>>>> configure time.  I suppose we need to put them in, say,
>>>> libltd/config/xsi.m4sh where libtoolize, commit, announce-gen,
>>>> mailnotify and any future m4sh scripts can reap the benefits.  This
>>>> in turn means we need to move it into a separate macro to contribute
>>>> back to Autoconf when we move getopt.m4sh and supporting code.
>>> 
>>> I'm fine with not using XSI for all other scripts; the func_opt_split
>>> could be trivial forwarders for the sed scripts there; that would avoid
>>> having to beef up infrastructure here, IIUC.  But the libtool command
>>> line parsing really was one of the time critical issues in user builds,
>>> and --mode and --tag are pervasive, so this would be a real regression.
>> 
>> I'm still not clear on how to implement this cleanly.  I'd like to be
>> able to figure it all out at bootstrap time:
> 
> That works portably only if you put the XSI-relevant tests in a
> subshell, otherwise an old shell may spew errors and even die due to
> syntax errors.  But a subshell regresses on time again.

Bummer.

> Can't you
> optionally allow to specify to the machinery "the functions X and Y
> have already been specified for you externally"?

Having given this some more thought, I think that instead of trying to
choose between the right implementation of the optimisable functions at
execution or configure time, but rather I should decorate the fallback
sed-based implementations in the m4sh output (adding appropriate
comments around them in getopt.m4sh).  That way libtoolize, commit et.
al. will work as they do now, and then instead of appending the XSI
definitions to libtool at configure time from _LT_PROG_XSI_SHELLFNS,
we textually replace the fallback definitions with XSI optimised
versions instead.

I'll work on a patch to that effect presently, unless you can forsee
any issues?

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