Re: source file ... .scm newer than compiled ... .go file

[Jean Abou Samra]

Le 16/10/2022 à 20:41, Federico Bruni a écrit :
> Il giorno dom 16 ott 2022 alle 12:18:25 +0200, Jean Abou Samra 
> <jean@abou-samra.fr> ha scritto:
> > Le 14/10/2022 à 19:55, Jonas Hahnfeld via Discussions on LilyPond 
> > development a écrit :
> > > > For the records, another application using Guile (GNU Cash) had the
> > > > same problem with flatpak three years ago.
> > > > Their workaround was disabling recompilation. Bad idea or good idea?
> > > > https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch 
> > > Not really great. On the other hand, you only need a very targeted
> > > installation and don't expect a fully functional Guile...
> >
> >
> >
> >
> > Try really hard to avoid this. Some LilyPond libraries are written in
> > .scm files, like a lot of the stuff in openLilyLib. It is important
> > to use compilation (by running with GUILE_AUTO_COMPILE=1) in order
> > to get helpful error messages when something goes wrong there. If this
> > patch is used, as soon as one run with GUILE_AUTO_COMPILE=1 has been
> > done, changes in the .scm files will have no effect, which is going
> > to be very confusing for the user ...
>
> I'm afraid I have no alternative. The LilyPond 2.23.x version in 
> flatpak doesn't currently work. I don't know when it started breaking, 
> as I usually tested the stable only.
> I opened a PR which makes 2.23.x work again:
> https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/14



If all else fails, can you make it depend on the path so that files
internal to Guile or LilyPond won't be recompiled but user files will?



> openLilyLib is used by a small number of users, I think, probably not 
> even using flatpak.


Most of it is indeed used by a handful of people, but the edition-engraver
does have some traction and from time to time you see people asking about
problems with it.

And then there are the people who write Scheme extensions for themselves
without telling anybody ...


> In case of problems they can still download and use the official 
> LilyPond binaries.


Sure, but debugging the problem is not going to be fun for them ...


> > > > Open issue which did not receive any feedback from flatpak developers:
> > > > https://github.com/flatpak/flatpak/issues/3064
> > > Yes, this would need proper addressing for use cases such as Guile
> > > bytecode compilation.
> >
> >
> >
> > CPython has a system roughly similar to Guile's; how does packaging
> > Python libraries work in Flatpak?
>
> I don't know. Do you know some Python libraries which may need a 
> similar feature?



OK, forget about this one sorry. I just checked and CPython doesn't
rely on the timestamps provided by the filesystem, but embeds them
in the .pyc bytecode file itself, which bypasses those redistribution
problems.