>
> 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 <d...@gnu.org>
> 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
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
