On Tue, Nov 2, 2010 at 18:34, Philip Herron <redbr...@gcc.gnu.org> wrote: > 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.
Excuse me, but why this issue raised at all? If I understand correctly, the ylwrap (and paired autoconf macro, AC_PROG_YACC, IIRC) is a helper for a classic yacc and compatible ones, intended for work with classic yacc's input and output and therefore, .y files should be one that may be understood by classic yacc. Otherwise all these compatibility layers have no sense. If it's known that "compiler's compiler" is Bison and what output files are, then there no need to search through possible yacc implementation nor guess what output files will be generated. And it is known, just because GLR is used there, which is bison and bison only feature. 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 another custom (unsupported especially by autoconf/automake) preprocessing tool. The same related to the classic Lex vs. Flex. -- Andrew W. Nosenko <andrew.w.nose...@gmail.com>
