bug-gnubg
[Top][All Lists]
Advanced

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

[Bug-gnubg] Makefile problem with flex/bison files


From: Jim Segrave
Subject: [Bug-gnubg] Makefile problem with flex/bison files
Date: Wed, 5 Jan 2005 00:59:30 +0100
User-agent: Mutt/1.4.1i

I noticed recently that the dependancies for sgfl and sgfp are not
correctly expressed in the Makefile. If I pull the CVS source, do
autogen/configure/make, then the CVSed versions of sgfp.c and sgfl.c
are compiled and linked. I get a working gnubg

If you run make again, immediately afterwards, something odd happens:
First, bison is ron on sgf.y to produce a new sgfp.c. This also
produces a new sgfp.h. Then, since sgfl.o depends on sgfp.h, this is
recompiled. sgfp.c is *not* recompiled. With the version of bison and
flex I'm running, the token numbers from the new sgfp.h are different
than the CVSed ones, so the parser produces new token identifiers. But
sgfp.c hasn't been recompiled, so now you get parse errors with this
version of gnubg when reading .sgf files.

If you run make a third time, sgfp.c is recompiled. Now it's using the
same token IDs as sgfl.c produces and things work again.

The errors appear to be:

1) that I can't see any reason for make to run bison on sgf.y to make
   a new sgfp.c. 
2) once a new sgfp.c is created, it should be compiled afterwards,
   along with sgfl.c
3) if you are foolish and touch sgf.l then do a make, this happens:
   sgfl.c is created (good)
   sgf.c  is created - this is very much not good, as sgf.c has no
   relation to the flex/bison files and is lost by this
   process. ylwrap thinks it ought to put the output in sgf.c, not
   sgfl.c, which is not a good thing to do.

I'm not sure why we're using ylwrap, it's a pretty awful shell
script. The only problem I see is that flex wants -Pprefix and yacc
(or at least the FreeBSD version) wants -pprefix.

-- 
Jim Segrave           address@hidden





reply via email to

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