[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison-3.0 fix lilypond

From: balducci
Subject: Re: bison-3.0 fix lilypond
Date: Sat, 31 Aug 2013 16:36:07 +0200

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

I have sampled several 2.16.x and 2.17.x tarballs and I always find
parser.cc and parser.hh present; e.g.:



=> if I build from the as-downloaded tarball with bison-3, I get the

=> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]