Knut Petersen <[email protected]> writes: > "make doc" succeeds again, at least here. > > [newer versions]: make doc succeeds > dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8: fixes "make doc" failure here
Ugh, I forgot to make this a merge commit. The preceding commit does not compile on its own. Let's hope that this does not bite too many people when bisecting. > 4b4a2cae9953cff69159f10763e990f5e4265ddd: lilypond does not build > cccd7f9574c72ccecca00641d7a5ea3e8ce99cfd: still broken "make doc" > [...] > c1d7bc2217462a63bf5c5c6d6f6df5cb00099180: first broken "make doc" > [older versions] The "fixing" commit, like the "breaking" one is a reorganization that should not have caused a difference either way. The purpose of committing the "fix" mainly was to streamline the initialization code such that tracing and debugging of the initialization would become more straightforward. It's not clear to me what even causes somewhat reliably reproducible failure (with or without --disable-optimising, robust against smaller changes, across different computers and setups) when LilyPond is called from the Makefile but not when it is called with the same command line from the shell. I am currently doing a large sequence of tentative fixes to garbage collection/initialization, rebased on the earliest failing commit. So far, no change in result. But it's still stuff useful for avoiding use-before-initialization. Guilev2 might be affected worse, so making things airtight is not a waste of time. Still, I'd want to get a hold on the actual culprit. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
