bison 3.0 released [LWN.net]

bison 3.0 released

Posted Aug 2, 2013 20:42 UTC (Fri) by nix (subscriber, #2304)
Parent article: bison 3.0 released

Some of the stuff in here (e.g. complex api.value.type support) looks really, really good, and I'm already annoyed that I'll have to wait years before this version of Bison becomes common enough that I can rely on it in my grammars. :}

bison 3.0 released

Posted Aug 3, 2013 3:10 UTC (Sat) by rsidd (subscriber, #2582) [Link] (16 responses)

Can't you require this version? People who need this stuff should know how to install it, surely?

bison 3.0 released

Posted Aug 3, 2013 6:16 UTC (Sat) by dakas (guest, #88146) [Link] (15 responses)

Distributors are hardly likely to include software that does not compile using their build system.

bison 3.0 released

Posted Aug 3, 2013 10:37 UTC (Sat) by HelloWorld (guest, #56129) [Link] (11 responses)

Which shows once again how broken the "Linux distribution" model is.

Anyway, you could just ship the code generated by bison, right?

bison 3.0 released

Posted Aug 3, 2013 11:27 UTC (Sat) by dakas (guest, #88146) [Link] (10 responses)

Depends on the license of the software. The GPL, for example, states:

1. Source Code.
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work.
[...]
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

So you need to distribute the corresponding parser source code in Bison form at any rate. Just distributing the generated C source is not sufficient.

bison 3.0 released

Posted Aug 3, 2013 11:38 UTC (Sat) by rsidd (subscriber, #2582) [Link] (9 responses)

I don't get it. Just distribute both the parser source and the generated C! Those who want to modify something can install bison 3.0 for themselves, the rest needn't bother.

bison 3.0 released

Posted Aug 3, 2013 13:37 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (1 responses)

That's what every program using Bison does, indeed.

bison 3.0 released

Posted Aug 3, 2013 17:50 UTC (Sat) by JoeBuck (subscriber, #2330) [Link]

Yes, back when GCC used bison, this was the approach taken. The derived files were in the release tarball but not in version control.

bison 3.0 released

Posted Aug 3, 2013 15:58 UTC (Sat) by andresfreund (subscriber, #69562) [Link] (6 responses)

Well, it does raise the barrier for casual contributors. For one in many cases and by actually sensible reasoning the generated files will not be included in the VCS. For another, instead of needing only one software's prerequisite you increase that by every tool you require in very recent versions.
If you ever had the experience of wanting to quickly write a simple bugfix only to spend some hours to get the build environment running, you know what I am speaking of.

bison 3.0 released

Posted Aug 3, 2013 16:26 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

Well, yes, but this is bison we are speaking of. I may be wrong but my feeling was that anyone who is capable of writing a bugfix for bison parser source will either have already installed bison 3.0, or can do so in minutes. (How many casual contributors understand context-free grammar, Backus-Naur form, etc? Of those, how many can use bison but would find it hard to install bison 3.0?)

bison 3.0 released

Posted Aug 5, 2013 5:18 UTC (Mon) by quanstro (guest, #77996) [Link]

it's possible to be skilled and a casual contributor. "drive by" fixes make sense for folks to trip over something that bugs them in their daily use. some percentage of these folks are going to be serious programmers who just aren't going to become core developers.

using the very latest features for acmeprog x.y.z, thus requiring that version to be installed might just be a bridge too far. especially if other things, like a day job, require version p.d.q.

bison 3.0 released

Posted Aug 3, 2013 16:47 UTC (Sat) by jiiksteri (subscriber, #75247) [Link]

> For one in many cases and by actually sensible reasoning the generated files will not be included in the VCS.

How so? Isn't this the same thing that's done with autotools all the time, and nobody's compl... wait everybody's complaining. Nm then :)

bison 3.0 released

Posted Aug 3, 2013 17:45 UTC (Sat) by dakas (guest, #88146) [Link] (1 responses)

Well, nobody said being a developer is always easy. In LilyPond, we tend to have one new GCC C++ code generation bug turning up per year. And we are talking about the version of GCC shipping with Ubuntu here (or in one case, Fedora). I think our last Fedora code generation bug was bad enough that it was among the reasons for postponing Fedora's release.

So you can of course ask "why would it be the job of a music typesetting programming team to track down code generation problems in a compiler?". But then somebody needs to do it...

Moving to newer Bison would not be really feasible right now. But at one point of time, we certainly will do so. The LilyPond grammar does a lot of weird things, like generating artificial tokens and hoping that the grammar state has not permanently registered the previously seen token already. GLR parsers might or might not make this easier.

bison 3.0 released

Posted Aug 5, 2013 15:13 UTC (Mon) by Wol (subscriber, #4433) [Link]

As a drive-by lilypond developer :-) that's why I switched to gentoo.

I couldn't build lily using the then-latest version of SuSE.

Cheers,
Wol

bison 3.0 released

Posted Aug 3, 2013 21:07 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> Well, it does raise the barrier for casual contributors.
I think it's more important to make life easy for core developers. Also installing a recent version of bison is not a big deal IMHO.

bison 3.0 released

Posted Aug 3, 2013 20:00 UTC (Sat) by jrn (subscriber, #64214) [Link] (2 responses)

If you have time for it, that has an easy fix: help the distros to package bison 3.0.

bison 3.0 released

Posted Aug 5, 2013 4:43 UTC (Mon) by tetromino (guest, #33846) [Link] (1 responses)

Distros will package bison-3.0 as soon as bison-3.0 can be used to build any bison- or yacc-using package in their repos from source - and at the moment, there are too many failures.

bison 3.0 released

Posted Aug 6, 2013 13:59 UTC (Tue) by madscientist (subscriber, #16861) [Link]

One supposes that jrn's comment extends to helping to fix up packages that don't work with Bison 3.0.

bison 3.0 released

Posted Aug 5, 2013 22:38 UTC (Mon) by jzbiciak (guest, #5246) [Link]

I personally will switch for the next project I write that wants a Bison-based parser, as I move new projects to C++. I will also do what I've been doing for years with my other projects: Ship the generated code with the source. I have a dedicated "make regen" target to regenerate all generated files.

The strategy has worked pretty well so far, allowing others to port my Intellivision emulator and tool chain to everything under the sun, without having to worry about flex/bison versions. That includes (at various times) Linux, MacOS X, Windows, FreeBSD, Solaris, Nintendo Wii, PSP, Nokia N900, and Android.

What really pushed me over the edge was when I started running into weird issues between (I think) 1.8x and 2.x versions. Once I forked off the dedicated regen targets, life got much simpler building across the 4 or 5 machines I built releases on as their flex/bison versions drifted apart from each other, as long as my primary dev machine had the latest and greatest. And I no longer got the random support email from the random porter.