Reconsideration of MinGW work

[Neil Jerram]

I've been making gradual progress on MinGW cross building, but I've
reached a point where I'm no longer sure that this is worthwhile.  This
email explains why, and invites comments from anyone interested in this
- especially from anyone who is really trying to use Guile on Windows.

First, I've found that completing a successful build (i.e. autogen.sh,
configure and make) is not at all the end of the story; it's only the
first part of what is really needed - because at runtime some key pieces
of function can still be missing, or can behave differently on
MinGW/Windows than on Linux/POSIX.  Two examples of this are operations
on file descriptors - where on MinGW/Windows different functions must be
called for sockets than for real files - and regular expressions, which
are not supported by the MinGW/Windows C library.

Therefore the definition of "success" also needs to include a successful
"make check", or some equivalent of that.  Using MSYS and MinGW on
Windows, I assume that "make check" can be run just as easily as
"make".  When cross-building with i586-mingw32msvc-* tools on Linux,
"make check" can be run (in principle) if you also have Wine installed,
and that's the setup that I've been using recently.

Second, though, it turns out that using i586-mingw32msvc-* and Wine on
Linux unfortunately does not give the same results as MSYS and MinGW on
Windows.  For example I've found that system(NULL) throws a SIGSEGV
under Wine, but for Carlo Bramix, working on Windows, that wasn't a
problem; and instead, for Carlo, there were other problems that I don't
see with a Linux cross build.

This is hardly surprising.  Although Wine aims to emulate the Windows
runtime DLLs precisely, of course it is only software and so can have
bugs.  But it is an extra hassle in practice.

Third, I reviewed my own need for Guile on Windows - and in fact I've
been perfectly happily using the Cygwin version for some time now.  So
actually I don't currently need a MinGW version - and maybe that would
be true for other Guile on Windows users too.

Looking forwards, supporting a Cygwin build of Guile will always be much
easier than supporting a MinGW build, because the whole point of Cygwin
is to provide an emulation on Windows of the POSIX API, and that's what
most of the Guile code assumes.

Fourth, I've realized that I significantly misunderstood MinGW's
objective.  Its true objective is to provide free software tools for
building native Windows programs to run with the Win32 runtime DLLs, and
the MinGW website is actually very clear about this.  That means that it
is 100% targeting the API provided by the Win32 DLLs.  But somehow or
other I had got the idea that it was also a bit Cygwin-ish, in trying to
provide pieces of the Linux/POSIX API that aren't provided by those
DLLs.

That last idea is completely wrong, which means that trying to build a
POSIX-assuming project for MinGW is always going to be hard.

Fifth, and now thinking more of the future with 1.9/2.0, I wondered if
it would be better to address MinGW porting problems within Gnulib,
instead of putting lots of #ifdef __MINGW32__ into Guile's own code.
And in fact yes, based on a small and completely unscientific sample of
Google results, it seems the Gnulib guys do regard MinGW compatibility
as part of their remit.

So putting #ifdef __MINGW32__ stuff into Guile is probably unhelpful
anyway, because it would be better to contribute to Gnulib instead.  And
it's possible that Gnulib might already have what we need.

And finally, I noticed that there already claims to be a MinGW port of
Guile 1.8, here:

http://sourceforge.net/projects/mingw/files/
http://sourceforge.net/projects/mingw/files/MSYS%20guile/guile-1.8.7-1/guile-1.8.7-1-msys.RELEASE_NOTES/download

Therefore I'm inclined to conclude the following.

- Overall, it isn't as important as I had been thinking to get a
  complete MinGW build of Guile.  I personally plan to concentrate more
  now on 1.8 - 1.9/2.0 compatibility, and on the manual.

- As far as future development is concerned, including the current
  "master" branch, MinGW portability fixes should be directed at Gnulib
  if possible, instead of done directly in the Guile code.

- As far as 1.8.x is concerned, I'm not sure if there's any need out
  there that isn't already met either by Cygwin or by the MinGW port
  linked above.

Anyone still reading?  Congratulations if so - and please let me know
what you think!

Regards,
      Neil