Re: bison-3.0 fix lilypond

[balducci]

> 
> Oopsie daisy.  The idea behind that might be that one can build a
> version of LilyPond without having flex/bison available at all.  That
> makes sense for bootstrapping things like, well, flex/bison/gcc and so
> on.

oops, sorry for being so naive: I did not even consider such a
perspective; I was thinking that the presence of those 2 files was
unintentional...


> 
> Well, the distribution and dependencies should be set up in a manner
> that either none or all of the bison-generated files are regenerated.
> 

Utterly right

> configure.ac clearly thinks that BISON should be optional (though the
> comments are downright scary):
> 
> # Do not use bison 1.50 and 1.75.
> # 1.29 is required fr %locations, but I'm not sure it's enough --ns
> STEPMAKE_BISON(OPTIONAL, 1.29)
> 
> I don't think this is a really good idea: as soon as you change the
> parser in any way, you'll need BISON anyway, and it's not like LilyPond
> is a component for bootstrapping Bison or GCC or whatever else, so there
> is no hen-and-egg problem we need to circumnavigate.
> 
> At any rate, the following commit should be related to the problem in
> that it makes it possible to occur in the first place (the real reason,
> however, should be something different):
> 
> commit ae9b8d637bae923bf8069f5e0f9bdb327bb98559
> Author: David Kastrup <address@hidden>
> Date:   Thu Dec 22 19:41:26 2011 +0100
> 
>     Make parser.cc and parser.hh independently to lessen parallel build probl
ems.
> 
> Now this is 2.15.24 already, but it is conceivable that some later
> update of the build system did not properly take that into account.  It
> _looks_ to me like the dependencies should be clean.


My 5 cents: I also think that trying hard to be bison independent does
not make very much sense; it is like trying to be gcc (or C[++]
compiler) independent, in a way; but then, just distribute a binary. As
far as I can say, bison (or flex or any other source-related tool) is
supposed to be available to anyone interested in building software from
source. Not to mention that every linux distribution or *nix vendor will
provide bison or equivalent.


> Can you check which (if any) of parser.cc and parser.hh get rebuilt for
> you?  It's likely that one of the two is kept in the version from the
> tarball while the other is recreated with a different Bison, and this
> mismatch is what is causing the problems.

Looks like you got it: parser.cc is regenerated (and, of course,
different from the original copy), while parser.hh is not:

        Sep  1 12:16 ./lilypond-2.17.25/lily/out/parser.cc
        Aug 25 16:42 ./lilypond-2.17.25/lily/out/parser.cc.ORIG
        Aug 25 16:42 ./lilypond-2.17.25/lily/out/parser.hh
        Aug 25 16:42 ./lilypond-2.17.25/lily/out/parser.hh.ORIG


thanks a lot
ciao
gabriele