[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patch] cwrapper invokes target directly
From: |
Charles Wilson |
Subject: |
Re: [Patch] cwrapper invokes target directly |
Date: |
Tue, 27 May 2008 09:37:09 -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 |
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