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 -- David Kastrup