Re: a new way to build LilyPond binary releases

[Thomas Morley]

Am Do., 12. März 2020 um 16:22 Uhr schrieb Mats Bengtsson
<address@hidden>:
>
>
> On 2020-03-12 16:17, Mats Bengtsson wrote:
> >
> > On 2020-03-12 14:39, Jonas Hahnfeld wrote:
> >> I did test some more advanced files than "{ c' }", but apparently not
> >> complicated enough. I think this one actually has the same root case as
> >> Karlin reported: I traced this back to the garbage collector freeing
> >> objects prematurely. Apparently it's not really happy that I made it
> >> unaware of threading...
> >> I've just finished building anew, please give
> >> https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
> >> try. Or rebuild with the updated scripts
> >
> > I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on
> > a reasonably large project (some 80+ page output string quartet score)
> > and it runs without any error messages and produces correct output,
> > with the exception of Unicode characters in titling that are
> > completely garbled, but that's perhaps a known issue.
> >
> > When untarring the package, I happened to notice that the tar ball
> > contains a number of soft links to
> > /home/jonas/lilypond-binaries/dependencies/install/fontconfig-2.13.1/...
>
>
> I just spotted another oddity towards the end of the log printouts that
> probably also is related to the Guile updates:
>
> "Finding the ideal number of pages...Omitting the destination on a call
> to format is deprecated.
> Pass #f as the destination, before the format string.


Likely.

(format ...) nowadays always needs a destination-port.
>From the guile-manual
"
Scheme Procedure: format dest fmt arg …
Write output specified by the fmt string to dest. dest can be an
output port, #t for current-output-port (see Default Ports), or #f to
return the output as a string.
"

I just noticed such a missing #f in lilypond-book.itely:
https://sourceforge.net/p/testlilyissues/issues/5843/

Cheers,
  Harm