The Portability WG is being launched to track and improve the portability of
the Rust libraries and ecosystem. Interested in making sure Rust is a
first-class citizen on all past, current and future platforms? Get involved at
rust-lang-nursery/portability-wg.
While the Rust language and compiler can easily target many platforms, std
and crate support is a different story. The goal of this WG is to make it easy
to take existing Rust code and make it run anywhere! To do this, we’ll make it
easier to port std to new platforms, we’ll make it easier for crate authors
to write portable code, and we’ll make it easier for developers to discover
portable crates.
Our initial effort will be to refactor std to cleanly separate the
platform-specific code from other code. Then we’ll move on to other things,
such as possibly implementing the portability lint and other static analysis
mechanisms. Come check out the working
group for current and
future plans.
You can usually find the members of the portability WG on the #rust-portability channel (server: irc.mozilla.org). Most of us use our GH usernames as our IRC nicknames.
It is not clear why the first step is not xargo’s improvments.
Because of before anything else you need compile your code. And only after you can generate code for you target CPU you can start to think what how to deals with not supported OS in std.
I think that improving cargo (that is, including xargo’s functionality into cargo) may fall under the responsibility of the Embedded WG led by Japaric (the author of xargo).
I must admit it’s not quite clear to me what’s the difference in scope between Embedded and Portability at this point
Here's how I see it. Note I'm not a member of either WG
Embedded: "Is the Rust experience nice on embedded platforms?"
Portability: "How can we get Rust to run on other platforms more easily?"
These are related but different questions. In some sense, Portability is foundational, and then for each platform, the nicer stuff gets layered on top. Embedded is that layer for certain platforms. You could imagine a "windows WG" that would work on stuff like this. That'd be analogous to embedded, but I think the distinction from Portability is more clear.
I think there can be a certain amount of overlap between different working groups; it’s mostly a question of what their focus is.
It sounds to me that embedded is mostly focusing on, well, embedded systems, which are generally #[no_std] and don’t really want much of std, need to deal directly with hardware, etc.
Portability has a broader focus, including desktop and server style systems that you do want to port std to, but may only be able to support a subset, or want to be able to do it incrementally and not have to maintain a fork of rustc while doing so. Or ones for which there is no libc, so the C compatibility types like CString are not really relevant. Or wasm.
I think part of the reason that xargo showed up in the embedded world first is that you need to easily be able to set up cross-compilation targets in the embedded world, while for porting to other full-fledged systems someone only needs to do it once to bootstrap the compiler and then it can be self-hosted from then on. Though of course, for systems which haven’t yet had the compiler bootstrapped and binaries available, xargo would help out there a lot in the meantime.
I agree there’s overlap with the embedded WG. That’s why there’s an issue specifically for coordination with the embedded WG. The way I see it embedded is more about tooling and CPU architectures, whereas portability is about std and crate ecosystem.
Similarly, there’s also overlap with the WebAssembly WG.
