Re: Blockers for Guile 2.2

[Han-Wen Nienhuys]

On Tue, Feb 22, 2022 at 12:05 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
>
> Friends,
>
> I don't see this thread coming to a conclusion if it stays between the same 
> three people, and the topic is somewhat important to LilyPond's future. More 
> voices would be helpful.


Here are my thoughts:

* GUB needs to die. Really: I don't ever want to touch that code
again, and I can't fault anyone else for feeling the same.

* We've got GUILE 2.2 support to a state that we can vouch for. We
need to keep that state. This means we should switch CI to run on
GUILE 2.2

* I'm worried that introducing a new version of lilypond that is
significantly slower than older versions creates an incentive for
users to stay on older versions.

* I grepped our source code for "guile-2" (scm) and GUILEV2, but the
divergence of code paths seems pretty minor. Sure, it's inconvenient
to have the odd conditional or limit ourselves to what is both in 1.8
and 2.2, but I'd rather see us drop 1.8 support once we see an
obstacle that we cannot paper over.

* The concern over CI minutes seems like it's the least important: we
can buy more computing power (I'm happy to sponsor), and is the
duration of CI much of a concern today? I don't think we have to do
the doc build across both 1.8 and 2.2, for example.

* We're talking about the impact of (the lack of) byte compilation on
users, but we haven't discussed the impact on ourselves: the startup
slowness affects our every debug/edit cycle, and byte compilation is
impractical because we change scm files often (by virtue of checking
out other branches). If we need to kill 1.8 support because it blocks
something important, then so be it, but given the impact on lilypond
development, I'd try to postpone it if possible.

* In the discussion, we've been treating "keeping GUB alive" and
"supporting GUILE 1.8" as equivalent, but is that really the case? We
can't have GUILE 1.8 for 64-bit windows, but for OSX/Linux, it would
be an option with the new release scripts too?

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

I'm glad to hear that, but do we know about the GUILE team's plans in
this space? It would suck if they want to move to CPU dependent
bytecode.

> properly solve the setup for "downstreams" that apparently is now a
> requirement, but at least doesn't require additional effort. I wrote

I read over this thread, but I don't understand what you mean by
"downstreams" here.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen