On 2020/02/22 22:27:05, Dan Eble wrote: > How does this interact with CPU_COUNT, which is documented in the Contributor's > Guide thus (emphasis mine)? > > The most time consuming task for building the documentation is > running LilyPond to build images of music, and *** there cannot be > several simultaneously running lilypond-book instances, *** so the > -j make option does not significantly speed up the build > process. To help speed it up, the makefile variable CPU_COUNT may > be set in local.make or on the command line to the number of .ly > files that LilyPond should process simultaneously, e.g. on a > bi-processor or dual core machine: > > make -j3 CPU_COUNT=3 doc > > This is how I always build. Is it going to have the same effect now, or will it > do something new, e.g. attempt 9 concurrent jobs?
if you were doing make -j3 CPU_COUNT=3 you were already potentially in a state where you have 3 jobs each spawning 3 lp-book invocations, as all almost everything is already doing $(MAKE) instead of 'make'. As you can see, this only affects the regtests for lilypond-book, and not even that, since parallelism is explicitly switched off for this directory (facepalm) by the statement I marked. There is a better reason to avoid multiple lp-book processes, though: I am pretty sure lilypond doesn't write files atomically, so multiple lp-book invocations might try to write the same files at the same time. We should probably add locking on the .ly snippet DB so this doesn't happen. https://codereview.appspot.com/569400043/
