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

Previous Next

Full log

Message #8 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: Tue, 4 Jan 2011 23:36:05 +0100

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!

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.

> 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?

> Regards,
> 
> James
> 

Thanks,
  Stefano

Previous Next

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