Re: [PATCH] getopt.m4sh generated libtool option parser, and XSI improvements.

[Gary V. Vaughan]

Hallo Ralf,

On 27 Jun 2010, at 00:44, Ralf Wildenhues wrote:

> * Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 10:23:39PM CEST:
>> This is the improved (and renamed) `Use getopt.m4sh to generate libtool
>> option parser.' patch I promised yesterday.  I'm pretty happy with this,
>> save that even though _LT_PROG_XSI_REPLACE correctly generates sed
>> scripts in config.status of the form:
>> 
>>  sed -i .tmp -e '/^func_name ()$/,/^} # func_name/c\
>> func_name ()\
>> {\
>>  indented code\
>>    over several\
>>  lines\
>> } # XSI func_name implementation' $cfgfile || ...
>> 
>> which, when run from the command line, retains the indentation of the
>> function body, but somehow deletes that indentation when run from
>> config.status.  It doesn't affect the functionality of the patch which
>> passes the testsuite with and without the XSI replacements in effect.
>> 
>> Other than that, this allows us to put the fallback implementations of
>> functions in the files which depend on them, and eliminate a fixme in
>> libtool.m4.
>> 
>> Any ideas why the indentation is lost like this?
> 
> Yes: 'info Autoconf --index sed', scroll down to
> 
>     Many `sed' implementations (e.g., MacOS X 10.4, OpenBSD 3.9,
>     Solaris 10 `/usr/ucb/sed') strip leading white space from the text
>     of `a', `c', and `i' commands.  Prepend a backslash to work around
>     this incompatibility with Posix:
> 
>          $ echo flushleft | sed 'a\
>>   indented
>> '
>          flushleft
>          indented
>          $ echo foo | sed 'a\
>> \   indented
>> '
>          flushleft
>             indented

Tx.  I see now that  my environment is picking up GNU gsed, but the script
is using the vendor sed, which explains the discrepancy between command
line and script for me when 'type -p -a sed' shows me only one binary
(my /etc/profile calls a script that runs 'alias sed=/opt/local/bin/gsed').

> For all of the variable names that you changed in ltmain.m4sh in order
> to comply with getopt.m4sh requirements: did you check whether any of
> these variables are referred to in libtool.m4 macros?  There are some of
> those kinds of hacks on some systems, and testing isn't necessarily
> gonna show.

Yes I did.  However, double checking reveals that I actually missed a
$mode->$opt_mode instance in ltmain.m4sh :(  Fixing now...

>> And in any case, okay to push?
> 
> No.  Well, you did already, time has passed already, but I can't review
> this patch because it doesn't build for me (see other mail).

Argh.  Sorry.  I figured it was okay after 72 hours without feedback.

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