[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: |
Tue, 23 Mar 2010 02:59:46 -0400 |
On Mar 22, 2010, at 20:04, Neil Jerram wrote:
> Ken Raeburn <address@hidden> 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
- 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, 2010/03/21
- 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
Re: Reconsideration of MinGW work, Neil Jerram, 2010/03/22
Re: Reconsideration of MinGW work, Ludovic Courtès, 2010/03/28