Re: Reconsideration of MinGW work

[Andy Wingo <wingo@pobox.com>]

Hi!

On Mon 22 Mar 2010 02:28, Ken Raeburn <raeburn@raeburn.org> 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/