[Top][All Lists]
[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