Re: 2.21.0 release plans and considerations

[Jonas Hahnfeld]

Am Donnerstag, den 05.03.2020, 11:45 +0100 schrieb Han-Wen Nienhuys:
> On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld <address@hidden> 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