Re: bison-3.0 fix lilypond

[David Kastrup]

address@hidden writes:

> hi there,
>
>     > I've just installed a version of bison-3.0 in a temporary directory and
>     > used that for compilation.  No problem whatsoever.  Huh.
>     > 
>     > And parser.cc does start with
>     > 
>     > /* A Bison parser, made by GNU Bison 3.0.  */
>     > 
>     > /* Bison implementation for Yacc-like parsers in C
>     > 
>     >    Copyright (C) 1984, 1989-1990, 2000-2013 Free Software Foundation, 
> Inc.
>     > 
>     > [...]
>     > 
>     > So this can't be _all_ that's involved.  Maybe your Bison binary is
>     > broken?
>
> but: parser.cc and parser.hh are ALREADY there in the distributed
> tarball!

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.

> I have sampled several 2.16.x and 2.17.x tarballs and I always find
> parser.cc and parser.hh present; e.g.:
>
>     lilypond-2.17.25/lily/out/parser.cc
>     lilypond-2.17.25/lily/out/parser.hh
>
> Now:
>
> => if I build from the as-downloaded tarball with bison-3, I get the
>    error
>
> => if I build from the as-downloaded tarball with bison-2, no errors
>
> => IF I CLEAN THE lily/out DIRECTORY IN ADVANCE and then build with
>    bison-3, ==> NO ERRORS
>
> So, this makes me think that parser.cc and parser.hh should not be
> there.

That's my feeling as well.

> My interpretation is that if parser.cc and parser.hh are present, they
> won't be (re-)generated during the build and, when using bison-3, they
> will interact badly with the rest of the built files (because they
> were generated with bison-2)

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

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 
problems.

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.

> Actually, I see that this lily/out directory gets heavily populated at
> build time, which, again, makes me think that it should be empty at
> the beginning of the build process

Not if Bison should be "optional" to install.  I am quite unconvinced
that this is a good idea.

> Did you try bison-3 with the officially distributed tarball or with a
> local build tree?

Local build tree after "make clean" which would definitely clean out the
suspects.

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.

-- 
David Kastrup