[Top][All Lists]

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

Re: [PATCH] {yacc-work} coverage: more on 'yacc -d' and recovery from de

From: Stefano Lattarini
Subject: Re: [PATCH] {yacc-work} coverage: more on 'yacc -d' and recovery from deleted headers
Date: Sat, 29 Jan 2011 14:48:12 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Saturday 29 January 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Sat, Jan 29, 2011 at 02:20:00PM CET:
> > On Saturday 29 January 2011, Ralf Wildenhues wrote:
> > > I agree with everything except ...
> > > 
> > > >  BUILT_SOURCES = parse1.h p2-parse2.h
> > > > address@hidden@: parse3.h
> > > 
> > > ... this line shouldn't be there, other than to workaround
> > > a bug in automake;
> > >
> > Why not?  IMO it increases coverage by showing that, when we know
> > which files include a yacc-generated header, we can just declare
> > dependencies directly instead of relying on the $(BUILT_SOURCES)
> > hack, and still have things work correctly.
> Ah, so it was done on purpose.  Well, ok then, but it wouldn't be
> good to document this in the manual, because this line relies on
> either of the two facts that @OBJEXT@ hides the actual name from
> automake, and there is a matching inference rule for the object
> (automake will not produce a rule for some target if you put a
> rule for that target in the, even if your rule does
> not contain commands;
JFTR: I never liked this behaviour, which IMHO greatly reduce the
transparency of automake.  But that's for another thread anyway
(and another day, probably).

> cf. the comment about this in

I will push this patch (and other approved ones which are still
pending) shortly.


reply via email to

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