Sort of off topic, but one thing I really enjoy about the Go project is how open development and intent is. In addition to this, the Go team has shared plans (and invited discussion) for many things, some examples:

Internal changes: https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5...

Linker overhaul: https://docs.google.com/document/d/1xN-g6qjjWflecSP08LNgh2uF...

Garbage collector changes: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...

Ditto on the Darwin builds.

Since Apple ditched the Xserve forever ago and the legal issues of Mac OSX on non-apple hardware, builds on mac are a pain in the ass for everyone. You get to buy your Mac Pro, deal with VMware when you want to build for more than one OS (which of course means someone always loses days at a time doing something minor), and hope you have a nice 6U square peg available for your cylindrical trashcan peg.

Not 6U, a pair of mac pros needs only 4U of rack space.

http://www.sonnettech.com/product/rackmacpro.html

Seems like overkill, with the unused graphics capabilities, I guess the cards could be removed. Could a couple of macbook pros fit into a 1U?

Well most of the computing power is in the GPU, so for some sort of specific application you could take advantage of them, but for this sort of thing, yeah, it's not a great fit. I'm not sure about laptops. You could probably do it, but there was an article on here a while ago about using chromebooks for ARM native compilation, and the result was that the machines weren't quite up to it. The load would kill the machines and cause their batteries to swell up alarmingly. I'm not sure if a macbook would fare better.

These days, if you have a portable project that builds on both Windows and Linux, it's fairly easy to set up a MinGW-based cross-compiler and do all your builds on Linux. Does anyone have a useful cross-compilation environment for OS X? Clang and GCC should both be quite capable, so the primary issue would be obtaining the necessary headers and (possibly stub) libraries.

>>These days, if you have a portable project that builds on both Windows and Linux, it's fairly easy to set up a MinGW-based cross-compiler and do all your builds on Linux.

That isn't very useful if part of what you are testing are builds on OSX.

Go OSX build have broken due to very Apple specific issues before.

> > These days, if you have a portable project that builds on both Windows and Linux, it's fairly easy to set up a MinGW-based cross-compiler and do all your builds on Linux.

> That isn't very useful if part of what you are testing are builds on OSX.

That's probably why the next sentence in the post you are responding to was the following question:

> > Does anyone have a useful cross-compilation environment for OS X?

Why not buy a Mac Mini?

Slow.

Slow is better then not at all in my books.

This discussion is taking place in the context of trying to speed up our build bots. We already have slow mac minis.

A customized MD389LL (2.6 Ghz i7, 16 GB RAM, 2 x 256 GB SSD) would be quite mean actually!

Sweet. I’m in the same boat, using buildbot to produce binary packages (from git) for Debian unstable and the most recent Ubuntu release.

I’m particularly interested in the orchestration part of what they come up with in order to quickly boot VMs on GCE (or other cloud providers), do a build, and turn them down again.

Should I assume that this topic directly relates to building Go the language and not Go binaries that we use Go to write?

I see some comments here that seem like overkill for building cross-platform binaries which is why I ask.

How does this research project help us today?

Today? Not at all, unless you have some connections at Microsoft Research. But it would seem to be just the thing to address some of the concerns in the Windows section of the OP.

Having actually gone through the pains of using Chef to provision a Windows box, I would say it was totally worth it.