Re: Reconsideration of MinGW work

[Neil Jerram <neil@ossau.uklinux.net>]

Ken Raeburn <raeburn@raeburn.org> writes:

> Yes... you then also need to decide if Guile is exposing GNU/POSIX
> functionality, whatever the native OS functionality is, or some
> abstraction...

Ideally, yes, I think.  In other words, I think it's preferable if Guile
provides the same function to applications on all platforms.  (Emacs
shows how fantastically useful this is.)

> Having just bought a Lemote Yeelong notebook at LibrePlanet [...]

Aside: I was wondering about buying one of those too, but haven't yet
because of performance concerns.  Can it compile Guile successfully, and
if so how long does it take?

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

Err... not yet.  So thanks for the reminder.  But I just checked, and
their (i.e. Wine's) bugzilla requires creating an account, so I'm not
sure I'll bother.  (Is that really irresponsible of me?)

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

I agree that this is useful, but it is, as you say, difficult to set up.
Personally, to the extent that I continue working on this, I think I'm
happy to limit myself to what can be achieved with emulation (i.e. with
Wine) on a single Linux box.  At least so far as regular builds are
concerned; of course I'd also expect occasionally to copy the built DLLs
over to Windows and try them 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?

Yes, but this isn't intentional, just a matter of limited resources.

On the other hand, in the Windows case, it seems there is independent
effort being put in to the problem downstream.  I wonder why that's
downstream - perhaps because we're not good enough at accepting patches
when they're offered?

On the MacOS side I haven't been closely involved recently, but I think
- for all platforms other than the really mainstream ones that you've
mentioned above - we need people who are authoritative about what the
solution for a given problem is.  If I see a patch for MacOS that seems
to be done at the right place in the build, and obviously doesn't
inappropriately impact other platforms, and the submitter is
authoritative about it being the right solution for MacOS, it's easy to
say "OK, I believe you, and there's no risk, so let's commit it".  But
in the conversations that I remember there hasn't been that
authoritative tone; it's more like I've needed to work out half of the
solution myself, which I'm not in a position to do.  So then things get
left sitting, etc.  And similarly for other less mainstream platforms.

> For a random Scheme implementation, it's okay to pick the set of
> platforms you want to support, and drop whatever's inconvenient.

Which is absolutely not my intention...

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

>  I think that includes both Cygwin and MinGW,

This is a key point.  My previous email hinted that Cygwin support might
be enough, and several people have commented that it isn't.  So I'm
happy now that that hint was wrong.  For me, then, the questions are
whether we need any more Cygwin/MinGW support for 1.8.x than what
already exists, and how, structurally speaking, we do Cygwin/MinGW
support for 1.9/2.0 and future releases.

Having said that, I don't feel I understand technically why a MinGW
version of Guile, including all necessary emulation code, would run
faster or be less bloated than a Cygwin Guile.  Can someone explain
that?

> and probably not just supporting whatever subset can be mapped into
> POSIX functions via Gnulib.

I don't think I understand your point here.  Gnulib isn't a fixed point.
If we can add emulation code into Guile, can't we just as easily add it
into Gnulib?

Regards,
       Neil