GNU bug report logs - #7648
ylwrap appears not to support bison's lalr1.cc skeleton

Previous Next

Full log

Message #14 received at 7648 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: James Bostock <james.bostock <at> gmail.com>
Cc: 7648 <at> debbugs.gnu.org
Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
Date: Wed, 5 Jan 2011 20:32:10 +0100

On Wednesday 05 January 2011, James Bostock wrote:
> And thank you for getting back to me. Given the time of year, I
> wouldn't consider your reply late :). More inline below.
> 
> On Tue, Jan 4, 2011 at 11:36 PM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
> > Hello James.
> >
> > Thanks for your report, and sorry for the late reply.
> >
> > On Wednesday 15 December 2010, James Bostock wrote:
> >> Hi,
> >>
> >> Automake version 1.11.1
> >> Autoconf version 2.67
> >> Bison versions 1.875 and 2.4.1
> >>
> >> If bison is directed to use the lalr1.cc skeleton file then although
> >> ylwrap renames the files generated by bison, it does not update the
> >> generated parser source code to #include the renamed header file.
> >>
> > Actually it's even worse than that: the generated y.tab.h "#include"s
> > two other bison-generated header files (stack.hh and location.hh) that
> > end up being removed by the ylwrap script!
> 
> Yes, after submitting the bug report, I came across this too. The
> reason that I didn't run across this from the outset is that while
> trying to get things up and running, I ran bison manually and so these
> files just happened to be lying around. Starting from scratch, I ran
> into this and added another crude hack to the ylwrap script.
>
OK, all makes sense now.  Thanks for letting us know!

> >
> > JFTR, here is how that happens.  The ylwrap script works by doing a
> > chdir into a temporary directory, calling yacc from there, renaming
> > and editing the generated files, and then moving them back to the
> > original directory.  In your case, since ylwrap knows nothing about
> > the bison-generated 'stack.hh' and 'location.hh' header files, it
> > doesn't copy them back in the original directory, so that they are
> > lost when the temporary directory is removed.  D'oh!
> >
> > I'm still undecided if at this point we should just (try to) rewrite
> > the messy ylwrap script, or if it would be better to teach automake
> > to recognize when it's using bison as $(YACC), and take advantage of
> > more bison features in this case -- which would probably allow to
> > bypass the use of ylwrap altogether.
> 
> For what it's worth, I think the preferable solution would be to add
> an AM_BISON macro to detect the presence of bison and, if it is
> present, not use ylwrap at all as, unless in compatability mode,
> bison's output files are named after the input grammar file anyway,
> obviating the need for ylwrap.
>
Hmm... I agree, especially because most of the problems of ylwrap derive
anyway from the use of bison-specific flags and features.

If the change you propose is implemented, than:
 - either you avoid to use bison-specific features in you packages,
   and in this case AC_PROG_YACC and ylwrap should be good enough; or:
 - you use the new AM_PROG_BISON macro, bypassing ylwrap completely,
   (and living happier probably :-).

> I had a look at the automake code but
> as this doesn't seem to be trivial (at the same time, I don't think it
> should be too complicated), I gave up on trying to do it myself.
>
I'll put writing a patch about this issue on my TODO list; I agree
it shouldn't be too complicated (and will give me an excuse to add
more tests about Yacc support ;-)

> >
> >> Attached is a test script that illustrates the problem.
> >>
> >> In more detail, the generated parser tries to #include the file "y.tab.h":
> >>
> >>  48
> >>  49 #include "y.tab.h"
> >>  50
> >>
> >> But y.tab.h has been renamed to zardoz.h by ylwrap, causing compilation to fail:
> >>
> >> $ make
> >> g++ -DPACKAGE_NAME=\"yaccpp2\" -DPACKAGE_TARNAME=\"yaccpp2\"
> >> -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"yaccpp2\ 1.0\"
> >> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"yaccpp2\"
> >> -DVERSION=\"1.0\" -I. -I..     -g -O2 -MT zardoz.o -MD -MP -MF
> >> .deps/zardoz.Tpo -c -o zardoz.o zardoz.cc
> >> zardoz.cc:49: fatal error: y.tab.h: No such file or directory
> >> compilation terminated.
> >>
> >> For a personal project, I made the following modifications to the
> >> ylwrap script but I doubt that I have considered every possible usage
> >> of ylwrap.
> >>
> >> $ diff -u /usr/share/automake-1.11/ylwrap ylwrap
> >> --- /usr/share/automake-1.11/ylwrap   2010-02-02 01:59:15.000000000 +0100
> >> +++ ylwrap    2010-10-15 21:58:04.693283559 +0200
> >> @@ -188,6 +188,17 @@
> >>            mv -f "$target" "$realtarget"
> >>          fi
> >>        fi
> >> +
> >> +      # Update #include directives
> >> +      case "$target" in
> >> +       *.cc)
> >> +           base=`basename $target .cc`
> >> +           mv $target $target.tmp
> >> +           sed "s/y.tab.h/$base.h/g" $target.tmp > $target
> >> +           rm $target.tmp
> >> +           ;;
> >> +      esac
> >> +
> >>      else
> >>        # A missing file is only an error for the first file.  This
> >>        # is a blatant hack to let us support using "yacc -d".  If -d
> >>
> > Hmmm...  accordingly to my analysis above, this workaround is not
> > enough, and in fact it fails for me.  Does it really works for you?
> 
> You are referring to the additional header files that bison generates
>
Yes, and your explanation above dissolved my doubts about this issue.

> or is there some other problem that you see?
>
Nope.

> Adding support for the location.hh and stack.hh header files (elsewhere
> in the script), the change above does seem to work for me.
>
Exactly.

Thanks,
   Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.