On Tue, Feb 22, 2022 at 12:05 PM Jean Abou Samra <j...@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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen