Re: bison-3.0 fix lilypond

[balducci]

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!

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.

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)

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

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

thanks for your work

ciao
gabriele