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 <j...@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
