Make Cargo aware of standard library dependencies by Ericson2314 · Pull Request #1133 · rust-lang/rfcs (original) (raw)

Ok, I talked to @alexcrichton for a long while on IRC, and then rewrite the RFC. In short, I massively elaborated the motivation, and cut phase 1. I'm respond to some his points, which will also offer some summery of what we talked about, though go to the IRC logs if you're really curious.

At a high level, could you clarify the motivation for this RFC a bit more in the text? After reading it it's not clear to me what the RFC is trying to achieve. For example:

I think that refining the motivation will help me understand more of the detailed design as well, but I'll make some specific comments below about this.

All three of those are valid motivation for this.

I'm curious where you came up with this? Cargo doesn't pass --sysroot at all.

I extrapolated incorrectly from his comments in the issue I opened long ago. It's fixed in the current RFC. The larger picture is the same either way however: Cargo allows rustc to look in the sysroot for libs.

This worries me a bit, I don't think we want the ability to swap in an alternate standard library in a super easy fashion.

I'm OK with having implicit-deps = false imply #![no_std], I just wanted to point out that technically the two features are orthogonal. The RFC now as some examples of how they can be used orthogonally, but again I don't care very much about this bit.

If you're depending on your own "standard library", then I think it should be just that, a dependency in Cargo.toml which goes through the normal crates.io + Cargo process.

I agree wholeheartedly, but this is currently not possible if crate names + target platform overlap with anything that is in the sysroot.

In general I think it's pretty brittle to swap out the std that an upstream crate is using, praying the APIs match up and the compile still succeeds.

This this can only be accomplished with a Cargo config override, which I consider sufficiently hacky. It's possible phase 1 would have allowed this to happen more accidentally, but that's outta here.

Can you clarify why you can't use Cargo for these kinds of projects today? If you use #![no_std] and don't use extern crate std, you can basically do anything with Cargo you can do with the compiler. For example I have written my own kernel which is built with Cargo and depends on rlibc from crates.io, and it all works out just fine (no standard library exists).

I wanted libcore to be cross compiled automatically, but if on some machines the host and target match (i.e. no cross compile), the build will fail. See the expanded motivation for more details.

I don't quite understand this comment because this can already be done? I can upload a crate which says #![no_std] and doesn't depend on the standard library (only libcore). Can you elaborate on how this is different and what you're thinking here?

I meant do this in a such that all deps can be (cross-)compiled automatically. See rewritten RFC and below.

Overall I think this RFC feels like it's "bolting on" features after the fact instead of creating a well-integrated and smooth system with Cargo. I believe this is also (depending on the motivation) highly inter-related with #1005, and it may wish to be considered here. I think some refinement of the motivation, however, will help guide this RFC, though!

I think I was able to explain my case on IRC. Basically @alexcrichton and I (and presumably you, dear reader, too) would like easy no-brainer cross compiling. If we don't make packages state which of libstd or its backing crates packages they need, future Cargo needs to download/build everything to play it safe, and needs to do that for ever.

By treating these things as normal deps, Cargo can do something adhoc like querying a Mozilla build farm, but can seamlessly transition to just building them like any other package if they get Cargoized. Then all that ad hoc functionality can be thrown out the window.

Finally, if you use a unstable compiler, you can cross compile your own libstd today, and it is nice to do so. While it would be great to standardize libcore, using it effectively requires a fair amount of lang items, and if those are standardized, perhaps all of libcore's implementation could to[1]. Thus, for the time being, freestanding development is probably going to require a compiler that is capable of building libcore, and it just so happens that those people benefit from that the most, so we might as well give them a way to cross compile their whole project---libcore up---today.

[1] @alexcrichton pointed out that with standardization there might be less overlap with the lang needed items to use libcore and the lang items it uses in its implementation, quite possible.