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.
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 theEmbedded 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
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.
Does that make sense?
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.
Anyhow, there is work going on for integrating xargo into cargo being led by@japaric .
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 .
As I want to create a libc implementation in rust lang I am very much interested in this WG… Is there a gitter channel for the WG?