[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reconsideration of MinGW work
From: |
Ken Raeburn |
Subject: |
Re: Reconsideration of MinGW work |
Date: |
Sun, 21 Mar 2010 21:28:18 -0400 |
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
- Reconsideration of MinGW work, Neil Jerram, 2010/03/21
- Re: Reconsideration of MinGW work, Grant Rettke, 2010/03/21
- Re: Reconsideration of MinGW work,
Ken Raeburn <=
- Re: Reconsideration of MinGW work, Andy Wingo, 2010/03/22
- Re: Reconsideration of MinGW work, Greg Troxel, 2010/03/22
- Re: Reconsideration of MinGW work, Neil Jerram, 2010/03/22
- guile on lemote (was Re: Reconsideration of MinGW work), Ken Raeburn, 2010/03/28
- Re: guile on lemote, Neil Jerram, 2010/03/29
Re: Reconsideration of MinGW work, Peter Brett, 2010/03/22