On 2020/02/26 07:59:36, hanwenn wrote: > On Tue, Feb 25, 2020 at 11:09 PM <mailto:[email protected]> wrote: > > Another solution might be serialize only lilypond-book and let tex et > > al. run concurrently. That should also be harmless, right? > > But this is exactly what this patch does.
I meant "serialize only lilypond-book in the Makefile [...]", sorry for not being specific. I agree that this patch attempts to go this way in lilypond-book, and that's what I object to, see below. > I don't understand your objection. Serializing mechanism in the > makefile are obscure and hard to understand, because build systems > want to do as many things in parallel as possible. ... so it's the build system's responsibility to get things right. In our case this means: Do *not* call lilypond-book in parallel. > A lock (a file lock, in this case) is the standard solution for > serializing concurrent access to a shared resource (a standard > problem). What is your objection against using a standard solution? Yes, locks are a standard solution, but file locks are brittle. I've seen them fail far too often (ever had your apt-get / yum / pacman error out because there was a lock-file?) so I object to adding this complexity if it only helps for a single case in our build (ie input/regression/lilypond-book/). > On a philosophical level, it is a lilypond-book implementation detail > that it can't deal with concurrent invocation, so the remediation for > this problem should be in lilypond-book too. Let me disagree: It's an implementation detail of make that it runs things in parallel. IMHO a build system should ensure that the result of running with multiple jobs is the same as a sequential run. https://codereview.appspot.com/555360043/
