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
