David Kastrup <d...@gnu.org> writes: > Graham Percival <gra...@percival-music.ca> writes: > >> On Thu, Dec 22, 2011 at 05:28:44PM +0100, David Kastrup wrote: >>> Graham Percival <gra...@percival-music.ca> writes: >>> >>> > Skimming through lily/GNUmakefile, this makes sense. There's a >>> > couple of explicit dependencies for parser.hh, but these don't >>> > mention lily-lexer-scheme.cc, which is the file that triggers the >>> > fail. >>> >>> But the out/lily-lexer-scheme.dep file mentions it in the last line: >>> ../flower/include/arithmetic-operator.hh include/pitch.hh out/parser.hh >>> >>> Does that mean that we generate the dependencies without actually using >>> them? That sounds rather stupid, but then I don't understand the build >>> system anyhow. >> >> ... yes? no? >> Bottom line: somebody added explicit dependencies to >> lily/GNUmakefile, for some reason. It could have been somebody >> not really understanding the build system, but at least it worked. >> >> I wouldn't be surprised if Julien sent in a patch in a few >> hours/days that removed the explicit dependencies for the parser >> in favor of a more general solution. :) > > He'll have to be pretty fast. I'm on it. But I am afraid you have to > expect another hour or so before I get this fixed.
Phooey, this does not make all that much sense. The dependencies are actually being generated while the files are getting compiled. So they are not good for determining a compilation order, just for avoiding recompilations when the dependencies are already there. So it will probably end up being a patch along the lines you suggested first. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
