Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Samstag, dem 19.02.2022 um 21:08 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <hahnjo@hahnjo.de> writes:
> 
> > Am Samstag, dem 19.02.2022 um 18:14 +0100 schrieb David Kastrup:
> > > 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.
> 
> And the modification date is the date of unpacking on all platforms?

For Unix, it's the timestamp when the binaries were built. For Windows,
it depends. What I was trying to say here is that a user modifying a
source .scm file will not silently get wrongly compiled byte-code.

> 
> > > 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).
> 
> Why would the user have write permissions there?  What happens with
> other users also running LilyPond?

Our answers are racing here, I'd suggest we keep that discussion to the
sub-thread of your original reply. Just for completeness and future
reference: Setting GUILE_AUTO_COMPILE=1 is an explicit choice by users.
You don't get this by default, hence no problems.

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