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
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
