automake-patches
[Top][All Lists]
Advanced

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

Re: More problems with `make -n' in automake-generated rules.


From: Ralf Wildenhues
Subject: Re: More problems with `make -n' in automake-generated rules.
Date: Thu, 4 Nov 2010 21:58:56 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* Stefano Lattarini wrote on Thu, Nov 04, 2010 at 09:50:08PM CET:
> On Thursday 04 November 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET:
> > > Hello Ralf.  Again, just a couple of nits w.r.t. the test cases...
> > 
> > Thanks; but I didn't mean to actually commit the second patch
> > (just in case that wasn't clear).

> I didn't get that, sorry.  Anyway, why you don't want to commit this second
> patch?

Causes a slowdown without gain for the user.

> While its usefulness is admittedly limited, being a little bit more
> correct (even if only theoretically) wouldn't hurt IMHO.

But then there is no argument to not also fix the other configure.am
rules (which also have problems in even more obscure and hard-to-use
cases).  I gave up trying to write exposers for them.

> > > > +# The subdir rebuilding rules rely on GNU make automatically updating
> > > > +# the makefile and its prerequisites (through am--refresh).
> > > > +required=GNUmake
> > > Why requiring GNU make here?  After all, if a make implementation does not
> > > implement automatic Makefile-rebuild rules, it should trivially pass this
> > > test, and if implements them, it makes sense to run this test on it too.
> > 
> > But that requires me to think about the test again: was this really
> > meant to test portable code?  The rebuilding rules, esp. the am--refresh
> > trick, rely on GNU make-specifics, and special-casing some test of it
> > just because it may or may not happen to trigger the specifics doesn't
> > seem robust.  I don't want the next small patch to this test cause a
> > failure for non-GNU make, a failure I'm really not interested in in this
> > test.
> > 
> > Does that make sense?
> Yes.  I'd still prefer to leave the GNU make requirement out, and add it
> back when (and if) the necessity arise, but I can see your point too.

The point is that this lowers maintainability: I'll have to check again
whether that necessity has arisen or not.

> It's mostly a matter of tastes here, and since I have no strong opinion
> on the issue, I'm OK with keeping GNU make in $required.

Cheers,
Ralf



reply via email to

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