Re: [PATCH v3 2/?] Work around a bug in Solaris make's file-inclusion mechanism.

[Stefano Lattarini]

On Sunday 26 September 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Sun, Sep 26, 2010 at 11:58:09AM CEST:
> > On Sunday 26 September 2010, Ralf Wildenhues wrote:
> > > * Stefano Lattarini wrote on Fri, Sep 24, 2010 at 04:38:29PM 
CEST:
> > > > Then we could proceed to refactoring, and split it up in
> > > > several separate modules where needed, thus improving
> > > > modularity and clarity.  But this second step should be
> > > > undertaken only once we have enough testsuite coverage --
> > > > no, the present one is definitely not enough IMHO).
> > > 
> > > For such an approach, I'd first like to see, and discuss, a
> > > design layout for the intended structre.
> > 
> > But that would be for the second step; the first step (creation
> > of `Automake::Main') shouldn't change the structure of
> > automake.in, just move it to make it easily unit-testable.  Then
> > we could discuss the design layout for the intended structre, or
> > even decide not to change the structure at all.
> 
> Hmm.  Your argument for this ordering is that you can test
> Automake::Main better than you could test the current code, is that
> right?
Yes.
 
> Guess I need to think about that then. 
> Still, I don't like big code churn without a clear direction.
The clear direction is "make the code more easy to unit-test" (this 
can be accomplished in a single step, in fact).  The not-so-clear 
future direction is "going towards a big refactoring and code 
reorganization", but as I said, that's not a necessity, and the 
creation of Automake::Main is IMHO valuable even if no further 
refactoring follows.
 
> > > Not ad-hoc hacking and factorizing like this, that has a good
> > > chance to create a mess in the long run.
> > > 
> > > Which is the reason I'm rejecting this patch for now, sorry.
> > 
> > I'll happily repropose it when the patch queue is stabilized
> > enough to allow the creation of `Automake::Main'.
> 
> Please consider that it may not ever get to the point where you
> might find it stable enough.  ;-)
Good point.  Sigh.
 
> I'm not too afraid of merge conflicts, in case of doubt I can try
> to do the hard merge parts.
OK, I'll attempt a patch for a new branch than (not before this 
evening, though).
 
> > > > I'm not trying to do this code reoarganization now, because
> > > > it would disrupt useful pending patches, at least:
> > > It could be done in a branch only to be merged strictly
> > > afterwards.
> > 
> > Yes, but the merge would imply basically a huge conflict over all
> > automake.in, and require a by-hand re-application of those
> > patches I talked about.  No thanks.
> 
> As long as lots of the code has only moved literally, it should be
> possible to automate it.  git already has a few merge drivers,
> maybe there's one already mostly up to the task.
Let's hope so.

> > BTW, with this mail are you rejecting also the first part of the
> > patch ("[PATCH v3] Work around a bug in Solaris make's
> > file-inclusion mechanism.")?
> 
> No.  I hope to get to that patch today.
OK, good.

Thanks,
  Stefano