libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/4] libtoolize: simplify file-copying and -linking call-grap


From: Gary V. Vaughan
Subject: Re: [PATCH 1/4] libtoolize: simplify file-copying and -linking call-graph.
Date: Wed, 16 Nov 2011 10:14:09 +0700

Hi Eric,

Thanks again for taking the time to review these patches.

On 16 Nov 2011, at 00:00, Eric Blake wrote:
> On 11/14/2011 04:04 AM, Gary V. Vaughan wrote:
>> This series of changesets are either necessary for, or at least
>> make the application of the directory move patches coming in the
>> next set as straight forward as possible.
>> 
>> It turns out that we haven't needed to fork a tar process for
>> every file-copy for about 4 years now.  With that knowledge it's
>> easy to reduce the complexity of the surrounding functions
>> somewhat.
>> 
>> I'll apply in 72 hours, along with addressing any feedback I
>> get in the mean time.
>> 
>> @@ -112,8 +110,7 @@ M4SH_GETOPTS(
>>      CP="func_echo_all $CP"
>>      test -n "$LN_S" && LN_S="func_echo_all $LN_S"
>>      MKDIR="func_echo_all $MKDIR"
>> -    RM="func_echo_all $RM"
>> -    TAR="func_echo_all $TAR"],
>> +    RM="func_echo_all $RM"],
> 
> My only concern is whether existing projects may have been
> (inadvertently) relying on $TAR to be set on their behalf by using libtool.

Libtool's setting of TAR was never exported to the environment, so I'm
pretty sure that its use inside of libtoolize has always been invisible,
(except of course that until recently it wastefully forked a process that
could be influenced by the environment TAR value for every file it
installed).

> The reason I ask is that I know of at least one case where a project was
> using libtool, but manually setting $RM itself to a value different than
> libtool's default, which in turn caused libtool to emit a warning:
> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=8a93dafc5

That's slightly different in that it means another tool could influence
the behaviour of libtool by setting an environment variable it depends on.

> That is, dropping $TAR is a user-visible change, so we either need to
> document it in NEWS that it is intentional, or we need to keep providing
> $TAR (even though we no longer use it) to keep our namespace pollution
> constant, all so that users upgrading to newer libtool don't complain
> about an undocumented change.

We definitely don't need to keep TAR, because there's never been any way
for another program to access libtoolize's setting.

I can't imagine a scenario where setting TAR in libtoolize's environment
would have worked before removing our reliance on it but broken afterwards.

Am I missing something here?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



reply via email to

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