bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Bison 1.50a] testsuite.log: 19 failures


From: Paul Eggert
Subject: Re: [GNU Bison 1.50a] testsuite.log: 19 failures
Date: Fri, 25 Oct 2002 11:50:20 -0700 (PDT)

> From: Akim Demaille <address@hidden>
> Date: 25 Oct 2002 10:04:04 +0200

> Hum, I think I added even more confusion :)  When you said `doing by
> hand' I did understood make alpha failed for you, but even by hand you
> ran make dist, which (should) makes sure the test suite is up to date.

Oh yes, that worked.

> | "make alpha" fails for me on Solaris, since it puts too many m4 files
> | into m4/* and then later complains when they're not there in the
> | tarball. 
> 
> How bizarre...  Anyway, make alpha does not try to be portable (for a
> start it uses GNU make :).

I did use GNU make (compiled for Solaris).  I also have many GNU
utilities in my path, and don't have problems when generating other
distributions.

I suspect that there is some portability bug in there, which could
well bite us even on GNU/Linux some day.  When I have some time during
a "make alpha" I'll try to look into it.

> Having the beta is a good thing for the translations, but I don't
> think we should aim at a release so soon.  My plans for the next
> release includes addressing the lex-param, parse-param, and yyerror
> issues.  AFAICS, there is no need (= no bug fix) for a replacement of
> 1.75, right?

I think the biggest bug fixed in 1.75a is that 1.75 does not clean up
its temporary files when interrupted.  1.75a should also fix the GLR
test failures reported in
<http://mail.gnu.org/pipermail/bug-bison/2002-October/001764.html> and
<http://mail.gnu.org/pipermail/bug-bison/2002-October/001748.html>.

I haven't been following %lex-param etc yet (they aren't documented
yet).  I worry that these new features will cause some compatibility
glitches, though; if our goal is for Bison 2.0 to be quite stable then
it is a bit late in the day to be adding features, and perhaps we
should defer them (or at least defer their documentation :-) until
after 2.0 is out.  Anyway, nobody has followed up to your earlier
message on this subject so I'll turn to it next.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]