Jonas Hahnfeld <hah...@hahnjo.de> writes: > On Sun, 2025-03-30 at 23:08 -0700, Mike Gran wrote: >> Mike Gran <spk...@yahoo.com> writes: >> >> I've created a new branch in the main Guile repo on savannah called >> wip-guile-2025, pulling in enough of various patchsets to get `make` and >> `make check` to run on 64-bit, threaded, JIT-enabled Guile on Windows 11 >> via MinGW 64-bit using UCRT. In the end, I based the patchset more on >> Guile's old wip-mingw branch than the LilyPond patches, but they are >> quite similar. > > I had a quick look and the major difference is the inclusion of the > large commit > https://git.savannah.gnu.org/cgit/guile.git/commit/?h=wip-mingw-2025&id=a043eaf349e151efb114f9363f8080956687ca46 > This was already discussed back in 2023 because it changes the argument > types of GMP from long to long long, and requires the use of mini-gmp > on Windows. I wrote back then why this might not be the best idea and > how my patches try to address this differently: > https://lists.gnu.org/archive/html/guile-devel/2023-10/msg00051.html > Overall I'm quite sad that this approach is not considered (in fact, > none of my commits are in the branch).
Nothing is set in stone and my hope here is to find consensus among all interested. There are primary Guile maintainers, but, they don't often express opinions on Windows issues, so unless they weigh in, I'm probably the only committer that has familiarity with the issues we're trying to address here who is willing to spend time on it. > >> There are no actions required by anyone at this point, but, I'll need >> some review once I have a tree I'm happy with. Apologies for the >> slow progress. > > Based on the above, I think the branch builds on a bad base. I'm not a > Guile developer, but I don't see new arguments for doing it in the way > taken by the branch. The argument, such as it is, is that unless `make check` works on MinGW itself, evaluating any set of patches is difficult. And since the Lilypond patches were not sufficient to make `make check` work, I bootstrapped with the bitrotten guts of what we had before to get back to a working `make check`. From here, it might be simple to extract the old 64-bit patch and incorporate the Lilypond patch set in whole or in part. I don't know yet. I haven't tried it. On the Guile side of the discussion, to the extent that I've received feedback: - rlb expressed the importance of ensuring the ABI on Debian versions of Guile don't change with minor revisions, so I think he'd like to see that any patchset to accomodate Windows doesn't change the 32-bit or 64-bit ABI for libguile on Debian. - janneke indicated that in the past, the *.go files were identical for the Linux and Windows builds on the same CPU - the Guix project does cross-build MinGW packages on their CI/CD, so cross building use case seems somewhat important to them - and spk121 (me) wants Guile to be buildable using the native tools of Cygwin and MSYS2's MINGW32 and UCRT64 toolchains So those are basically the exit criteria for this story. We'll get there. Just a bit more time. But if another Guile committer wants to champion the Lilypond patchset and push it, that's fine by me. No need to wait on me. Regards, Mike Gran
