On Fri, Jul 24, 2020 at 09:22:54AM +0200, Dr. Arne Babenhauserheide wrote: > > This is one of the biggest worries I have with the time I put into > Guile: Many of my friends are still on Windows and in the current state > of Guile I won???t be able to create tools that help them. > > Creating installers for Windows was bad with Python, it is much worse > with Guile. I wish I could just do something like > guild package --target windows -o my-program.exe entry-point.scm > > This prevents people from using Guile for anything that might have to be > cross-platform (though the Lilypond folks got it working > https://lilypond.org/windows.de.html).
Yeah, I did put a 32-bit, no-thread Windows version of Guile-2.2 in a game-jame game I did once, but, it was non-trivial. For those that hanven't programmed on Windows much, it is a bit of a struggle. The native tools are C++, not C, and the native API is just different: different threading, different asyncs, similar but still not identical sockets, different dynamic linking. No guarantee that the sizeof(long) is sizeof(void *). So different groups have created projects to help port or run legacy UNIX-like software to Windows. The most familiar to free software people are Cygwin and MinGW. Cygwin: use gcc or clang, link to a special C and POSIX library that handles the Windows API for you. This exists and works well for Guile. Its emulation library is GPL, so to distribute a Cygwin app, it must be GPL and must include a healthy chunk of the Cygwin infrastructure. MinGW: use gcc or clang, link to native Windows API. Guile almost supports this, because it uses Gnulib. Gnulib has a library of shims that tweaks Windows C library API to be more POSIX-like, but, Gnulib isn't a comprehensive solution. When free software people talk of a "port" to windows, they usualy mean that it is built with MinGW. But, of course, MinGW had a spat years ago and now there are two competing MinGW projects. Sigh. Some projects go a step further and try to use the native windows compilers and API, but, since autoconf basically won't work on Windows because its shell language is not /bin/sh but is PowerShell or CMD, this usually requires a different build system, like CMake or Meson. Guile has both autoconf and gnulib, so MinGW is the semi-supported path to a native Windows executable. It actually would not be a lot of work to get a 32-bit, unthreaded Guile 3.0 working again, assuming that lightening works for Win32. Just some run of the mill patching. But historically getting these patches in the main tree has been an awful experience -- expecially in the Mark era -- because of arguments as to whether they should be fixed in Guile or in Gnulib and having to deal with both Guile and Gnulib having competing interests. Thanks you for coming to my TED talk. Regards Mike Gran