Re: [RFC] Moving to Guile 2.2 and away from GUB

[Jonas Hahnfeld]

Am Mittwoch, dem 24.11.2021 um 19:54 +0000 schrieb Carl Sorensen:
> I LOVE the idea of build scripts that don't need another special build
> tool.  I am somewhat concerned about their robustness relative to
> checking for appropriate versions of required prerequisites.  You will
> demonstrate that the scripts work by building all of the targets.
> I' not sure we will have any tests that show what happens when someone
> tries to build in an inappropriate environment.  And maybe this is not
> necessary, as we will be providing binaries.  Hopefully the build
> scripts will be accessible enough that somebody who wished could modify
> them for a different target (although that represents a *very* small
> market; certainly smaller than the Windows 64-bit market).

Yes, this is certainly a fair point because we use the platform
compilers. For the "official" builds, I've added Ansible scripts to
recreate VM environments as I'm using them. This includes CentOS and
Ubuntu, so we should be good for those two "worlds" of Linux
distributions plus I work on Arch Linux. I therefore hope it will only
be a minor problem in practice, but only time will tell.

> I  think we need to move off of the Guile 1.8 platform; distributions
> are no longer supporting it.  As far as I can see, Guile 2.2 is fast
> enough for the typical user use case.  IIRC, it has some start-up
> overhead, but runs almost as fast as 1.8 if you discount the overhead.

Correct, without bytecode the startup time is significantly worse and
overall operations are slightly slower. This improves with compiled
bytecode, as Jean replied, but this won't be included initially (I
forgot to mention this). We should definitely have it for the next
stable release, but I'm optimistic that this is possible.

> The current major problem with 2.2 as far as I understand it is that it
> is very slow in building docs, because the start-up overhead happens for
> every snippet.  I think the biggest risk for this is a bigger likelihood
> for developers to skip the make doc step, which used to be the gold standard
> for committing.

Maybe, but I think in practice the effect is not that large because
lilypond-book passes many, many snippets to one process. In addition,
CI will still enforce that 'make doc' went fine before any commit lands
in the master branch.

> I love the idea of static binaries, instead of dynamic linking.  
> 
> The risk of your proposal is pretty low in the short term is pretty low,
> because if the Guile 2.2/new script package blows up, we can always go
> back to GUB and try again later (not that I'm expecting it, but I'm
> looking worst-case right now).

Yes, that's also why I proposed that we first continue to release with
GUB and just build additional binaries that we can test. Even after the
switch, we can keep the existing code related to Guile 1.8 for a while,
until we are sure that we don't need it anymore. (Which hopefully is
not too long because the cleanups will be quite significant.)

Jonas

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