[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patch] cwrapper invokes target directly
From: |
Ralf Wildenhues |
Subject: |
Re: [Patch] cwrapper invokes target directly |
Date: |
Tue, 27 May 2008 08:51:17 +0200 |
User-agent: |
Mutt/1.5.17+20080114 (2008-01-14) |
* Charles Wilson wrote on Tue, May 27, 2008 at 07:51:32AM CEST:
> Ralf Wildenhues wrote:
>> * Charles Wilson wrote on Sat, Apr 26, 2008 at 10:22:39PM CEST:
>
>> 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
> };
It might even be as simple as inserting *literal* code into cwrapper like
lt_setenv("FOO", "bar");
I understand that --lt-env-set may help debugging, but in the end, there
is no need to expose more unportable interface than necessary.
> 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.
Which is good, even if cwrapper can lose a third of its code to achieve
the same.
Cheers,
Ralf