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: 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





reply via email to

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