[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 01:51:32 -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:
* Charles Wilson wrote on Sat, Apr 26, 2008 at 10:22:39PM CEST:
This patch also adds the following three command line options to the
wrapper executable:
--lt-env-set foo=bar
--lt-env-prepend foo=bar
--lt-env-append foo=bar
Why? I don't see any use case for this. In fact, I don't see how any
argument to the wrapper other than the dump-script one could ever be
useful: the user cannot (better: does not want to have to) know whether
the wrapper executable will be built for a certain uninstalled program
or not (think: it could be linked against an uninstalled library or
not). Further, if I want to modify the environment like
./prog --lt-env-set foo=bar
I can do
foo=bar ./prog
just as well, no?
Yes.
In case you were hinting at supporting this
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319/focus=5438>
for the cwrapper, well, that's not what you're doing, as Behdad's
feature request revolves around adding arguments to libtool --mode=link
which cause the uninstalled executable to have a modified environment.
*That* allows me to not have to differentiate between the call of an
uninstalled and an installed program at all.
That's not YET what I'm doing. However, these options exercise and test
the requisite functionality within the wrapper, so that LATER, we can
modify func_emit_cwrapper_src() to insert the appropriate stuff and be
assured that it will work.
It MIGHT even be as simple as defining an array like so:
const char* extra_argv[] =
"--lt-env-set", "foo=$bar",
"--lt-env-prepend", "rcpath=$builddir",
NULL
};
or whatever, depending on -wrapper-arg/-wrapper-env, and having the
arg-parsing loop look through extra_argv as well as the normal argv.
But that's pretty inefficient, so I don't really suggest going that way.
But the point is, the requisite functionality for doing what
gmane.comp.gnu.libtool.patches/8429
needs is IN the cwrapper, and *tested*. It can then be *used* to
implement 8429.
--
Chuck