[Bug-gnubg] Is anyone else seeing ylwrap problems building gnubg?

[Jim Segrave]

I just got a new laptop and, after getting FreeBSD and X up and
running, I went to build gnubg from CVS. When I tried, the make failed
on external_y.c:

after building timer.o:
/usr/local/bin/bash ./ylwrap `test -f 'external_y.y' || echo
'./'`external_y.y y .tab.c external_y.c y.tab.h external_y.h 
y.output external_y.output -- bison -y  -d
gmake[2]: *** [external_y.c] Error 1
gmake[2]: Leaving directory `/usr/home/jes/gnubg'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/jes/gnubg'
gmake: *** [all] Error 2

I then tried on my old Linux laptop, runnnig RedHat 9. Same failure
with current sources. On the Linux box, I tried a binary search to
find when it broke (my installed copy was April 21). I found the
problem came and went. Further investigation seems to suggest that
bison isn't doing what ylwrap expects it to do. ylwrap takes the
traditional yacc output files - y.tab.c y.tab.h and gets them named to
seomething sensible. Bison does not normally produce these names, 
bison external_y.y will produce external_y.c and external_y.h. 

ylwrap is suppoesed to invoke bison (or whatever yacc-alike you are
running) in a subdirectory, then copy and rename the input files back
in gnubg's directory. Actually it's not a copy, it uses sed to do some
other internal name fixups. If the yacc-alike is bison, the -y flag is
given and, according to the bison man page, should produce the old
style output file names. Testing with bison 1.35 on Linux and 1.85 on
FreeBSD failed to ever produce a y.tab.c or y.tab.h file. So if make
ever decides to rebuild either external_y.c/external_y.h, external_l.c
or external_l.h, it will run ylwrap, which will fail.

Am I missing something?

-- 
Jim Segrave           address@hidden