Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > David Kastrup < > > d...@gnu.org > > > writes: > > > > > David Kastrup < > > > d...@gnu.org > > > > writes: > > > > > > > Valentin Villenave < > > > > valen...@villenave.net > > > > > writes: > > > > > > > > > On 4/19/20, David Kastrup < > > > > > d...@gnu.org > > > > > > wrote: > > > > > > Note that the delete-file instructions are executed while the book > > > > > > is > > > > > > being read in while markup is typeset when the books are being > > > > > > processed > > > > > > at the end of the input file. > > > > > > > > > > Yes, it looked completely bonkers to me as well, until I realized it > > > > > worked :-) > > > > > > > > > > > No idea whether the fonts made it into > > > > > > LilyPond at that point of time, or how happy LilyPond is with them > > > > > > appearing. > > > > > > > > > > No, because at this point the first \book has already been processed, > > > > > and even GS should already be invoked. That’s the whole point of > > > > > putting that stuff inside another \book. > > > > > > > > There is no point in putting the deletion of files "inside another > > > > \book" since it is not being executed when the book is typeset but when > > > > the book is read in. > > > > > > > > > > There may well be race conditions here. > > > > > > > > > > Well, AFAIK there’s no parallelism inside a same .ly file being > > > > > processed for different \book outputs. (If there _was_, that would be > > > > > great news though!) > > > > > > > > Again: file creation and deletion happens while the book is being read > > > > in, typesetting happens when the book is being processed. File handles > > > > will tend to stick around until garbage collected. That is not as much > > > > "parallelism" as an absence of order. > > > > > > So I am afraid that things are rather weird at my side: > > > > > > input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an > > > error for the expression beginning here > > > # > > > (rmdir dummyfontdir) > > > Directory not empty > > > Finding the ideal number of pages... > > > Fitting music on 1 page... > > > Drawing systems... > > > Layout output to `/tmp/lilypond-pXKtKN'... > > > Converting to `font-name-add-files-1.pdf'... > > > Deleting `/tmp/lilypond-pXKtKN'... > > > fatal error: failed files: "input/regression/font-name-add-files.ly" > > > dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/ > > > total 0 > > > dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/ > > > total 12 > > > drwxrwxr-x 2 dak dak 4096 Apr 19 19:51 . > > > drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 .. > > > -rw-r--r-- 1 dak dak 36 Apr 19 19:51 .uuid > > > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid > > > 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ > > > > > > Does anybody have an idea _what_ and _why_ would leave a .uuid file > > > lying around in the temporary file with, well, an uuid kind of number in > > > it? Is that an artifact of my freetype library or something? > > > > Seems to be something that fontconfig does. > > Just in case: > > dak@lola:/usr/local/tmp/lilypond2$ fc-list -V > fontconfig version 2.13.1
In case it helps, they're removing the uuid functionality again: https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c So I guess the fix is to delete the (temporary) directory and all contained files? And maybe putting it under /tmp? Oh, and ignore my comment that I had tested this with Guile 2.2. Looks like I didn't (at least not properly).
signature.asc
Description: This is a digitally signed message part