Re: No Guile on Windows? (was: My Guile Hacker Handbook)

[Mike Gran <spk121@yahoo.com>]

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