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:
> Hello Stefano,
> 
> * Stefano Lattarini wrote on Fri, Sep 24, 2010 at 04:38:29PM CEST:
> > On Wednesday 15 September 2010, Ralf Wildenhues wrote:
> > > I don't think we want subobj11c.test.  What we want instead,
> > > and I agree with your earlier sentiments on this, is unit
> > > testing for the normalize_file_name function.  Which suggests
> > > that it should be in lib/Automake/FileUtils.pm I guess,
> > 
> > I disagree, it would be a text-transformation function which
> > doesn't really belong to that file.
> 
> What I meant was just the functionality of normalizing a file name
> to not contain non-leading multiple slashes.  That would quite
> well fit in FileUtils, and also could be usable for other things
> as well.
Oh.  This is true.
 
> Computing a dependency file name might be done *on top of that*,
Not sure about that, the code in my proposed `compute_depfile_path'
seems too ad-hoc to be easily implemented on the top of another 
function.
> in another function, sure.  But "Misc" is not a good category for
> that, and I don't quite see yet where it would be reusable.
If you mean `compute_depfile_path', well, it wouldn't. But at least,
putting it in a module would make it unit-testable.  That said...
 
> > BTW, in the long run, my idea would be to move *almost all* of
> > automake.in into a "temporary" module `Automake::Main', to ease
> > its unit-testability.
... with this implemented, we could just leave `compute_depfile_path'
and other ad-hoc functions in `Automake::Main', and they could be
easily unit-tested, without the need to introduce a confusing module
`Automake::Misc'.

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

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

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.")?

Regards,
   Stefano