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

[Eric Blake]

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.

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

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature