bison 3.0 released [LWN.net]

bison 3.0 released

Posted Aug 3, 2013 10:37 UTC (Sat) by HelloWorld (guest, #56129)
In reply to: bison 3.0 released by dakas
Parent article: bison 3.0 released

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

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

to post comments

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.