Eric Blake wrote:
Eric Blake <ebb9 <at> byu.net> writes:
| + /* otherwise ... */
| + newargz[++newargc] = xstrdup (argv[i]);
Shouldn't you handle "--" as the end of wrapper options, in case the user
really wants to pass --lt-env-* as the first option to the wrapped executable?
This caused a regression caught by the m4 testsuite.
I see two options:
1. Entirely revert the portion of the cwrapper that looks for --. Instead,
make the cwrapper only recognize leading --lt-* options,
currently, --lt-* options are allowed anywhere in the argument list, not
just leading. The only reason for the wrapper to respect "--" was a
vague notion of abiding by the GNU standards for option parsing.
However, it isn't clear that this requirement should be levied on the
wrapper -- especially as it serves no real utility, and only makes it
harder to pass those same GNU-standard options (like "--") to the REAL
executable!
and pass all remaining
options as is; and document that the --lt-* option namespace is reserved for
the wrapper. Pro: easier to implement, simplifies the cwrapper. Con: the
wrapped executable can't be handed a leading argument in the --lt-* namespace.
Counter-proposal: remove "--" handling in the wrapper, but don't worry
about requiring "leading" options only. Instead, the wrapper just eats
--${LTWRAPPER_OPTION_NAMESPACE}-* options (and their arguments) wherever
they appear in the command line. However, allow the end-developer to
set an environment variable (or a configure option?) to change what that
prefix is.
That way, if package X insists on having options in the --lt-*
namespace, package X's configure.ac could specify that, for this
package, the magic wrapper namespace is --libtool-wrapper-* or whatever.
2. Instead of using --, invent a new cwrapper option --lt-end-options that does
the same concept. Pro: no infringment on the application; if an application
truly needs to use --lt-* as its first argument, it can decide whether to add
the --lt-end-options marker based on whether it was compiled statically or
not. Con: rather complicated just to support a corner case of uninstalled
applications, and we must document how the package can tell whether the
uninstalled program is a cwrapper or a static executable, to know whether --lt-
end-options is needed.
Ick.
If you haven't guessed, I'm leaning towards option 1. Any other comments on
this issue?
See above, and sorry for the trouble.
--
Chuck
