On Sun, 2025-03-30 at 23:08 -0700, Mike Gran wrote: > Mike Gran <spk...@yahoo.com> writes: > > > I'm making progress. I just pushed back into Guile's main branch a > > patchset that makes the 32-bit MinGW build again, which was broken. The > > 32-bit build is now working on my native MinGW on Windows 11, and I'll > > know today if it works on Guix's CI cross-build. > > > > Assuming all goes well, we'll be back to square one, haha. From, here we > > your patchset can be applied to a branch off of Guile's main to see what > > happens. > > 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). > 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. Jonas
signature.asc
Description: This is a digitally signed message part
