You can look at the problem in 2 ways, really you can say ylwrap is
too simplistic and not great which is correct but it does work for
standard-ish inputs like C parsers. But c++ and GLR doesnt work right
but you could say they dont comform to the standard way ylwrap expects
so it fails.
I do want
On Sat, Nov 06, 2010 at 04:37:26PM +, Paulo J. Matos wrote:
> Does someone confirm that there is a bug here?
> Bison in C++ mode with -y compatibility mode generates a file which
> includes y.tab.h. ylwrap _cannot_ rename the file or compilation will
> fail. If C++ is supported there's a proble
pocma...@gmail.com (Paulo J. Matos) writes:
>
> I understand your opinion, unfortunately it then means that there's no
> support for Bison in C++ mode from the automake side which is
> unfortunate. :-/
I decided to forget automake support and instead go for my own:
So, I removed AC_PROG_YACC from
"Andrew W. Nosenko" writes:
>
> Therefore, there is no need neither AC_PROG_YACC nor ylwrap. Just
> need move them away, don't use them. Anyway, if byacc (for example)
> will be found and cough, it won't process GLR-targeted .y source
> anyway. Just threat bison like would be threated any anot