Re: 2.21.0 release plans and considerations

[Han-Wen Nienhuys]

On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld <address@hidden> wrote:

> Am Mittwoch, den 04.03.2020, 09:34 +0100 schrieb Han-Wen Nienhuys:
> > On Sun, Mar 1, 2020 at 3:12 PM Jonas Hahnfeld <
> > address@hidden
> > > wrote:
> > > For example, I'd very much like #5799 to be part of 2.21.0 to be able
> > > to cross-compile to x86_64-w64-mingw32 and show-case a replacement for
> > > GUB. However I acknowledge that the changes have at least the potential
> > > to break the current process using GUB.
> >
> > I'm intrigued by the idea of replacing GUB. Can you say something more
> > about what you're planning?
>
> I've been working on this: https://github.com/hahnjo/lilypond-binaries/
> Before you ask: No, there's not a single line of documentation yet. In
> case you still want to give it a try, the order is
>  * scripts/get_tools_*.sh (or just install the needed tools via your
> system's packet manager; the following scripts don't really care where
> the tools come from)
>



>  * scripts/build_native_deps.sh
>  * scripts/build_lilypond.sh (expects LILYPOND_TAR to be set to a
> result from make dist)
>  * scripts/package_tar.sh
> There are some more scripts for cross-compilation to mingw (64 bit),
> this requires scripts/mingw_install_toolchain.sh to get the tools for
> cross-compilation.
>
> 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.

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
* 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).
* 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.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen