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

[James Bostock]

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
<address@hidden> 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.

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

>
>> 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
or is there some other problem that you see? Adding support for the
location.hh and stack.hh header files (elsewhere in the script), the
change above does seem to work for me.

>
>> Regards,
>>
>> James
>>
>
> Thanks,
>  Stefano
>

Regards,

James