Re: a new way to build LilyPond binary releases

[Jonas Hahnfeld]

Am Donnerstag, den 12.03.2020, 14:18 +0100 schrieb Federico Bruni:
> Il giorno mer 11 mar 2020 alle 16:56, Jonas Hahnfeld <
> address@hidden
> > 
> ha scritto:
> > This is _not_ (yet) a proposal to switch over, but rather my ideas
> > about a possible replacement. So take this as a request for feedback
> > and testing as well as general discussion.
> 
> I've just made a test and was able to build the Linux package in about 
> half a hour. I think it took me years to be able to run GUB 
> successfully :-)
> 
> I have a suggestion: what about providing an install/uninstall script 
> with a configurable prefix option?

The usage of plain archives has the advantage that the user can install
and move the files anywhere, without invoking any installer. That is by
design, but maybe there's a valid use case for installers that I'm
missing? Uninstalling is just as easy as deleting the files (the
scripts from GUB don't do more than that anyhow).

> Did you test some real files?
> I've tried the full package and it works fine with minimal examples, 
> but not with real project files.
> For example, here's an error (with both full and "slim" binaries):
> 
> lilypond 2.21.0 [miniatura4.ly] in avvio...
> Processing `/home/fede/Documenti/spartiti/GammanossiM/miniatura4.ly'
> Parsing...
> Interpreting music...
> Interpreting music...[8][16][24]
> Preprocessing graphical objects...Backtrace:
>            9 (apply-smob/1 #<catch-closure 7f97beb9ee40>)
> In ice-9/eval.scm:
>    293:34 8 (_ #(#(#<directory (lily) 7f97beba1f00>) #<variable 7?>))
>     619:8 7 (_ #(#(#(#(#(#(#(#<directory (lily) ?>) ?) ?) ?) ?) ?) ?))
> In srfi/srfi-1.scm:
>     640:9 6 (for-each #<procedure 7f97bfa0ec60 at ice-9/eval.scm:3?> ?)
> In ice-9/eval.scm:
>     619:8 5 (_ #(#(#(#(#(#<directory (lily) 7f97beba?> ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
>     829:9 4 (catch _ _ #<procedure 7f97bfa18000 at ice-9/eval.scm:?> ?)
> In unknown file:
>            3 (ly:parse-file "/home/fede/Documenti/spartiti/Gammanoss?")
>            2 (ly:book-process #<Book> #< Output_def> #< Output_def> #)
> In ice-9/eval.scm:
>     259:9 1 (_ #(#(#(#<directory (lily) 7f97beba1f00>) #<Grob ?>) #))
> In unknown file:
>            0 (ly:grob-array-length #<finalized smob 7f97c093cf40>)
> 
> ERROR: In procedure ly:grob-array-length:
> In procedure ly:grob-array-length: Wrong type argument in position 1 
> (expecting Grob_array): #<finalized smob 7f97c093cf40>

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 😉

Jonas

signature.asc
Description: This is a digitally signed message part