Am Donnerstag, den 05.03.2020, 11:45 +0100 schrieb Han-Wen Nienhuys: > On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > The basic idea is to produce native binaries with all dependencies > > compiled as static libraries, with dependencies only on the most basic > > I applaud that, but I recall that this was difficult last time we tried, > because some libraries require dynamic loading of things, both GUILE and > Pango IIRC.
GUILE 1.8 dynamically loads the srfi modules, but I even managed to make this work while still linking the static libguile.a. However I switched to GUILE 2.2 recently because GUILE 1.x just doesn't work on 64 bit mingw (It throws "division by zero" errors, and I think it's related to garbage collection. There are a few posts from people who attempted to fix this, but nothing worked and I decided to stop wasting time on fixing software from 2010.) > > There's already some work to adapt the scripts to macOS, and I don't > > see any reason that the very portable shell scripts should not work on > > other Unix systems or architectures. > > After 2.21.0 is done, I'll post a more detailed description and also > > upload some sample binaries. But you asked for what I'm planning 😉 > > sounds good. Some comments: > > * I think on Linux we should do the build inside a docker container to ensure > reproducibility Possibly, but I'd say it's out-of-scope for the first attempt. Moreover I think it won't help for FreeBSD (can you run a FreeBSD container from Linux?) and certainly not for macOS. > * I'd base it off Git commits rather than tarballs. The tarballs are > anachronistic, and with git commits, it will be easier to build binaries for > pending changes (to make sure they don't break the process). Nope, I'm not a huge fan of doing this and actually I'd argue that tarballs are easier: Just run 'make dist' for your local changes. With GUB (which is entirely based on git commits for the LilyPond spec?), I always need to push the changes to a public repository. This has cost me quite some time in the past days and it just doesn't feel right when I want to quickly iterate with local changes. > * If we don't have to rebuild the toolchain all the time, we can likely also > do this as a routine step for staging => master, and start producing nightly > builds. That actually would be one of the nice benefits we could get. You can keep the toolchain for mingw and the "native" dependencies around and just re-compile LilyPond and package it - taking around ~10 minutes or so depending on the system. But let's stop discussion for now until we actually have a thread proposing to change release tooling. Until now it's just a set of ideas that I find promising, but not more. Jonas
signature.asc
Description: This is a digitally signed message part
