Re: [RFC] Transition to Guile 3.0

[Jonas Hahnfeld]

On Sat, 2023-11-11 at 18:37 +0100, Han-Wen Nienhuys wrote:
> On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld wrote:
> > Hi all,
> > 
> > I hear LilyPond hasn't changed its Guile version since some time (more
> > than 18 months). So before we get too comfortable with the current
> > situation, let me propose to move to Guile 3.0. Below is a plan for
> > that switch, with a transition period to test the official binaries.
> > Last time, when going from Guile 1.8 to version 2.2, the switch had to
> > coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could
> > in principle support both versions for a longer period. However, I
> > personally think that a full transition and dropping support for Guile
> > 2.2 is the more reasonable approach: It will reduce testing
> > configurations (both for development and user reports) and hopefully
> > enable some future cleanups in the code.
> 
> Could you say a bit more about the benefits/disadvantages for the user?
> I had the impression that Guile 3 had different (worse?) performance
> characteristics relative to 2.2, but it's been a while.

As far as I can tell from my limited tests so far, LilyPond built
against Guile 2.2 or 3.0 has similar speeds. At least if you have
compiled bytecode (that generates faster with Guile 3.0, but that's not
really an advantage for users). The build with Guile 3.0 seems to have
a slightly lower startup time, which is good for small scores, but we
will be able to test in full tomorrow when I build the other binaries.

> IIRC, one of the arguments to drop 1.8 is that Guile pre-2.x did not
> support installing multiple versions alongside each other, which forced
> distributions to choose whether to ship LilyPond or a recent version of
> Guile. With 2.2 and later, that dilemma disappeared.

Not quite: While it's true that Guile 1.8 was not prepared to be co-
installed with later versions, it worked in practice because Guile 2.0
had the necessary modifications. What happened instead is that Linux
distributions wanted to get rid of Guile 1.8, and some did before
LilyPond was able to fully work with Guile 2.2. The same is currently
happening again, for example we had to do quite some convincing to keep
Guile 2.2 in Debian 12 Bookworm released this summer. So IMHO we really
want to support Guile 3.0; Jean already did the hard work here last
year, up to the point that some already build LilyPond 2.24.x with
Guile 3.0 right now.

> I quickly grepped over the source (grepping for SCM_MAJOR_VERSION),
> but the bifurcations look very modest.

In principle yes, we could continue to support Guile 2.2 and it
wouldn't cause too many issues at first. However, we know from
experience that supporting two versions of Guile has a certain cost,
and I think we are better off just supporting Guile 3.0 going forward.

Jonas

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