[discussion / pre-pre-pre-RFC] out-of-tree platform support for libstd

libs
1

Firstly, apologies if this just rehashes / conflicts with previous plans that I have failed to find, or is seen to be stepping on any of the teams’ toes.

I’ve been working on porting libstd to a target that I doubt will ever be upstreamed. This is more work than I anticipated so I wondered if my efforts would be better spent first working on making life easier for new targets. I also see this as an opportunity to work towards something that I’ve seen flirted with in the past - support for out-of-tree libstd platform implementations.

This topic is meant to spur discussion about how much work this would require, how far along we are (afaik the libs team do not have public meetings so this is difficult to gauge from an outside perspective), and how people can help. To start, I have laid out a high-level, possibly-flawed plan for refactoring libstd.

Goals

  • Make the split between libstd and the underlying platform implementation clearer and more enforcable
  • Make it easier to port libstd to new targets
  • Support out-of-tree implementations of libstd

Broad strokes, as I see them

  • Move features provided by xargo into cargo itself, allowing custom versions of libcore, liballoc and libstd to be build and used. I believe this is already something that is going to happen, just a question of the work being done.
  • Create a crate to represent the interface between libstd and a platform implementation - suggested name of libplatform, open for bikeshedding
  • Write crates for each existing target, which use libplatform, implementing libstd's existing functionality
  • Provide some way of “selecting” an implementation while building libstd
  • Migrate libstd to use the implementations
  • Eventually remove std::sys and std::sys_common in favour of the definitions within libplatform - these modules are not public and so this is backwards compatible

I have purposely left these last bullets quite vague - I’d like to get some input from more-experienced people before being more detailed, but I see the two most probable designs being trait-based and monomorphizing to the implementation’s providing type within libstd, or specifying a set layout for the implementation crate and generating a extern crate platform_linux as implemention; in libstd.

Prior discussion (that I’ve managed to find, probably not a complete list)

Specifically, I’d like to know whether this is still seen as a valid approach, and whether it would be supported by the teams and community. If it would be, what are the next steps for formalising an approach (as this would not impact end-users, would this require RFCs?) and starting work?

1 Like
2

I’d recommend continuing the discussion in https://github.com/rust-lang-nursery/portability-wg/issues/1

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.