Subject: bug#7648: closed (Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 16 Jul 2012 09:24:03 +0000

Your bug report

#7648: ylwrap appears not to support bison's lalr1.cc skeleton

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
7648: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton
From: Stefano Lattarini <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 16 Jul 2012 11:17:49 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On 07/14/2012 11:34 AM, Stefano Lattarini wrote:
> Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648>
> 
> The bug has finally been fixed by Akim Demaille (kudos to him); the fix
> will appear in the next maintenance version of Automake (1.12.3).
> 
> See the thread:
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00088.html>
> and in particular the messages:
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00123.html>
>   <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00139.html>
> 
> I will proceed to close this bug report once those patches are actually
> merged into maint.
>
Done.  I'm thus closing this bug report.

Thanks,
  Stefano

Subject: ylwrap appears not to support bison's lalr1.cc skeleton
From: James Bostock <[email-masked]>
To: [email-masked]
Date: Wed, 15 Dec 2010 19:27:19 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Regards,

James