Re: Some wild considerations and a question

[Jonas Hahnfeld]

Let me address the points about GUB:

Am Dienstag, den 20.10.2020, 11:03 +0200 schrieb Jean Abou Samra:
> > > - rely only on C++, flex, bison and the extension language.
> > >    Eliminating the need for GUB and Python would greatly simplify
> > >    porting LilyPond to various environments, including web sites,
> > >    phones and tablets.

I don't see how eliminating GUB simplifies porting to "various
environments". As others have said, it's only used to produce the
official binaries distributed for user convenience. This process is
complex and needs some form of automation, which is the reason why GUB
was created. Now even if moving to something else, it will still only
support a limited set of targets.

> > GUB will be history soon, thanks to the work mainly of Jonas.

Your mileage may vary, but I don't see this happening "soon", as in the
next few months. Right now it's more of a proof-of-concept that native
binaries for a number of architectures could be produced with a set of
generic scripts.

> Is this true, Jonas? I've heard of scripts you wanted to replace
> GUB with, but the last time I read about them, Han-Wen was skeptical
> of this idea because GUB had precisely been created to replace the
> scripts that were used before and were a nightmare to maintain.

I don't want to digress into this topic right now (P.S. the reply got
longer than I initially anticipated), but the scripts have a much
narrower focus: they mostly compile native binaries (except for Windows
via mingw) instead of cross-compiling for all targets. In my experience
from helping with GUB in the past year, that's the main source of
complexity for usage and maintenance. Moreover, this choice also
outright prevents 64-bit executables for macOS because of Apple's
restrictions with regard to their toolchain.

I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
just too much (a package manager for building arbitrary packages for
various targets; where we only do LilyPond to a handful) by using a too
powerful language and architecture (Python 2 with dynamic dependency
resolution and generic interfaces to various build systems). I think we
should learn from that and choose a design that avoids the pitfalls.

But again, that's nothing I'm expecting to happen "soon". Also because
an eventual transition to Guile 2 plays an important role here: I don't
want to plug that into GUB, but Guile 1.x is fundamentally incompatible
with 64-bit binaries for Windows.

Closing words: In general, a replacement for GUB is not something to be
discussed in length on -user. This must happen in a proper thread on
the -devel list, and hopefully with more technical content than just
the statement of "we need something better".

Jonas

signature.asc
Description: This is a digitally signed message part