[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `bu
Gary V. Vaughan
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
Sat, 5 Nov 2011 19:25:03 +0700
On 2 Nov 2011, at 16:29, Stefano Lattarini wrote:
> On Wednesday 02 November 2011, Gary V wrote:
>> I like to make sure the tree is capable of passing `make distcheck' after
>> every patch,
> And this is a very good policy, with which I fully agree. What I meant
> was: wouldn't be better to introduce the $(auxdest), $(macrodest) and
> $(ltdldest) in a preparatory patch (with no semantic change), so that
> the edit to `Makefile.am' done in the present patch patch can be brought
> down to a minimal change like "auxdest = config" => "auxdest = build-aux"?
>> and splitting this one into "move directories around" and
>> "fixup the aftermath" would leave the tree broken in the middle...
> This is not what I proposing, not at all! What I was proposing is:
> 1. in a first, preparatory patch, factor out the names/locations of
> the directories in proper variables and/or makefile macros;
> 2. in the "real" patch, move the directories around, leveraging on the
> previous refactoring to ensure this moving can be done with smaller
> and more self-contained changes.
> Sorry if I failed to express myself correctly; I hope I've made my
> point clearer this time.
Yes indeed, the misunderstanding was mine. And you raise a good point.
I have always tended to break a series of changes into patches in such
a way that each individual patch is doing *something*... otherwise it's
easy to get to a point where everything is so fine grained that you lose
all sense of direction... my patch queue is already 40 patches deep, and
if I had to go through those and break them into ever smaller pieces, it
would slow my progress dramatically.
However, I'll post all but the most trivial patches to this list at least
a few days before pushing... and I would be extremely happy for you to
raise a flag if you think any particular patch is too broad in scope.
Gary V. Vaughan (gary AT gnu DOT org)