Re: Reconsideration of MinGW work

[Ken Raeburn <raeburn@raeburn.org>]

On Mar 22, 2010, at 20:04, Neil Jerram wrote:
> 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.)

But is that POSIX, or something more abstract, when POSIX and other platforms differ in significant ways?

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

Don't know yet; I've been having network problems until tonight.  But I plan to try it out, maybe later this week.

>> 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?)

It is kind of a pain, isn't it?  But with all the spam flying around these days, it seems to me that fewer and fewer projects/sites accept anonymous email or web submissions.

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

I believe NetBSD (and maybe some of the GNU/Linux distros?) has made progress in cross-compiling for the OS on one architecture, hosted on the OS running on another architecture.  (And I'm not just talking about 32-bit and 64-bit variants of the same architecture -- this might be x86 to sparc, for example.)  So a first cut at something like this might just take as little on the Guile side as setting up the test suite to copy binaries and test scripts over to the target machine with scp, then run a test over ssh.  Hmm....

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

I'm glad to see the other non-Linux people were paying attention. ;-)  I guess I overstated the situation, but I have on occasion gotten the feeling that only GNU/Linux systems were getting tested as part of the main development work, with "porting" back to other systems happening later, when Greg or I or someone else found problems.  (I can certainly understand not trying on every system on the planet.  But *occasionally* it feels like only one is really used.)  But, we are paying attention, when we've got time, and those of you doing most of the core development work are doing awesome stuff, and listening to us when platform issues come up, so I shouldn't be complaining too much....

The build farms are a good improvement; we should try to get as much variety there as we can.  And maybe some sort of alert (bot messages to #guile ?) when a build fails...

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

We could ask and see.  And maybe get someone to figure out how to fit Cygwin and/or MinGW into the build farm (or some automatic build-and-test setup), and keep an eye on things, while we help them get their porting changes integrated.

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

I don't mind trying to sound authoritative sometimes. :-)  And I deal pretty well with the UNIXy bits of Mac OS X.  But sometimes I'm unsure how things are intended to work on the Guile side.

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

I had the impression that Gnulib was about emulating the GNU/Linux/POSIX type API on other platforms, not providing an abstraction.  But it looks like I'm wrong; at the very least, there are non-POSIX utility functions as well as replacements for missing POSIX routines.  Maybe that is the way to go, then....

Ken