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
On Tue, Nov 2, 2010 at 18:34, Philip Herron 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
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 th
Philip Herron 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
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. Bas
Pippijn van Steenhoven 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
Pippijn van Steenhoven 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 f
On 1 November 2010 10:08, Pippijn van Steenhoven 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
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
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 wrote:
> On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote:
>> Your bison file shouldnt
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 Steenhov
On 31 October 2010 18:49, Paulo J. Matos wrote:
> Philip Herron 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
>>
Pippijn van Steenhoven 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
Philip Herron 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 scgpa
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
> scgparse
On 30 October 2010 11:46, Paulo J. Matos 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
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
|
| s
20 matches
Mail list logo
