Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

[Charles Wilson]

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