From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Reconsideration of MinGW work Date: Tue, 23 Mar 2010 00:04:05 +0000 Message-ID: <87ljdjlx8q.fsf@ossau.uklinux.net> References: <87fx3tjt3r.fsf@ossau.uklinux.net> <11640D11-A8D6-4C58-86FA-EF79F4D60770@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269302796 30150 80.91.229.12 (23 Mar 2010 00:06:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Mar 2010 00:06:36 +0000 (UTC) Cc: Guile User List , Guile Development To: Ken Raeburn Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 23 01:06:31 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ntrca-0000sq-UA for guile-devel@m.gmane.org; Tue, 23 Mar 2010 01:05:59 +0100 Original-Received: from localhost ([127.0.0.1]:34611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntrca-00029l-Hs for guile-devel@m.gmane.org; Mon, 22 Mar 2010 20:05:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtrcJ-00024l-9x for guile-devel@gnu.org; Mon, 22 Mar 2010 20:05:07 -0400 Original-Received: from [140.186.70.92] (port=52489 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtrcH-000240-SV for guile-devel@gnu.org; Mon, 22 Mar 2010 20:05:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NtrcF-0000tH-Nw for guile-devel@gnu.org; Mon, 22 Mar 2010 20:05:05 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:43494) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NtrcF-0000qc-G0; Mon, 22 Mar 2010 20:05:03 -0400 Original-Received: from arudy (host86-182-154-126.range86-182.btcentralplus.com [86.182.154.126]) by mail3.uklinux.net (Postfix) with ESMTP id 5D74C1F670B; Tue, 23 Mar 2010 00:04:26 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id C3CDD38026; Tue, 23 Mar 2010 00:04:05 +0000 (GMT) In-Reply-To: <11640D11-A8D6-4C58-86FA-EF79F4D60770@raeburn.org> (Ken Raeburn's message of "Sun, 21 Mar 2010 21:28:18 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10071 gmane.lisp.guile.user:7716 Archived-At: Ken Raeburn 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