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

[Jim Segrave]

On Tue 01 Jun 2004 (08:38 +0100), Jon Kinsey wrote:
> Jim Segrave wrote:
> 
> >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?
> 
> Hi Jim,
> 
> I changed external_y.y to produce external_y.c, this is probably what's 
> going wrong.  We can either change it back (so bison produces y.tab.c 
> etc.) or not use ylwrap.
> 
> You can check it's this by removing the following line from external_y.y:
> %output="external_y.c"

Yes - that fixes it. I suppose we should do this, but I'm not
sure. ylwrap is an ugly hack, but if some people are building gnubg on
a system without a gnu toolchain, this will introduce problems. 

-- 
Jim Segrave           address@hidden