Definitely add aarch64-apple-ios and aarch64-linux-android as Tier 2 platforms, at least. In particular, provide pre-built libstd for them and gate changes on those libstd builds passing. Ideally, these should be Tier 1 platfporms.
Strongly consider adding the other top platforms that are currently Tier 3 as Tier 2 platforms.
In particular, it should be relatively easy for somebody making a cross-platform library/framework to build & test on aarch64-apple-ios and aarch64-linux-android (and, ideally the other platforms). Right now it is difficult because there’s no libstd provided for these platforms.
Nobody decided that these platforms shall have worse support. Their Tier-3 status is because a laundry list of necessary work hasn’t been done, so what you are really suggesting is that people roll up their sleeves and figure out how add builders for these platforms and fix all the errors that those builders find. It is of course valid to suggest “hey this thing is cool it would be cool if someone did that”, but let’s be up-front that we are talking about a significant chunk of work, not just flipping a switch.
For iOS, here are instructions for building libstd:
I guess that aarch64-linux-androideabi is pretty much the same as arm-linux-androideabi, which I imagine is about the same as the iOS stuff above.
So, maybe somebody could point out where the stuff at https://static.rust-lang.org/dist/ gets built/packaged/deployed, and I can just copy-paste the arm-linux-android stuff to add iOS and AAarch64 Android support? Is there something I'm missing?
Starting a cross-build isn’t difficult, it’s making the build succeed and having enough hardware to swiftly execute all the additional builds. But I now noticed we already have a builder that cross-compiles to iOS (auto-mac-cross-ios-opt). So those problems have actually been solved, yay!
What’s more, the stable version of the book is actually outdated, the nightly version has the current state of the matter. aarch64-apple-ios, armv7s-apple-ios, and aarch64-linux-android (under slightly different names) are already Tier 2. Morale of the story: Check your sources before you get in arguments
Windows XP in particular is tier 3 not because we don’t want to support it, but because rustc/cargo simply don’t work on XP. They depend on a lot of system APIs that simply do not exist on XP and modifying them to not rely on those APIs on XP is a lot of work that nobody really wants to do.
There are parts of libstd that simply do not work on XP, some of the synchronization stuff in particular, but also other things here and there. The iOS libstd is much more functional than the XP libstd.
I don’t believe that Tier 2 requires that you run the test suite; just that libstd builds.
However, I also think that having XP listed at tier 3 is not quite right; since it doesn’t have a different target triple, and the compatibility fallbacks for XP are done at runtime, I believe that the existing i686-pc-windows-msvc and x86_64-pc-windows-msvc libstd builds would qualify it to be at Tier 2, libstd only, as it does build libstd for XP, there are just expected test failures of any test that depends on the functionality that’s unavailable on XP.
Hmm. I'm seeing the iOS targets you list there, but not aarch64-linux-android, which appears to still be Tier 3.
However, that seems to be the only one that's still Tier 3 in the nightlies, of those that @briansmith mentioned in his original post, if I'm correct about the definition of the tiers and that the existing libstd works on XP except for things that require the unavailable APIs.
I believe @hanna-kruppe's point above is spot on, nothing is intentionally not a tier 1/2/3 platform in Rust, it essentially just means that no work has been done to promote it just yet. Platform support typically just starts out as a PR for all the initial changes, eventually we then add some builders and CI to keep it building, and then the final step of moving to Tier 1 is a bit hazy as it's never happened before, but I suspect it's a case of "we'll know it when we see it".
Along those lines most of these platforms in question likely just need a PR to rust-lang/rust-buildbot to add an auto builder to start gating on the platform. Unfortunately this isn't a trivial task as our buildbot config file is pretty sprawling, but lots of the target-specific configuration has been refactored to be somewhat easily readable. If a platform fits in one of those buckets, then it should be easy to add!
PRs are of course always welcome to rust-buildbot! Unfortunately testing out changes isn't always the easiest thing so there may be a bit of a delay to pushing it into production for us, but hopefully it won't take too long. Most of our cross compilation happens in docker images so you can run 90% of the build locally (and I can audit the last 10% hopefully).
To address some specific points brought up about a few platforms in this thread:
As @lambda's PR shows this is essentially almost a tier 2 platform. My hesitation here is simply that we have no CI preventing us from accidentally requiring a Windows 7+ API. We'll likely always have a similar story about how the standard library is somewhat hamstrung on XP, but this seems suitable for simply being XP's tier 2 platform story.
The tl;dr; is basically that we need a bot that compiles hello world on XP and ensures there are no link errors.
This, and all other iOS targets, should already have nightlies!
We'll probably also want to ensure that the NDK is the right (read, "oldest") version, but that's also easy to verify later.
As another note, the rustc/cargo working on a platform is not currently a threshold for Tier 2. It's not even a requirement for Tier 1! Each platform gets to decide what's in scope for tier 1/2/3, where this of course always includes the standard library and then optionally includes rustc/cargo as appropriate.
Also note that any new platform takes some time to move into the stable channel, so once we add support it'll have to ride the trains into beta and then stable before it's actually available in release.
Hope that all makes sense! If you've got any questions about any of this, feel free to ask
Can't compile on XP because rustc won't run on XP. Also linking for XP is identical to linking for other versions of Windows, aside from passing /SUBSYSTEM:CONSOLE,5.01, so linker errors aren't going to be informative either. Really the only thing we need to do is to actually run the hello world binary on XP. If it exits with a successful exit code and the output is correct, then it passes. So basically build Rust on modern Windows, build a hello world binary with /SUBSYSTEM:CONSOLE,5.01, boot up an XP virtual machine, copy over the hello world binary, run it on the virtual machine and somehow send back the exit code and output of the binary to verify it so the test can pass.
So, good news! I was under- and mis- informed due to reading the wrong set of documentation. It seems other people had already had the same thoughts as me and had gotten most of the work done even before I posted my suggestions. Since I started this thread, aarch64-linux-android builds of libstd have become available at https://static.rust-lang.org/dist/ and basically all my concerns have been addressed.
FWIW, I would be interested in seeing somebody maintain a branch of libstd that fully supports Windows XP (including Mutexes, std::sync::Once, and other things that aren't currently working on WIndows XP). FWIW, until a few months ago (when Chrome dropped XP support), BoringSSL had C code for working around the limitations of XP in these areas, so I'm pretty confident it can be done relatively easily. However, I think it's also fair for the Rust teams to not do it. OTOH, I suspect the Firefox developers will run into these issues and probably eventually address these issues.
