-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
add preliminary support for incremental compilation to rustbuild.py #38072
Conversation
Probably I should remove the code that dumps the rustc command line -- well, more specifically, I should make it a separate option, distinct from |
> ../configure --enable-rustbuild --local-rust-root=~/.cargo/ --enable-local-rust \ | ||
--enable-local-rebuild --enable-debug --enable-optimize | ||
|
||
# you don't have to use a build directory, I just think it's nicer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a copy-and-paste artifact.
So, I take it back, I actually am getting reuse locally. I'm experimenting more now. I also have some local fixes to make before this lands:
|
OK, this is... good to go I guess, though maybe it would be better to avoid printing the full verbose output unless the verbosity is at "level 2" or something like that. Anyway, using it locally, and running with |
Fixed the verbosity level concern in the latest commit by adding |
``` | ||
# you don't have to use a build directory, I just think it's nicer --nmatsakis | ||
> mkdir build | ||
> cd build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically rustbuild already places all of it's output in a build
directory, so this'll create build/build
. Maybe we could leave the separate directory bits to a different section of the readme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'll remove it. I just still find that it's better to have a build
directory, since it winds up with quite a lot of files in it:
> ls
build config.mk config.stamp Makefile tmp
|
||
# ok, the --enable-debug and --enable-optimize are not strictly needed, | ||
# but I recommend them personally. --nmatsakis | ||
> ../configure --enable-rustbuild --local-rust-root=~/.cargo/ --enable-local-rust \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that --local-rust-root
and --enable-local-rust
can both be elided here. At least rustbuild only takes a look at --enable-local-rust
, so the other two configuration options are ignored by rustbuild.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--local-rust-root
is certainly used, since that's how we pick which binary -- but I think if you don't supply it, we will search your path. I can add some comments about that.
@@ -63,6 +74,8 @@ impl Flags { | |||
pub fn parse(args: &[String]) -> Flags { | |||
let mut opts = Options::new(); | |||
opts.optflag("v", "verbose", "use verbose output"); | |||
opts.optflag("", "very-verbose", "use very verbose output"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally this is interpreted as -vv
, but I'm not sure if getopts has the ability to tell us about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it doesn't? I should dig a bit more I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I guess there is optflagmulti
@@ -29,6 +29,10 @@ struct Step<'a> { | |||
} | |||
|
|||
impl<'a> Step<'a> { | |||
fn noop() -> Step<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
much nicer
Hm I didn't quite see all the pieces I expected to see here. So right now if you pass |
Right. This is what I meant by this from the PR summary: 'This does NOT implement the "copy stage0 libs to stage1" optimization described in #37929, just because that seems orthogonal to me.' Note that |
@alexcrichton pushed one bug fix and tweaked README. I didn't address the problem of copying libraries over yet. |
So @alexcrichton and I had some chats over IRC and we came to some conclusions:
This would mean that building with --incremental and a recent nightly as your base compiler is by default fast:
@alexcrichton do you want to hold off on landing until I do that? doesn't seem so hard. |
On the other hand, I could just remove the check that forces |
☔ The latest upstream changes (presumably #37800) made this pull request unmergeable. Please resolve the merge conflicts. |
@nikomatsakis I'd be fine landing this ahead of time, seems like a fine optimization no matter what to unconditionally incrementally build stage0 with So in that sense, likely r=me with a rebase, but I'll take one more look. |
73eaec0
to
41a677b
Compare
@alexcrichton rebased and adjusted |
41a677b
to
d09050f
Compare
# configure to use local rust instead of downloding a beta. | ||
# `--local-rust-root` is optional here. If elided, we will | ||
# use whatever rustc we find on your PATH. | ||
> configure --enable-rustbuild --local-rust-root=~/.cargo/ --enable-local-rebuild |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha! I found out where we actually read this. Ideally we wouldn't need --local-rust-root
here because --enable-local-rebuild
should say "get from PATH by default".
Let's fix that bug later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcrichton actually, I think the configure script does fetch from path by default -- I just used --local-rust-root
because I have a different rustc
in my path that takes precedence over rustup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, but I see that bootstrap doesn't. ok.
r=me with a squash |
f4601db
to
3bfdd48
Compare
@bors r=alexcrichton |
📌 Commit 3bfdd48 has been approved by |
⌛ Testing commit 3bfdd48 with merge 5daf4b6... |
💔 Test failed - auto-linux-64-cargotest |
☔ The latest upstream changes (presumably #37817) made this pull request unmergeable. Please resolve the merge conflicts. |
For example: - we now support `-vv` to get very verbose output. - RUSTFLAGS is respected by `x.py` - better error messages for some cases
3bfdd48
to
83453bc
Compare
@bors r=acrichto |
📌 Commit 83453bc has been approved by |
⌛ Testing commit 83453bc with merge 94ae2a2... |
add preliminary support for incremental compilation to rustbuild.py This implements the integration described in #37929. It requires the use of a local nightly as your bootstrap compiler. The setup is described in `src/bootstrap/README.md`. This does NOT implement the "copy stage0 libs to stage1" optimization described in #37929, just because that seems orthogonal to me. In local testing, I do not yet see any incremental re-use when building rustc. I'm not sure why that is, more investigation needed. (For these reasons, this is not marked as fixing the relevant issue.) r? @alexcrichton -- I included one random cleanup (`Step::noop()`) that turned out to not be especially relevant. Feel free to tell me you liked it better the old way.
…e, r=nikomatsakis Correct path of incremental artifacts Per rust-lang#38072 (comment) r? @nikomatsakis
This was added in rust-lang#38072 but I can't recall why and AFAIK Cargo already handles this. This was discovered through rust-lang#42146 where passing duplicate flags was causing problems.
…rk-Simulacrum rustbuild: Remove RUSTFLAGS logic in rustc shim This was added in rust-lang#38072 but I can't recall why and AFAIK Cargo already handles this. This was discovered through rust-lang#42146 where passing duplicate flags was causing problems.
…rk-Simulacrum rustbuild: Remove RUSTFLAGS logic in rustc shim This was added in rust-lang#38072 but I can't recall why and AFAIK Cargo already handles this. This was discovered through rust-lang#42146 where passing duplicate flags was causing problems.
This implements the integration described in #37929. It requires the use of a local nightly as your bootstrap compiler. The setup is described in
src/bootstrap/README.md
.This does NOT implement the "copy stage0 libs to stage1" optimization described in #37929, just because that seems orthogonal to me.
In local testing, I do not yet see any incremental re-use when building rustc. I'm not sure why that is, more investigation needed.
(For these reasons, this is not marked as fixing the relevant issue.)
r? @alexcrichton -- I included one random cleanup (
Step::noop()
) that turned out to not be especially relevant. Feel free to tell me you liked it better the old way.