bug or feature

YONETANI Tomokazu qhwt+dfly at les.ath.cx
Thu Jan 6 07:34:11 PST 2005


On Thu, Jan 06, 2005 at 03:48:18PM +0100, Joerg Sonnenberger wrote:
> On Wed, Jan 05, 2005 at 09:23:20PM -0800, Matthew Dillon wrote:
> >     There's nothing wrong with make.  The make clean target is not removing
> >     the temporary expr.c file generated by previous runs of make before you
> >     changed expr.y to expr.c, and it is that expr.c that it is finding.
> > 
> >     If you do that you will see that the standard conversion rules will
> >     cause yacc to be run to generate the .c file from the .y file.  That's
> >     documented conversion rule behavior for make.
> > 
> >     So the bug is simply that the Makefile is missing a CLEANFILES= expr.c
> >     line (or one of the .mk files is).
> 
> It's not that simple. Just create a new directory, copy the expr.y into it
> and add a Makefile containing only "expr: expr.c". Run make and it will
> create the expr.c from expr.y.
> 
> Second try: create expr.c and touch expr.y afterwards. It will still run
> yacc to generate expr.c.
> 
> This is what created the problem with GCC 3.4 back than, we had both
> the bison generated C sources (which I originally had in the
> Makefile's SRCS) and the .y source. CVS checkout creates X.c before X.y,
> so the yacc source is always newer than the C source. It wasn't a problem
> in the GCC case, because yacc handles the sources fine. It can be a problem
> for newer CVS version, because the included getdate.y isn't compilable by
> yacc anymore. I'm thinking about adding the reentrant parser support, but
> I have to read the sources more.

While trying to upgrade grep to grep-2.5.1 in my tree(also in this case
recent version of bison was required instead of yacc to generate .c file
from .y file), I found that adding an empty suffix rule(shown below) to
the Makefile avoids the implicit rule no matter whether .y source is newer
or not:

%%%
# disable implicit rule in sys.mk, and always use pre-built version
. y.c:

%%%





More information about the Kernel mailing list