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

[Ralf Wildenhues]

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?

Guess I need to think about that then.

Still, I don't like big code churn without a clear direction.

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

I'm not too afraid of merge conflicts, in case of doubt I can try to do
the hard merge parts.

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

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

Thanks,
Ralf