[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: |
Stefano Lattarini |
Subject: |
Re: Failure in test silent5.test with heirloom make |
Date: |
Wed, 21 Apr 2010 00:41:21 +0200 |
User-agent: |
KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.2; i686; ; ) |
At Tuesday 20 April 2010, Ralf Wildenhues <address@hidden>
wrote:
> * Ralf Wildenhues wrote on Tue, Apr 20, 2010 at 11:25:41PM CEST:
> > I'm guessing this has to do with chains of inference rules not
> > being detected or so.
>
> 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?
> [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/>, which provides many unix utilities
and developement tools derived from original Unix material released as
Open Source by Caldera and Sun.
The manpage for heirloom make is here:
<http://heirloom.sourceforge.net/devtools/make.1.html>
from which is appearent that it has a builtin `.l.o' rule.
> [FROM ANOTHER MAIL]
> 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.
> 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.
WDYT?
Regards,
Stefano