guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reconsideration of MinGW work


From: Andy Wingo
Subject: Re: Reconsideration of MinGW work
Date: Mon, 22 Mar 2010 21:10:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hi!

On Mon 22 Mar 2010 02:28, Ken Raeburn <address@hidden> writes:

> I think cross-compilation and cross-testing is a good thing to be able
> to do.

Totally agreed. I'd like to start compiling Guile for ARM devices now.

> Perhaps having build farms available with multiple platform types can
> help there.

There has been the Debian build farms (and will be once 2.0 is out):

  http://packages.debian.org/sid/guile-1.8

There are the nixos builders, which track git, and build on linux, fbsd,
and darwin:

  http://hydra.nixos.org/jobset/gnu/guile-master

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

So, point taken, sorta; but there are the builders above, I support mac
installations of Guile as well (intel 10.4 and 10.5 right now), Ludovic
regularly builds on sparc systems, and there are only about 6 active
committers anyway!

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

Heh, regarding VMS :)

Seriously though, I think we should drive the gnulib approach as far as
it can go, and only then make concessions in the areas where a gnulib
solution is inappropriate.

Cheers,

Andy
-- 
http://wingolog.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]