automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [PATCH v3 2/?] Work around a bug in Solaris make's file-inclusion mechanism.
Date: Sun, 26 Sep 2010 08:50:36 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

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.

Computing a dependency file name might be done *on top of that*, 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.

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

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]