I’ve been building/hosting unofficial rust and cargo nightlies for
arm-unknown-linux-gnueabihf for almost 2 weeks now. Note that I’m not gating the uploads on the success of
make check because some tests are failing and I can’t commit to fixing them right now. However, I still run the test suite and upload the full logs, so at least potential contributors can tell what needs fixing.
I’d be interested in providing my ARM board as a buildbot slave. However,
I don’t think this is a good idea in my case, because build+test time for rustc in my quad core ARM device is 6h+. Even if bors doesn’t gate on the success of my ARM build, it would still have to wait for it to finish, right? That would greatly increase test cycle time.
But, I could hook my buildbot slave to the snapshot and nightly triggers. Which would be very similar to what I’m doing now, except that it would ensure that my nightlies are built at the same commit hash as the official ones are. Right now my builds are time based, so they may not always match the official ones (haven’t seen that happen so far).
About distribution via rustup/multirust. I think we should put the unofficial nightlies behing an
--unofficial flag to let the users know that they are opting in to non officially supported target:
# On some ARM device
The `arm-unknown-linux-gnueabihf` is not an officially supported triple, however, there are unofficial nightlies in stock. You can opt-in by passing the `--unofficial` flag. Be warned that these nightlies may break from time to time (..)
$ ./rustup --unofficial
# Proceed with install
Or not use the flag, and simply add a warning message telling the users that they are using an unofficial nightly. But, I think it’s easy to miss the message with this alternative approach.
Another thing I’d like to see is some help for cross-compilation. Since compilation times are rather bad on some ARM devices (6 seconds to compile “Hello, world!” on a single core ARM device), some people have requested information on how to set up cross-compilation. I wrote a guide about the topic, and I think rustup/multirust could provide some help in this area.
What I have in mind is a
--target=$TRIPLE flag that would download the nightly for $TRIPLE and install the cross compiled crates (.rlibs) in the native installation. At the very least this should let you easily cross-compile static libraries. Cross compiling binaries or crates with C dependencies additionally require a cross-compiler for linking and cross-compiled C libraries (
libgcc_s, etc), but, I don’t think we can provide much help for these other scenarios.