Re: Bison and automake together
Andrew W. Nosenko andrew.w.nose...@gmail.com 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 another custom (unsupported especially by autoconf/automake) preprocessing tool. The same related to the classic Lex vs. Flex. 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. :-/ -- PMatos
Re: Bison and automake together
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 configure.ac and added: , | AC_PATH_PROG([BISON], [bison]) ` Then in Makefile.am: , | BISON_HEADER = scgparser.tab.hh | BISON_GENERATED = scgparser.tab.cc $(BISON_HEADER) | COMMON_OBJS = scgparser-driver.cc scgparser.yy scglexer.l \ | $(BISON_GENERATED) | | bin_PROGRAMS = scgc scgdoc scgmc | | scgc_SOURCES = scgc.cc $(COMMON_OBJS) | | $(BISON_GENERATED): scgparser.yy | $(BISON) --defines=$(BISON_HEADER) $ ` But then I get this annoying: , | Makefile.am: Yacc (C++) source seen but `YACC' is undefined | Makefile.am: The usual way to define `YACC' is to add `AC_PROG_YACC' | Makefile.am: to `configure.ac' and run `autoconf' again. | make: *** [Makefile.in] Error 1 ` 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 problem with ylwrap. If it's not supported then Yacc shouldn't display the error and abort the build. Am I right? -- PMatos
Re: Bison and automake together
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 problem with ylwrap. If it's not supported then Yacc shouldn't display the error and abort the build. In my opinion, ylwrap should gain knowledge about the used yacc implementation and pass a -o to it if the implementation supports it. That way, line numbers will be correct (aids debugging), header file inclusions will be correct (solves your problem) and it automatically allows for multiple yacc files to coexist in one project. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
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 to start to look into this problem with ylwrap and automake support this week something i;ve been meaning to do for about a year or so but havent had the time untill about now. I have some old projects which had multiple lexer's and parsers and ylwrap could help more in this regard which it doesnt there are tricks you can search the mailing list for old posts about this though. --Phil On 6 November 2010 17:06, Pippijn van Steenhoven pip8...@gmail.com wrote: 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 problem with ylwrap. If it's not supported then Yacc shouldn't display the error and abort the build. In my opinion, ylwrap should gain knowledge about the used yacc implementation and pass a -o to it if the implementation supports it. That way, line numbers will be correct (aids debugging), header file inclusions will be correct (solves your problem) and it automatically allows for multiple yacc files to coexist in one project. -- Pippijn van Steenhoven -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzVizIACgkQJc+zqGNdDgpmjgCgu153EM4ifKlkiVpb6EJdLJXx qigAn1HrC+EPynBJ96qty403O2aSudTO =r5cg -END PGP SIGNATURE-
Re: Bison and automake together
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
Re: Bison and automake together
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
Re: Bison and automake together
On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote: Then thats probably a bug although i havent played with GLR prarsers in bison you may want to post this to bison-help and see what they say. The thing is that bison does produce the y.tab.h header, which it then assumes to exist and #includes. It doesn't know ylwrap renamed it. You are supposed to say %defines myparser.h or pass bison a -o option so it produces myparser.c and myparser.h in the first place. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
On 1 November 2010 10:08, Pippijn van Steenhoven pip8...@gmail.com wrote: On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote: Then thats probably a bug although i havent played with GLR prarsers in bison you may want to post this to bison-help and see what they say. The thing is that bison does produce the y.tab.h header, which it then assumes to exist and #includes. It doesn't know ylwrap renamed it. You are supposed to say %defines myparser.h or pass bison a -o option so it produces myparser.c and myparser.h in the first place. Yep thing is though just like normal parsers with bison it doesn't have any hard-coded includes, and with GLR i _think_ it should be the same no? its for your bison head/field declarations section to do the include no? And since this breaks automake compatibility it sounds like a bug. Even though a work around exists. --Phil
Re: Bison and automake together
Pippijn van Steenhoven pip8...@gmail.com writes: On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote: Your bison file shouldnt generate any code with includes y.tab.h. You must have it in your field delcarations for bison. Its only your lexer needs to see these bison definitions. It does for GLR parsers. Also for C++ parsers, with , | %skeleton lalr1.cc ` or with same results using , | %language C++ ` This is an annoying issue that automake should strive to either solve or document since currently automake is not compatible with C++ bison generated parsers it seems. -- PMatos
Re: Bison and automake together
Pippijn van Steenhoven pip8...@gmail.com writes: I solved this problem by adding my own y.tab.h which does nothing but #include scgparser.h. But unfortunately each time bison is ran, the file is overwritten it seems. :( -- PMatos
Bison and automake together
Hi, I am slightly confused as to whether I should be posting this to the bison or this mailing list but here it goes. I have a bison based project which has the following definitions: , | BUILT_SOURCES = scgparser.h | AM_YFLAGS = -d | AM_LDFLAGS = -lgmpxx -lgmp | | bin_PROGRAMS = scgc | | scgc_SOURCES = scgc.cc scgparser-driver.cc scgparser.yy scglexer.l ` When I ran this with ./configure make I get: , | /bin/bash ./ylwrap scgparser.yy y.tab.c scgparser.cc y.tab.h \ | scgparser.h y.output scgparser.output -- bison -y -d ` This is ok because bison generates y.tab.c and y.tab.h that are renamed by ylwrap as scgparser.cc and scgparser.h respectively. However, bison generated parser scgparser.cc includes y.tab.h (which was the name known to bison when the file was generated). This results in an error during compilation since there is no y.tab.h anymore when the scgparser.cc is compiled. What am I missing here? Feel free to redirect me to the bison mailing list if this is not an automake config problem. Cheers, -- PMatos
Re: Bison and automake together
On 30 October 2010 11:46, Paulo J. Matos pocma...@gmail.com wrote: Hi, I am slightly confused as to whether I should be posting this to the bison or this mailing list but here it goes. I have a bison based project which has the following definitions: , | BUILT_SOURCES = scgparser.h | AM_YFLAGS = -d | AM_LDFLAGS = -lgmpxx -lgmp | | bin_PROGRAMS = scgc | | scgc_SOURCES = scgc.cc scgparser-driver.cc scgparser.yy scglexer.l ` When I ran this with ./configure make I get: , | /bin/bash ./ylwrap scgparser.yy y.tab.c scgparser.cc y.tab.h \ | scgparser.h y.output scgparser.output -- bison -y -d ` This is ok because bison generates y.tab.c and y.tab.h that are renamed by ylwrap as scgparser.cc and scgparser.h respectively. However, bison generated parser scgparser.cc includes y.tab.h (which was the name known to bison when the file was generated). This results in an error during compilation since there is no y.tab.h anymore when the scgparser.cc is compiled. What am I missing here? Feel free to redirect me to the bison mailing list if this is not an automake config problem. Your bison generated header also gets renamed by ylwrap, and yeah this is probably the best place to ask about this problem your bison header (y.tab.h) will get renamed to the same name as your bla.y but changed to bla.h. Notice the make line you posted was scgparser.cc y.tab.h scgparser.h See the y.tab.h then scgparser.h. Hope this helps! --Phil
Re: Bison and automake together
Hi, On Sat, Oct 30, 2010 at 11:46:25AM +0100, Paulo J. Matos wrote: However, bison generated parser scgparser.cc includes y.tab.h (which was the name known to bison when the file was generated). This results in an error during compilation since there is no y.tab.h anymore when the scgparser.cc is compiled. What am I missing here? I solved this problem by adding my own y.tab.h which does nothing but #include scgparser.h. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
Philip Herron redbr...@gcc.gnu.org writes: Your bison generated header also gets renamed by ylwrap, and yeah this is probably the best place to ask about this problem your bison header (y.tab.h) will get renamed to the same name as your bla.y but changed to bla.h. Notice the make line you posted was scgparser.cc y.tab.h scgparser.h See the y.tab.h then scgparser.h. I know, but that is not the problem. The problem is that the bison generated file includes y.tab.h but this doesn't exist since, as you said, ylwrap renames it. -- PMatos
Re: Bison and automake together
Pippijn van Steenhoven pip8...@gmail.com writes: I solved this problem by adding my own y.tab.h which does nothing but #include scgparser.h. Thanks. This sounds like a good workaround but it's far from a perfect solution. -- PMatos
Re: Bison and automake together
On 31 October 2010 18:49, Paulo J. Matos pocma...@gmail.com wrote: Philip Herron redbr...@gcc.gnu.org writes: Your bison generated header also gets renamed by ylwrap, and yeah this is probably the best place to ask about this problem your bison header (y.tab.h) will get renamed to the same name as your bla.y but changed to bla.h. Notice the make line you posted was scgparser.cc y.tab.h scgparser.h See the y.tab.h then scgparser.h. I know, but that is not the problem. The problem is that the bison generated file includes y.tab.h but this doesn't exist since, as you said, ylwrap renames it. Your bison file shouldnt generate any code with includes y.tab.h. You must have it in your field delcarations for bison. Its only your lexer needs to see these bison definitions. Heres some example: http://code.redbrain.co.uk/cgit.cgi/qub-mod-c/tree/src/ss-lexer.l http://code.redbrain.co.uk/cgit.cgi/qub-mod-c/tree/src/ss-parser.y --Phil
Re: Bison and automake together
On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote: Your bison file shouldnt generate any code with includes y.tab.h. You must have it in your field delcarations for bison. Its only your lexer needs to see these bison definitions. It does for GLR parsers. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: Bison and automake together
Then thats probably a bug although i havent played with GLR prarsers in bison you may want to post this to bison-help and see what they say. --Phil On 31 October 2010 23:03, Pippijn van Steenhoven pip8...@gmail.com wrote: On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote: Your bison file shouldnt generate any code with includes y.tab.h. You must have it in your field delcarations for bison. Its only your lexer needs to see these bison definitions. It does for GLR parsers. -- Pippijn van Steenhoven -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzN9cwACgkQJc+zqGNdDgrhqwCg4kJPoABYHKjEgSXjPd5M+5QT xwYAoLpUNUFTcQyVNk3U2S9uy+L7pt0P =rQxd -END PGP SIGNATURE-
