Re: [Patch] cwrapper invokes target directly

[Charles Wilson]

Ralf Wildenhues wrote:

> It might even be as simple as inserting *literal* code into cwrapper like
>   lt_setenv("FOO", "bar");

Exactly.  Or lt_opt_process_env_prepend("PATH=/some/path"), so that you 
prepend the provided value to what PATH is at wrapper *invocation* time, 
instead of completely overriding the runtime value of PATH based on its 
value at wrapper *compile* time.  Granted, at the time such 
functionality is introduced, it may behoove us to (a) change the name of 
that function, and (b) remove the associated cmdline option.

OTOH, maybe not. For debugging purposes -- or allowing end users to work 
around flaws in client packages' use of -wrapper-env -- I could envision 
cmdline overrides.

PATH=/explicit/new/path ./wrapper

is different than

./wrapper --lt-env-set=PATH=/explicit/new/path

because the former may be overridden/extended by built-in stuff, while 
the latter can be used to override the built-ins. (Sure, that's a 
dangerous tool; somebody could break the package maintainer's carefully 
constructed test environment. Or fix a bitrotted one.)

Whenever you start adding "automatic" behavior, there /will/ be problems 
-- some upstream maintainer will make an invalid assumption with 
-wrapper-env and break stuff for their users. The end user needs a way 
of working around these issues.  The --lt-* options give it to them.

> I understand that --lt-env-set may help debugging, but in the end, there
> is no need to expose more unportable interface than necessary.

It's only unportable in that a similar interface has not yet been added 
to the wrapper script, which is much easier to do than adding to the 
cwrapper. However, for the reasons described above, I think it /should/ 
be added. And then it's not unportable at all.

Ralf, if you have a problem with code that was proposed to the list a 
week before your vacation, and thoroughly discussed for over a month, 
before, during and after said vacation before you chimed in, you know 
what your options were then and are now.

> Which is good, even if cwrapper can lose a third of its code to achieve
> the same.

A third of main() -- and given the override capabilites I'm not sure 
even that should be removed.  Furthermore, most of the additional code 
and functions are PRECISELY the stuff -wrapper-env will need to use.

But hey, feel free to remove it now and re-implement the same crap later 
if it makes you feel better.

--
Chuck