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