Re: broken doc build (orchestra.ly)

[David Kastrup]

Knut Petersen <address@hidden> 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