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