|
From: | Charles Wilson |
Subject: | Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly. |
Date: | Wed, 21 May 2008 00:23:34 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |