Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Dienstag, dem 22.02.2022 um 09:02 +0100 schrieb Jonas Hahnfeld via
Discussions on LilyPond development:
> 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.

See https://gitlab.com/hahnjo/lilypond/-/commits/guile2-bytecode Let me
know if this is miraculously sufficient to make people happy and I can
open a merge request.

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