Am Samstag, dem 19.02.2022 um 21:08 +0100 schrieb David Kastrup: > Jonas Hahnfeld <[email protected]> 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
