[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

From: Jean Abou Samra
Subject: Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1
Date: Sat, 15 May 2021 17:30:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

Le 15/05/2021 à 17:02, Jonas Hahnfeld a écrit :
Am Samstag, dem 15.05.2021 um 16:24 +0200 schrieb 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
and the explanations at

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
  * 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
64-bit, right? This sounds nifty.
Yes, all 64-bit. For macOS, it's x86_64 only and not arm64 (Apple M1).
I'm optimistic that it should work with the same approach, but I have
to use GitHub Actions because I don't have access to a suitable macOS
otherwise, and as far as I know they don't have that type of machines

Understood. At any rate, any type of Mac OS 64-bit compilation gets
us out of the Catalina morass.

As far as I understand, what is needed at this point is:

- improving Guile 2 support,

- setting up a release team with people running GNU/Linux and
  Mac OS, or some kind of remote builder for Mac OS, to do the
  regular releases.

Is this correct?

  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.
  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-
;;; 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?
Yes, that's


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.

The best I could find in public are Han-Wen's concerns in

"We started out with a set of shell scripts, but they were hard to
maintain, so we built GUB. So, to me, Jonas' proposal to have a set of
simple compilation scripts is a little funny."
(or at least I understand that comment as concern about maintainability
of shell scripts; which I generally agree, but at that time I wasn't
sure Python is any better when looking at GUB)

I did get other comments off-list saying that opting for less
expressivity (which was the goal) does not yield better code.


  > Out of curiosity only, did you consider CMake?

Not sure where CMake fits in there? The problem is not about building a
set of sources (the traditional task of build systems), but about
orchestrating (pun intended) a couple of those systems to build all
needed dependencies. Regular Makefiles were also suggested to me, but I
wrote one at my past work to build GCC with all its dependencies, and
it was horrible.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]