Re: Reconsideration of MinGW work

[Ken Raeburn <raeburn@raeburn.org>]

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