Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Montag, dem 21.02.2022 um 22:44 +0100 schrieb Jean Abou Samra:
> Hi,
> 
> Sorry for the late reply, I hoped to have a merge request
> ready to implement but life is getting in the way.
> Nevertheless, a proof of concept is this:
> 
> 
>  From 95794324cd4a637c4735447b672a1de91416cc4a Mon Sep 17 00:00:00 2001
> From: Jean Abou Samra <jean@abou-samra.fr>
> Date: Sun, 20 Feb 2022 17:00:20 +0100
> Subject: [PATCH] WIP: allow separate Guile byte-compilation
> 
> Benefits: can be integrated into the build system, can byte-compile
> all files even if not used, can byte-cross-compile.

No, it can't. This approach fundamentally assumes that you can run the
lilypond binary, which is not true in cross-compilation setups. If it's
about the "with-target", then you've solved a problem that doesn't
exist: Guile bytecode (at least for version 2.2) only cares about the
"cpu-endianness" and "triplet-pointer-size". As all relevant CPU
architectures of today are little-endian, and we only care about 64-bit
the bytecodes are identical (tested with a simple module, compiled for
x86_64-pc-linux-gnu, x86_64-w64-mingw32, powerpc64le-pc-linux-gnu). So
in essence, instead of writing this additioanl code, we could just use
GUILE_AUTO_COMPILE=1 and collect the .go files. Which still doesn't
properly solve the setup for "downstreams" that apparently is now a
requirement, but at least doesn't require additional effort. I wrote
this in the discussion last weekend.

> TODO: actually integrate with build system, figure out load paths
> etc., also compile files not directly loaded in (lily).

Your approach also misses all modules that (lily) pulls in with a (use-
modules).


Am Montag, dem 21.02.2022 um 22:44 +0100 schrieb Jean Abou Samra:
> Honestly, if you are pessimistic about "a month or so" to
> get a setup that could work for a stable release, that
> doesn't make me confident about making a full switch now ...

My statement was about getting proper byte-compilation working, which
apparently is now a requirement since this weekend. Before, when I made
the proposal, it was only about getting compiled code into the binaries
which we already have a solution (GUILE_AUTO_COMPILE) and I just said
that, in my opinion, its integration is not a requirement for
switching.

> As far as I have understood the proposed plan, it involves
> putting the master branch in a state that is fundamentally
> unsuitable for production in Guile 2 and leave it so
> for months, while dropping Guile 1 support, making it
> effectively impossible to get something eventually satisfactory
> without the success of experimental work that has no
> proof-of-concept yet. In an environment run by volunteers
> where any person can be "hit by a bus" at any time, I don't
> consider this to be a wise plan.

I've been working on providing binaries with Guile 2.2 for more than
two years now, I had really been looking forward to finally closing
this chapter. I was close to giving up a number of times in the past,
and I'm considering it again. Realistically speaking, I'm not sure if
somebody would be able to continue that journey. Maybe the code I wrote
is good enough and I documented enough, but I wouldn't bet on it.

Meanwhile, please take a look at reality: Linux distributions are
switching to Guile 2.2 for LilyPond, no matter what the state is and
what our documentation recommends. Debian attempted to switch for the
stable release 2.22.0 (that is now in Debian stable) and we convinced
them to stick to Guile 1.8 more-or-less last minute. Arch Linux
switched to using Guile 2.2 twice, but I was able to convince them that
they should wait. Gentoo has an option to build with Guile 2, not sure
if it's used by default or up to the user. The package in Fedora
continues to use Guile 2.2 IIRC.
What this tells me is that we get a split user community if we do
nothing. If we want to avoid that and pro-actively test and fix issues,
we have to switch *now* and lead the transition.

Jonas

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