libtool-patches
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]