I've been doing Go development for chumby (ARMv5-based) devices for months, and do all of my editing and compilation on Windows and then just rsync the binary over as part of my Sublime Text 2 build script.
Go is the greatest embedded-device-style development environment I've ever used, by far, without all the hassles of having to build a full cross-compile toolchain or use some hopelessly out of date vendor-made BSP cross-compile toolchain.
(FWIW, building a Go compiler right on the device is easy as well, but even with Go's focus on fast compile times, cross-compiling is still a much better experience when targeting these low CPU/low RAM devices).
Cross compiling is certainly necessary and useful for bootstrapping a
new platform. It can also be a lot faster to cross compile when the
target system is slow, but there is a well known drawback to using cross
compiling to speed up development times; you are not stressing the
target system, and hence, you've made target-specific bugs harder to
find.
Of course, there can be substantial costs from slowing down builds and
spending development time waiting for compilation on the actual (target)
hardware. On the other hand, the advantages of finding target-specific
bugs and adequately stressing the system can make the expense
worthwhile. Bad hardware happens far more often than vendors like to
admit, and stressing the system is a good way to test it.
As always, it's a trade-off.
The good example of taking the expensive but thorough approach is the
OpenBSD project. After getting past bootstrapping an new platform, all
builds are done on the actual (target) hardware. Since the code base is
cross platform, the new platform could give them the benefit of finding
bugs that don't manifest or are unnoticeable on all of the other
supported platforms. Also, the OpenBSD project does pretty much continuous
build of their tree on actual hardware, so they're always stressing
the hardware to make sure it's working properly, as well as finding
errant bugs that are tough to find on a single platform.
This only makes sense some of the time, like in your OpenBSD example. Native compile for an embedded app brings much less benefit and significantly more pain.
I've been doing Go development for chumby (ARMv5-based) devices for months, and do all of my editing and compilation on Windows and then just rsync the binary over as part of my Sublime Text 2 build script.
Go is the greatest embedded-device-style development environment I've ever used, by far, without all the hassles of having to build a full cross-compile toolchain or use some hopelessly out of date vendor-made BSP cross-compile toolchain.
(FWIW, building a Go compiler right on the device is easy as well, but even with Go's focus on fast compile times, cross-compiling is still a much better experience when targeting these low CPU/low RAM devices).