The accompanying patch attempts to update the devel/bison port so that it uses the new bison 2.0 which was released in late 2004.
I just wonder, is bison-2.0 100% compatible with 1.75? Because we already got 1.875 and 1.875d in separate ports, which are not compatible with 1.75... -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org>
Moin, here's an excerpt of the NEWS file: --- cut here --- * Possibly-incompatible changes - Bison-generated parsers no longer default to using the alloca function (when available) to extend the parser stack, due to widespread problems in unchecked stack-overflow detection. You can "#define YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read the manual to determine safe values for YYMAXDEPTH in that case. - Error token location. During error recovery, the location of the syntax error is updated to cover the whole sequence covered by the error token: it includes the shifted symbols thrown away during the first part of the error recovery, and the lookahead rejected during the second part. - Semicolon changes: . Stray semicolons are no longer allowed at the start of a grammar. . Semicolons are now required after in-grammar declarations. - Unescaped newlines are no longer allowed in character constants or string literals. They were never portable, and GCC 3.4.0 has dropped support for them. Better diagnostics are now generated if forget a closing quote. - NUL bytes are no longer allowed in Bison string literals, unfortunately. --- cut here --- I don't know how many bison grammars that affects, and I don't see how you could tell unless you just go and try it out (and back out in case too many things break). - Frerich
Responsible Changed From-To: freebsd-ports-bugs->pav Poking..
Frerich Raabe pí¹e v st 10. 08. 2005 v 00:08 +0300: > I don't know how many bison grammars that affects, and I don't see how you > could tell unless you just go and try it out (and back out in case too many > things break). There is 165 ports using bison, so breakage can be huge. I'll try to build them and see if they break. -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> - Hocumms Razor states that the most obvious, though possible not conceviable, answer to a problem is most likely the correct one. - unless you are playing zelda.
State Changed From-To: open->feedback I compiled all the bison using ports, and found single breakage. That's quite good, I think. It's security/bro port which fails with: bison -y -d -t -v parse.y conflicts: 10 shift/reduce c++ -I. -Ilibedit -O -O -pipe -c parse.cc y.tab.c: In function `int yyparse()': y.tab.c:1894: error: invalid types `int[int]' for array subscript y.tab.c:3491: error: invalid types `int[int]' for array subscript *** Error code 1 Can you fix this? Alternatively, we can introduce a new port, devel/bison175, for this port and for other possibly failing ports, and update devel/bison to 2.0 using your patch.
State Changed From-To: feedback->repocopy Repocopy devel/bison to devel/bison175. I'd like to update devel/bison to 2.0, I tested all ports and found single point of failure, which will be set to use old version in devel/bison175.
Responsible Changed From-To: pav->portmgr Thank you
State Changed From-To: repocopy->open Repocopy completed.
Responsible Changed From-To: portmgr->pav Repocopy completed.
State Changed From-To: open->closed Committed, thanks!
State Changed From-To: closed->open Reoped; Ade Lovett requested removal of 2.0 from ports tree
Responsible Changed From-To: pav->ade Over to volunteer who offered to handle the update properly
State Changed From-To: open->closed Bison 2.1 now in the tree as devel/bison2 -- time for the fun conversion process from 1.x to 2.x