Re: Reconsideration of MinGW work

[Ken Raeburn]

On Mar 21, 2010, at 16:51, Neil Jerram wrote:
> 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.

Yes... you then also need to decide if Guile is exposing GNU/POSIX 
functionality, whatever the native OS functionality is, or some abstraction... 
e.g., looking at file descriptors, do you try to make sockets look like files, 
expose the differing underlying functionality to the Scheme coder, or make them 
distinct object types with some APIs that can handle both (and may do so with 
identical or different code, depending on the OS)?

I can imagine some ways in which distinguishing them would be beneficial.  You 
could code getpeername to reject arguments that aren't socket objects (instead 
of calling into the kernel to see if it works), and similarly for fstat and 
sockets.  On the other hand, the program will be started up with file 
descriptors on objects of types you don't know initially (on UNIX), so you 
still have to handle that.

> 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.

As an aside, one nice thing about the DejaGnu setup we had at Cygnus was that 
you could easily(?) define how to run tests in cross-build setups, and it could 
include "copy these files over to the target machine described in this config 
file and then use this command to invoke the program over there".  This was 
mostly used for embedded systems testing, with target boards connected via 
serial ports.  Once you've got the framework in place, defining new target 
systems and ways of communicating with them can be relatively easy.

Having just bought a Lemote Yeelong notebook at LibrePlanet this weekend, it 
has already occurred to me that cross-compilation from a faster machine (like 
my 8-core home Mac) targeting the Yeelong would be desirable; running tests too 
would be better still, when a machine is available.

> 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.

You *are* reporting these bugs, aren't you? :-)

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

I think cross-compilation and cross-testing is a good thing to be able to do.  
Obviously cross-testing requires some additional setup -- as a trivial example, 
the test suite code isn't going to know the name or IP address of your Windows 
or Yeelong machine.  I know it's hard to set up, though, and especially hard to 
maintain if few people actually use it.  Perhaps having build farms available 
with multiple platform types can help there.

One nagging concern I've got about my Guile-Emacs project is the seemingly 
narrow focus of active Guile developers as far as platforms are concerned.  I'm 
one of, what, two or three people testing the development versions on Mac OS X 
now and then, and most of the rest of the work is on x86 or x86-64 GNU/Linux 
systems, it seems?  But Emacs works on a lot more systems (including MinGW, for 
people who don't want all of Cygwin), and saying "hey, we can change Emacs to 
be Guile-based on x86 GNU/Linux systems; too bad about all the other platforms" 
wouldn't go over terribly well.

For a random Scheme implementation, it's okay to pick the set of platforms you 
want to support, and drop whatever's inconvenient.  But if you want to be the 
official extension language for the GNU project, used by (theoretically) lots 
of GNU packages, you've got to support all the platforms the developers of 
those platforms want to support, if you possibly can.  I think that includes 
both Cygwin and MinGW, and probably not just supporting whatever subset can be 
mapped into POSIX functions via Gnulib.  We can probably punt on VMS, though....

Ken