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

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Fri, Jun 11, 2010 at 07:22:52PM CEST:
> Okay to push?

> * libltdl/config/ltmain.m4sh: Replace hand written shell code
> with a call to M4SH_GETOPTS. Rename some option variables in
> the client code to match the generated option parser settings.
> * libltdl/config/general.m4sh (func_echo, func_error)
> (func_warning): Use $opt_mode instead of obsoleted $mode in
> message leader.

Some nits:

The variable preserve_args is not properly initialized any more,
so it could pick up junk from the environment.  The addition of
--debug to preserve_args is moved out of the parsing loop, unlike
the other preserved args, which is inconsistent.  I don't think
you need to take care about the leading extra space in preserve_args,
IOW, I think you can simplify all those
  preserve_args="${preserve_args+$preserve_args }$opt"

to
  preserve_args="$preserve_args $opt"

I'm not sure why some of the variable renamings are done, e.g.,
opt_preserve_dup_deps, or execute_dlfiles, or mode.  These could easily
be done in a separate patch (and then, they would be trivial to verify,
and maybe easier to understand why they are needed).

Why do you now separate entries in opt_dlopen (formerly execute_dlfiles)
with newlines, rather than, as formerly, with spaces?

The indentation in the generated libtool script is a bit awkward,
but I guess there's little we can do about it with this scheme.

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.

Thanks,
Ralf