bug-automake
[Top][All Lists]
Advanced

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

Re: Failure in test silent5.test with heirloom make


From: Ralf Wildenhues
Subject: Re: Failure in test silent5.test with heirloom make
Date: Wed, 21 Apr 2010 07:55:50 +0200
User-agent: Mutt/1.5.20 (2009-10-28)

* Stefano Lattarini wrote on Wed, Apr 21, 2010 at 12:41:21AM CEST:
> At Tuesday 20 April 2010, Ralf Wildenhues wrote:
> > Yeah, the make has a .l.o rule that triggers before our .l.c and
> >  .c.o rule chains.
> Do you know if this happens also with Solaris make, or is just a quirk 
> specific to heirloom-make?

It doesn't fail with Solaris 9 make.

> > [FROM ANOTHER MAIL]
> > Where can I get this heirloom-make?  Is there a Debian package for
> > it? 
> For the record, heirloom make is part of the Heirloom project 
> <http://heirloom.sourceforge.net/>,

Thanks.  This is really really low priority.  Basically nobody uses that
because they have to.

> > I'm not bound to bother much with this issue because no user is
> > forced to pain herself with heirloom-make (and even Solaris make is
> > better).
> Well, I'm using heirloom-make for testing purposes only, since it 
> seems to be the most Solaris-like make implementation easily available 
> also on GNU/Linux.  If you have a pointer to a similar make 
> implementation without the heirloom-specific quirks, I'd be happy to 
> use it instead.

Yes: Solaris make.  I'm guessing OpenSolaris version is derived from
that.

> > I guess this could be worked around by adding explicit rules (at
> >  least that's what SUSv3 recommends), maybe explicit dependencies
> >  without rules suffice.  I'm not sure we should spend time on this
> >  old make, though.
> I think you're right.  Maybe the best solution for the present problem 
> would be to properly divide `silent5.test' into many, more specific 
> tests (e.g. one for c++, one for fortran, one for lex etc.), and then 
> skip the Lex/Yacc test(s) if a buggy make is detected.

No, why?  The test fails for a reason.  The 'make' is not buggy wrt.
Posix, it works as documented.  There is no reason to not let the test
fail.

I've already noted earlier how to address the problem: help the 'make'
by producing explicit rules, either without or with commands; you could
try to find out whether it is sufficient to not specify the rules.

Cheers,
Ralf




reply via email to

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