On 2020/02/26 08:19:39, hahnjo wrote: > 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.
That said: I'm also fine if some other developer accepts this patch. See my timing data above to get to your own conclusion. After all, my opinion is just one of a larger range. https://codereview.appspot.com/555360043/
