Skip to content

Spurious rebuilds #1567

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.

Sign up for GitHub

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

Jump to bottom
Closed
gkoz opened this issue Apr 30, 2015 · 4 comments · Fixed by #1577
Closed

Spurious rebuilds #1567

gkoz opened this issue Apr 30, 2015 · 4 comments · Fixed by #1577

Comments

@gkoz
Copy link
Contributor

gkoz commented Apr 30, 2015

I'm encountering non-deterministic spurious rebuilds of already built dependencies when building this crate: https://github.com/rust-gnome/examples
The fingerprint traces: clean build, a rebuild a minute later that should've been a noop.
Contrary to what I said on the IRC, the behaviour doesn't require any path overrides, this was a vanilla checkout.
@gkoz
Copy link
Contributor Author

gkoz commented Apr 30, 2015

@larsbergstrom might've been having the same issue with servo.

@alexcrichton
Copy link
Member

It looks like that project has a ton of C dependencies (that I can't seem to figure out how to install), so could you elaborate a little more on how you generated the clean build and how you generated the rebuild?

@gkoz
Copy link
Contributor Author

gkoz commented May 1, 2015

Oh, sorry about the dependencies :( They're covered here: https://github.com/rust-gnome/gtk/blob/master/README.md (in a nutshell just install glib-dev and gtk3-dev and also XQuarz if on OSX).
The first log is from cargo build after doing cargo clean so it had to build everything. The second log is from doing cargo build again when it shouldn't have built anything at all.

@alexcrichton
Copy link
Member

Awesome, thanks for the pointer to the README @gkoz! I have reproduce and found the bug now, should have a fix soon!

alexcrichton added a commit to alexcrichton/cargo that referenced this issue May 5, 2015
@alexcrichton
Check default features when skipping resolution of a package
40d1c10 
Previously if a package had been activated without the default feature and then
it was attempted to be reactivated with the default feature, resolution wouldn't
continue and actually activate the default feature. This means that the
fingerprint on the other end of compilation would be slightly different because
the set of activated features would be slightly different, causing spurious
recompiles.

Closes rust-lang#1567
@alexcrichton alexcrichton mentioned this issue May 5, 2015
Merged
bors added a commit that referenced this issue May 5, 2015
@bors
Auto merge of #1577 - alexcrichton:issue-1567, r=brson
9cd0d35 
Previously if a package had been activated without the default feature and then
it was attempted to be reactivated with the default feature, resolution wouldn't
continue and actually activate the default feature. This means that the
fingerprint on the other end of compilation would be slightly different because
the set of activated features would be slightly different, causing spurious
recompiles.

Closes #1567
@bors bors closed this as completed in #1577 May 5, 2015
@gustavla gustavla mentioned this issue Jun 15, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Check default features when skipping resolution of a package alexcrichton/cargo
2 participants
@alexcrichton @gkoz