Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Jean Abou Samra]

Le 13/05/2021 à 22:46, Jonas Hahnfeld via Discussions on LilyPond 
development a écrit :

> Before starting: These builds are not official, highly experimental, 
> and not meant for "production" installations. They use Guile 2.2 and 
> are slower, might not compile all scores or break some advanced 
> feature that you might use. The binaries might eat your files or do 
> other bad things to your computer - you've been warned! ... That said, 
> you are of course very welcome to read on: Hi all, I revived my 
> efforts from last year to work on a new way to build binaries and 
> possibly replacing GUB. For details on the ideas, see 
> https://lists.gnu.org/archive/html/lilypond-devel/2020-03/msg00337.html 
> and the explanations at https://github.com/hahnjo/lilypond-binaries 
> After some work, I built binaries from the released sources of 
> LilyPond 2.22.1 for * Linux (compiled on CentOS 7; tested on Arch, 
> CentOS 8, Ubuntu 18.04) * FreeBSD (compiled on FreeBSD 11.4; works on 
> FreeBSD 12.2 and 13.0) * macOS (compiled on macOS 10.15 (x86_64); 
> hopefully works on Big Sur)

64-bit, right? This sounds nifty.

I didn't comment on Guile 2 because I didn't have an opinion
and I am not competent about that, but I am pretty sure that
a unified release method that gives 64-bit binaries for Mac OS,
plus Windows, is an extremely strong incentive for moving to
Guile 2 permanently.


> * mingw / Windows (x86_64, meaning 64-bit; I hope it still works...) 
> and uploaded them next to the scripts used to create them: 
> https://github.com/hahnjo/lilypond-binaries/releases/tag/2021-05-13 
> For each platform, there is one "full" package that includes wrappers 
> and interpreters for the scripts; the non-"full" packages expect the 
> system to provide python3 for using the scripts. The packages are 
> plain tar / zip archives, just extract them wherever you want and use 
> the executables in the bin/ directory. Feel free to give them a try, 
> but please keep in mind the limitations: Guile 2.2 and no compiled 
> bytecode [1] means startup will take around 3 seconds.

Having `export GUILE_AUTO_COMPILE=1` in my ~/.bash_profile (for
development), I got many warnings, mostly about "possibly unbound
variables", during the first run.  That's nothing different from
current master.

There is, however, one error that appears on every compilation.
I don't have it with my local build.

;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0

;;; or pass the --no-auto-compile argument to disable.

;;; compiling 
/home/jean/lilypond-new-binaries/share/lilypond/2.22.1/scm/ly-syntax-constructors.scm

;;; WARNING: compilation of 
/home/jean/lilypond-new-binaries/share/lilypond/2.22.1/scm/ly-syntax-constructors.scm 
failed:

;;; unhandled constant #<fluid 7fcb2efd07f0>



I don't have a full history of 2.23 development in mind.
Was this fixed at some point?

I also experienced the same problem as Lukas-Fabian with
Unicode file names in Frescobaldi with English messages.

Other than that, both the full and non-full versions run fine
on my scores.


> Also I'd like to note that the scripts are a proof-of-concept, 
> especially the choice of shell scripts earned me some criticism.


Where can we read this criticism? I may have misread it, but
I don't see it in the thread you quoted at the beginning of
your message.

Out of curiosity only, did you consider CMake?

> If the ideas are worthwhile to follow, I'm open to considering Python 
> as long as we can avoid some problems that I see in GUB's design. 
> Cheers Jonas 1: I tried to include bytecode, but LilyPond 2.22.1 
> doesn't know how to load it. If you're curious, you can get it on your 
> system by compiling a dummy score with GUILE_AUTO_COMPILE=1 set on the 
> command line. If there's sufficient interest, I could make a build of 
> 2.23.x with it...
Thank you for working on this.

Cheers,
Jean