Re: Failure in test silent5.test with heirloom make

[Stefano Lattarini]

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