Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Samstag, dem 19.02.2022 um 18:14 +0100 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> <lilypond-devel@gnu.org> writes:
> 
> > Hi all,
> > 
> > I'd like to discuss what are considered blocker issues for a switch to
> > Guile 2.2.
> > 
> > After the release of 2.23.6, there were reports of major problems on
> > Windows, namely that the binaries were broken when extracted with the
> > Windows Explorer (#6281) and that file names with special characters
> > didn't work (#6282). I think I found solutions for both of them, either
> > already merged (!1194 for #6281) or in review (!1219 for #6282).
> > 
> > The second large topic was performance of the binaries with Guile 2.2,
> > which we know will be worse without compiled bytecode. In
> > https://lists.gnu.org/archive/html/lilypond-devel/2022-02/msg00099.html
> > Jean writes
> > > [Guile bytecode for LilyPond's .scm files] should be added eventually
> > before we make a full switch.
> > 
> > I don't fully agree and think that bytecode compilation shouldn't block
> > the switch. In my opinion, it would be fine for the next development
> > releases to be somewhat slower if that results in Guile 2.2 being
> > available sooner.
> 
> That is not as much a speed issue as an stability issue.  The byte
> compilation caches are not robust across updates and downgrades since
> they are based on file names.

... where the path includes the version of LilyPond. Additionally,
Guile also checks the modification date.

> If our own scm files are not installing
> with their individual set of .go files, the installations bleed over
> into the user domain and remnants may cause problems.

I'm not sure I understand your concern here. For LilyPond, compiled
files never end up in the user's $HOME directory but always within
versioned directories within share/ (with GUILE_AUTO_COMPILE=1). Also
the user must be explicit about getting them, in which case they are on
their own.

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