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

[Gary V. Vaughan]

Hallo Ralf,

[transplanted from another thread]

On 22 Jun 2010, at 00:59, Ralf Wildenhues wrote:
> However, this makes me more cautious
> about your other patch for using this machinery for the libtool script
> itself: that is created in packages using Libtool,

Not true.  We distribute libtoolize.in and ltmain.sh, for both of which
the bootstrap time m4sh expansions have already been made.  The only
time users will notice any difference is if they want to bootstrap from
the repository using a more than 4 year old Autoconf.

> and for those, we
> only require Autoconf 2.58 for now.  I'm guessing this getopt
> implementation is not yet up to that task?

Nor does it need to be, AFAICT.

> If it can be made 2.59-compatible (and the other issues noted in that
> thread are fixed) then ok, otherwise I would suggest bumping required
> Autoconf for libtool.m4 to 2.62 before the Libtool 2.2.14 release and
> using the getopt machinery for ltmain then, so that with 2.2.12, users
> still have a 2.62-buildable Libtool with cautious requirement on their
> own packages.  Does that make sense?

Actually I was thinking of adding m4_version_prereq(2.61) to just
getopt.m4sh, since that will at least give a useful diagnostic to libtool
bootstrap users who want bleeding edge libtool and ancient autoconf to
work together.

As long as other users are content with the libtoolize.in and ltmain.sh
that come with the libtool release tarballs (or are in the habit of
updating their Autotools within a few years of each other before they
bootstrap git clones), they won't notice anything.

WDYT?

[And back to the original thread]

On 12 Jun 2010, at 17:45, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Jun 12, 2010 at 12:34:04PM CEST:
>> On 12 Jun 2010, at 15:48, Ralf Wildenhues wrote:
>>> The variable preserve_args is not properly initialized any more,
>>> so it could pick up junk from the environment.
>> 
>> Okay. I did that to avoid the initial space, otherwise
>> ${preserve_args+.... } is set and expands to the part with the
>> space.  But since a spurious leading space is better that picking
>> up garbage from the environment, that's an obvious change.
> 
> Well, these are two orthogonal issues.  But the leading space is still
> not a problem.  :-)

Fixed in my local repo. Thanks.

>>> The handling of --dlopen=..., --mode=..., --tag=..., now increased by
>>> two forks and one exec per such flag on systems with decent shells, and
>>> it doesn't use safe $ECHO any more even on systems with indecent shells,
>>> because you don't use func_opt_split any more.  My guess is that this
>>> would increase libtool execution time for typical compile commands by
>>> a noticeable amount, since we got them down to about half a dozen forks.
>>> Please fix this.
>> 
>> 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:

## -------------------------------------------------- ##
## 4. Shell Code Potentially Optimised for XSI Shell. ##
## -------------------------------------------------- ##

# First we set _m4go_xsi_shell if the standard shell supports XSI features
# that allow us to avoid (expensive on Windows) forks:
m4_esyscmd([_m4go_dummy="a/b/c"
test "${_m4go_dummy##*/},${_m4go_dummy%/*},"${_m4go_dummy%"$_m4go_dummy"}, \
        = c,a/b,, && echo 'm4_define([_m4go_xsi_shell])'])

m4_divert_pop([KILL])
# func_opt_split
func_opt_split ()
{
m4_ifdef([_m4go_xsi_shell],
[  func_opt_split_opt=${1%%=*}
  func_opt_split_arg=${1#*=}],
[  func_opt_split_opt=`$ECHO "${1}" | $SED "$my_sed_long_opt"`
  func_opt_split_arg=`$ECHO "${1}" | $SED "$my_sed_long_arg"`])
}
m4_divert_push([KILL])

But I imagine that we'll then end up with the person running bootstrap
injecting an XSI function body into the generated option parse loop for
ltmain.sh, where the enduser tries to run the script with a non-XSI
capable shell :(

So we need to push back the decision until much later. Can all reasonable
shells DTRT with the following?:

# func_opt_split
_m4go_dummy="a/b/c"
if test "${_m4go_dummy##*/},${_m4go_dummy%/*},"${_m4go_dummy%"$_m4go_dummy"}, \
        = c,a/b,,; then
  func_opt_split ()
  {
    func_opt_split_opt=${1%%=*}
    func_opt_split_arg=${1#*=}
  }
else
  func_opt_split ()
  {
    func_opt_split_opt=`$ECHO "${1}" | $SED "$my_sed_long_opt"`
    func_opt_split_arg=`$ECHO "${1}" | $SED "$my_sed_long_arg"`
  }
fi

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