To be honest i think its more of a problem of the code bison is generating, though i should look into what happens in GLR parser and C++ i want to see for myself to judge it. But i do feel its on the bison side of things it shouldnt assume the name of the header and auto include. I assume though that GLR parsers and C++ parsers have the head declarations where you would generally include this manually yourself.
--Phil On 2 November 2010 08:44, Paulo J. Matos <pocma...@gmail.com> wrote: > Philip Herron <redbr...@gcc.gnu.org> writes: > >> Yeah this all seems like a bug to me, i dont do much C++ i prefer to >> use C so i havent used C++ bison parsers et'al . But yeah i have a few >> work arounds to get multiple bison and flex working i have some work i >> want to do to ylwrap to help it all but i really haven't got the time >> at the moment. Basically it could all be fixed with automake had more >> control over ylwrap or make ylwrap more dumb just makes things easier. > > Should we get this reported as a bug for automake? > For now a workaround is not to rename the .h file at all. Use y.tab.h > and that's it. Or if you want to use scgparser.h instead then just have > #include "y.tab.h" inside scgparser.h > > That should do the trick. It would nice, however to get this sorted out > in automake. > > Cheers, > > -- > PMatos > > >
