Am Dienstag, den 21.01.2020, 11:28 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > [email protected] > > writes: > > > 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... > > The problem is "on macOS" since current macOSX library/toolbox licenses > all prohibit use in cross-building environments. It looks like a given > that we will not be able to offer macOSX libraries in future as the > result of a unified release process. Our sources build reasonably well > that macOSX integrators using some of the macOSX typical packaging > systems are able to provide reasonable replacements. > > But the elephant in the room is Windows. Han-Wen says he never wants to > touch GUB again (and he actually didn't as far as I remember) but I > don't want to touch Windows again, and GUB provides them. The > dependency nightmare on a non-UNIX like platform was what brought GUB > into being in the first place: native builds are much more of an ongoing > problem. Just look at the continuous effort the Git project has in > keeping a Windows version available. > > > > 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). > > Windows really is the elephant in the room. MacOSX will cater with > native port systems like MacPorts etc and other UNIX-like systems also > have working packagers and package systems.
So if I provided a working script to build a zip file for Windows, would you be ok with switching away from GUB? In that case I just noticed that I missed one character in my message: > I'm not going to tackle this until we've switched to Python *3*: > 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. Jonas
signature.asc
Description: This is a digitally signed message part
