-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
bootstrap: artifacts are not moved to build/:target/stage1 on x.py build --stage 0
#73519
Comments
The part of |
This does not fix the issue and I'm not sure why:
|
It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.
|
So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build |
Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could). I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense. |
Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution ( |
- Set rustc to build only when explicitly asked for This allows building the stage2 rustc artifacts, which nothing depends on. Previously the behavior was as follows (where stageN <-> stage(N-1) artifacts, except for stage0 libstd): - `x.py build --stage 0`: - stage0 libstd - stage1 rustc (but without putting rustc in stage0/) This leaves you without any rustc at all except for the beta compiler (rust-lang#73519). This is never what you want. - `x.py build --stage 1`: - stage0 libstd - stage1 rustc - stage1 libstd - stage1 rustdoc - stage2 rustc This leaves you with a broken stage2 rustc which doesn't even have libcore and is effectively useless. Additionally, it compiles rustc twice, which is not normally what you want. - `x.py build --stage 2`: - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 rustdoc and tools This builds all tools in release mode. This is the correct usage for CI, but takes far to long for development. Now the behavior is as follows: - `x.py build --stage 0`: - stage0 libstd This is suitable for contributors only working on the standard library, as it means rustc never has to be compiled. - `x.py build --stage 1`: - stage0 libstd - stage1 rustc - stage1 libstd - stage1 rustdoc This is suitable for contributors working on the compiler. It ensures that you have a working rustc and libstd without having to pass `src/libstd` in addition. - `x.py build --stage 2`: - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 libstd - stage2 rustdoc This is suitable for debugging errors which only appear with the stage2 compiler. - `x.py build --stage 2 src/libstd src/rustc` - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 libstd - stage2 rustdoc, tools, etc. - stage2 rustc artifacts ('stage3') This is suitable for CI, which wants all tools in release mode. However, most of the use cases for this should use `x.py dist` instead, which builds all the tools without each having to be named individually.
Once this is fixed, the docs for |
…ulacrum Assemble the compiler when running `x.py build` Previously, there was no way to actually get binaries in `build/$TARGET/stage1/bin` without building the standard library. This makes it possible to build just the compiler. This can be useful when the standard library isn't actually necessary for trying out your tests (e.g. a bug that can be reproduced with only a `no_core` crate). Closes rust-lang#73519.
I've lost so much of my life to this.
It looks like the critical missing line is
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
. I would expect this to happen whenever I passbuild --stage 0
.The text was updated successfully, but these errors were encountered: