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
>>
Paul Smith writes:
> As for why 3.82 is slower, unfortunately I'm having problems figuring it
> out. I compiled with gprof but the cumulative profiled code in GNU make
> only took 6 seconds or so, so I suppose the other 24 seconds must be in
> libc or someplace... but trying to install a profile-
On 10/31/2010 06:24 PM, Paul Smith wrote:
> All I can assume is there's some difference in heap management in 3.82
> which is causing this, because that's the only difference I can think of
> that would not show up in the GNU make code itself. I'll try using
> valgrind and see what I get. If any
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
On Thu, 2010-10-28 at 12:18 -0400, Paul Smith wrote:
> > Is there anything I can help with? bisect GNU make 3.81 -> 3.82 to see when
> > it
> > got slower? Or anything on our GNU make/automake usage? E.g. we use a non
> > recursive makefile
>
> I'll try to look into this more this afternoon/tonig
On Sun, Oct 31, 2010 at 11:54:04AM +0100, Jan Engelhardt wrote:
> Hi,
>
>
> While trying to utilize Autotools in a preexisting project that
> previously just relied on Makefiles, I came across ylwrap failing for
> some absurd, unknown reason. I couldn't help but run sh -x and debug it
> piecew
On Sunday 2010-10-31 16:42, Philip Herron wrote:
>>
>> While trying to utilize Autotools in a preexisting project that
>> previously just relied on Makefiles, I came across ylwrap failing for
>> some absurd, unknown reason. I couldn't help but run sh -x and debug it
>> piecewise.
>>
>> So what's u
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 31 October 2010 10:54, Jan Engelhardt wrote:
> Hi,
>
>
> While trying to utilize Autotools in a preexisting project that
> previously just relied on Makefiles, I came across ylwrap failing for
> some absurd, unknown reason. I couldn't help but run sh -x and debug it
> piecewise.
>
> So what's u
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
On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote:
> On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues
> wrote:
>> * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET:
>>> Automake somehow defines AR to 'ar'. I'm not sure where this comes
>>> from, but I do know that it's definitely not $
On 31/10/2010 10:20, Ralf Wildenhues wrote:
* Paul J. Davis wrote on Sun, Oct 31, 2010 at 12:10:01AM CEST:
On Oct 30, 2010, at 5:17 PM, Jason Curl wrote:
When building my package with "./configure" everything works well as
some datafiles that are required for tests are in the correct place
(my
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
Hi,
While trying to utilize Autotools in a preexisting project that
previously just relied on Makefiles, I came across ylwrap failing for
some absurd, unknown reason. I couldn't help but run sh -x and debug it
piecewise.
So what's ultimately done is running flex inside a temp directory,
* Paul J. Davis wrote on Sun, Oct 31, 2010 at 12:10:01AM CEST:
> On Oct 30, 2010, at 5:17 PM, Jason Curl wrote:
> > When building my package with "./configure" everything works well as
> > some datafiles that are required for tests are in the correct place
> > (my tests don't need to be installed
18 matches
Mail list logo
