Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.

[Gary V. Vaughan]

Hi Eric,

On 1 Nov 2011, at 22:03, Eric Blake wrote:

> On 11/01/2011 08:19 AM, Gary V. Vaughan wrote:
>> This next series of changesets is the beginning of modelling the directory
>> and filenaming conventions of Libtool to match what is done by other
>> prominent GNU projects... this means that gnulib scripts will require less
>> tweaking and configuration, so we can use them in the configuration in which
>> they have been most widely tested and debugged.  Also, it makes everything
>> look more familiar to anyone coming from another GNU project who is hoping
>> to generate some patches for us... and every little thing we can do to reduce
>> friction in that process is a net win as far as I am concerned.
>> 
>> I've attached the full patch which is ridiculously large for a simple
>> directory move and fixing the fallout in the files that care.
> 
> Next time, when sending a file rename patch, consider using 'git 
> format-patch/send-email -M -C'

Ahah!  I suspected it must be possible, because tig displays patches in that
much shorter format by default, but I didn't think to chase down the right
flags.  Thanks for the hint :)

> , which finds moves and renames and compresses them into a much smaller patch 
> output that names just the old and new file name and any incidental 
> differences between the two files (if I understand git correctly, the only 
> reason the smaller patch is not default is because it takes a bit more 
> processor time to determine file similarity and because it was not understood 
> by patch(1) back in the days when git used patch rather than its own tools 
> for parsing changesets; but I don't ever notice the difference, and 
> definitely appreciate the smaller diffs).
> 
> Or make those options permanent for your git setup, with 'git config --global 
> diff.renames true'.

Done.

> At any rate, I'm certainly in favor of this series, in the name of easier 
> maintenance, although I didn't review it closely.

Me too... I'm kinda surprised at the amount of cruft libtool is carrying around
right now, and moving decisively towards a gnulib based build is the perfect
opportunity to spring clean :)

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