Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High: > On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote: > > if GUB is used, who is maintaining and/or working on it? > > Almost exactly a year ago, there was a sizable "Please test gub" effort > initiated by Knut Petersen. > > < > https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html > > > > Clear instructions were given for exactly how to test GUB, and just that > thread seems to have involved about 16 people. > > More recently, it looks like Jonas Hahnfeld's work with Python 3 > migration involved quite a number of changes to GUB.
Yep, and it's not been a very pleasant experience. To be precise here: It's not about porting GUB to Python 3, it's just that porting LilyPond will introduce a dependency on an updated package for the next release. So while David is mostly correct that contributors don't need to bother with GUB, that doesn't hold true once you want to bump one of its dependencies... Based on this experience, I've thought about how to improve the process of building binary releases for LilyPond. What I have been experimenting with is a set of portable shell scripts that build mostly static executables. I've a prototype ready at https://github.com/hahnjo/lilypond-binaries which works for Linux and FreeBSD. I don't see a reason it cannot work on macOS, but I don't have the possibility to test... > From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with > something based on Guix. > > < > https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html > > > > That idea was mentioned a few times since, but I can't recall if > GUB-replacement discussions have moved beyond that or not. As far as I understand, Guix is a package manager in the first place. In the thread Jan proposes to use it for cross-compilation, which I think is the primary reason for the complexity in GUB. So why go that route once more? Instead I designed the mentioned scripts such that they produce native executables. That's also how TeXlive builds their packages, for example, and it works quite well if you compile on the oldest OS that you intend to support (CentOS 7, FreeBSD 11). I haven't decided yet how to compile for Windows. Maybe that's still a valid use case for cross-compilation (but only with a very limited scope). I'm not going to tackle this until we've switched to Python: Then we can just use the embeddable zip file provided by the Python project without bothering with cross-compilation for this beast. Everything else (Guile etc.) worked without problems in my early tests. If this attempt sounds interesting to the community, I would be happy to submit the scripts for inclusion into the LilyPond repository itself. That would also solve another issue with GUB: Currently it's a separate repository with no way to keep it in sync with changing dependencies for LilyPond... Regards, Jonas P.S.: to come back to the whole container idea: after you have the binaries, you can of course build a docker container from them...
signature.asc
Description: This is a digitally signed message part