Am Samstag, dem 19.02.2022 um 18:14 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond development > <[email protected]> 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
