Consider building the standard library with Cargo

[emberian]

This is distinct from #16091. Once we've hit 1.0.0, there's no better way to dogfood that stability than have the standard library a normal part of the Cargo ecosystem. The main benefit is that cross-compiling suddenly becomes a lot easier, especially for bare-metal targets: just use the normal --target with cargo. It also means that the answer to "do I need to add a line to my Cargo.toml" becomes a lot easier.

Cargo would inject references to std etc automatically, with an opt-out flag at the package level for things such as zinc or operating system kernels.

Building rustc would become slightly more interesting, but would probably just involve juggling with the PATH so that Cargo is pointed at the right place.

[emberian]

cc @alexcrichton @brson

[Gankra]

Oh dear yes please. Being able to cargo test std while iterating on some work would be amazing.

[alexcrichton]

I do agree that cross compilation would be easier with this, but I wouldn't forget that cargo builds 100% of its artifacts from source, and you probably don't want to build libstd from source for all of your projects. This is a nice-to-have, but it will probably complicate cargo/rust, especially the rustc build system, so we'd have to tread lightly.

[jauhien]

cargo builds 100% of its artifacts from source

I would say that this is a problem with cargo. Think, e.g. about software packaging and distribution. You definitely do not want your build system to download and rebuild everything, you want it to use the libraries already installed in your system. So I think, this should be fixed in the cargo (e.g. add some switch like use-systemlibs).

I mean, we need it for EVERY library, not only the standard one.

[emberian]

Or rather, some cache of build packages.

[jauhien]

Or rather, some cache of build packages.

No, if you really wish to make life of package maintainers easier and have cargo based software easier packageable in different distros, you need to have the possibility to use the installed system libraries.

[brson]

I do not want to make cargo a dependency of the Rust build itself at this time (because complexity), though it may be possible to put std in cargo in addition to the default distribution, as we are planning on doing with some second-tier crates that rustc depends on.

[steveklabnik]

Traige: this is still desired, and there were even some PRs to start work on it, but it never landed.

[Gankra]

Upon rereading this more closely, I'm mostly only interested in the cited precursor, #16091

[steveklabnik]

Yes, I would imagine that we'd want to do it all, these days.

[emberian]

Yep