[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 14:30:46 +0200 |
User-agent: |
KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.2; i686; ; ) |
At Wednesday 21 April 2010, Ralf Wildenhues <address@hidden>
wrote:
> > > [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.
Right. That's mostly used (and probably mostly intended) to ease
"portability testing". And that's the only reason I use it for.
> > 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.
So you're telling that there is a OpenSolaris make version which can
run on Linux? Where can I download/obtain it?
> > > 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.
Sorry, I uncorrectly surmised from your mail that heirlooom-make
was buggy in this respect. If it's not, then you're right that it's
probably better to let 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.
I'll try to take a look at this (maybe not soonish).
Thanks,
Stefano