Standard library portability

[ehuss]

This issue is for discussing different needs for making the standard library more portable and configurable.

There have been a number of proposals over the years for improving the portability of the standard library, and improving the organization and use of platform-specific APIs.

Some people also desire ways to change the behavior of the standard library, such as through using Cargo features to choose alternate implementations or additions (see #4).

Portability and configurability are two loosely related concepts that perhaps should be considered separately. However, they may have the same or related ways to approach, so I am combining them here.

This issue is a place to explore this rather large problem space. Perhaps initially it would be best to clearly articulate the needs for making it more portable, configurable, and also how libraries declare what they are compatible with. Perhaps listing some concrete use cases, existing problems and pain points, etc.

For those interested in different historical concepts for standard library portability:

• RFC 1502 proposal — libstd::sys, the great libstd refactor
• Scenarios
• PAL proposal
• RFC 1868 — Portability lint
• aturon's vision for portability
• Portability working group
• Embedded working group

[SimonSapin]

I think this is two related but distinct topics:

• Porting the standard library itself to new targets. (std::sys, PAL, Portability WG, …)
• Helping users of the standard library to write portable code (Portability lint, aturon’s vision, …)

They are both important, but I’m not sure that Cargo needs to be involved at all in either. So maybe this repository is not the best place to discuss them?

[ehuss]

So maybe this repository is not the best place to discuss them?

Very likely. There are a few reasons why I bring it up:

• The mechanism of making it more portable may require some syntax in Cargo.toml, like features, but those may not be appropriate for stability reasons. If we end up needing to change how features works, then it is relevant to Cargo.
• One of the goals of this project is to make it easier to build for unsupported targets. To that end, this is one of the impediments.
• If a custom target needs to somehow provide its own implementation of parts of the standard library, how would that be expressed?

I just wanted to keep the big picture in mind as we move forward.

[Ericson2314]

[For my vision at least :)] The most important thing to do is get the official rustc build system to leverage this feature std-aware Cargo as soon as possible. (Since rustc boots from a specific rustc and Cargo version, can it use unstable features?) This will make using external crates in std like hashbrown and parking_lot easier, after which I hope this problem can be resolves in a rather organic / distributed fashion.

Should we have a ticket for the rustc build system using this? Beyond the benefits I mention, we want to make sure this feature is good enough for that before stabilization. If it can't work for that, we probably messed something up!

[SimonSapin]

What do you mean by “this” feature? This thread is about a rather wide (pair of) topic(s) with a number of different proposals, not a single specific feature. (Perhaps you meant this comment for another thread?)

[Ericson2314]

Sorry by "this feature" I meant std-aware Cargo as a whole.

[SimonSapin]

Ok, so this thread is not quite the place for that topic. Regardless, rustc’s build system is quite special since there are multiple stages of bootstrapping, it’s not clear that Cargo will (or should) know how to do deal with that.