Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support building sysroot on stable/beta #53

Closed
wants to merge 1 commit into from

Conversation

upsuper
Copy link

@upsuper upsuper commented Jan 21, 2020

RUSTC_BOOTSTRAP=1 is what the Rust itself uses to build itself (because otherwise it wouldn't build on any channel other than nightly).

The justification that std can use unstable features is that it's always bundled with rustc, and whenever an unstable feature changes, std would be updated at the same time.

Since for sysroot we are literally building src from Rust, I think the same justification applies as well.

@phil-opp
Copy link
Member

I don't think that it's a good idea to set the unstable RUSTC_BOOTSTRAP environment variable because it is an implementation detail and might change at any time. By setting it automatically, users might think that their project is stable since it builds with a stable compiler. However, any change to the bootstrap process and the unstable environment variable can cause the project to fail.

I would be fine if the user themselves needs to set the RUSTC_BOOTSTRAP environment variable. So maybe we can check for the variable when a stable/beta toolchain is used and display only a warning instead of a "switch to nightly" error message. This way, users that really want to build the sysroot with a stable compiler can set the environment variable (hopefully after learning about its unstability), but there is no danger that someone accidentally thinks that their project builds on stable.

What do you think?

@upsuper
Copy link
Author

upsuper commented Jan 21, 2020

It's not more unstable than any unstable features, but yeah I agree that making users think they are using stable might not be a good idea.

I don't think this flag is going away in foreseeable future, and even if it does, there would likely be a replacement mechanism, as rustc would always need some mechanism to compile its std full of unstable features, and I would argue that it's unlikely to be too hard to embrace such new mechanism if there would ever be.

And hopefully it can give you more relief that, Firefox is also relying on this flag.

So although I agree that conceptually this is unstable, and rustc provides no guarantee that it will exist and work the same way forever, I would suggest that in practice this may not really be a problem.

But to be honest, I'm fine either way, so feel free to close it if you are not comfortable with this. For what I'm doing, nightly is still required for other dependencies anyway. I'm just hoping that we can move towards an all-stable world :)

@phil-opp
Copy link
Member

phil-opp commented Jan 22, 2020

I agree that the flag likely won't go away anytime soon. However, I still think that setting the flag automatically is not a good idea.

Some related discussion I found: rust-lang/cargo#7088. This is a bit different than what we do here, but the general recommendation seems to be that RUSTC_BOOTSTRAP should be avoided in third-party crates.

I'm open to make this project work with RUSTC_BOOTSTRAP, as long as the users set it themselves.

I'm just hoping that we can move towards an all-stable world :)

Me too! :)

@phil-opp
Copy link
Member

Someone just proposed the same thing for the xargo project: japaric#275. The maintainer is also opposed to setting the RUSTC_BOOTSTRAP flag automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants