-
Notifications
You must be signed in to change notification settings - Fork 2.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
Crate in workspace doesn't rebuild against changed dependency, if said dependency was already built within the workspace #2855
Comments
Oh dear, sounds bad! I'll take a look |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Jul 27, 2016
Previously Cargo would compile a library into a different location depending on whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's reliance on the idea of a "root crate" this PR is the next step. With workspaces the root crate of a compliation changes all the time, so the output needs to be the same whether a crate is at the root or not. Fixing this inconsistence in turn fixes bugs like rust-lang#2855 and rust-lang#2897 which arise due to this discrepancy. Additionally, Cargo will no longer recompile a library when it's used as a "root crate" or not. This is fixed by taking a few steps: * Everything is now compiled into the `deps` directory, regardless of whether it's a root output or not. * If a "root crate" is being compiled, then the relevant outputs are hard-linked up one level to where they are today. This means that your binaries, dylibs, staticlibs, etc, will all show up where they used to. * The `-C metadata` flag is always omitted for path dependencies now. These dependencies are always path dependencies and already all have unique crate names. Additionally, they're the only crates in the DAG without metadata, so there's no need to provide additional metadata. This in turn means that none of the file names of the generated crates are mangled. Closes rust-lang#2855
bors
added a commit
that referenced
this issue
Jul 27, 2016
Always build libraries into the same location Previously Cargo would compile a library into a different location depending on whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's reliance on the idea of a "root crate" this PR is the next step. With workspaces the root crate of a compliation changes all the time, so the output needs to be the same whether a crate is at the root or not. Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise due to this discrepancy. Additionally, Cargo will no longer recompile a library when it's used as a "root crate" or not. This is fixed by taking a few steps: * Everything is now compiled into the `deps` directory, regardless of whether it's a root output or not. * If a "root crate" is being compiled, then the relevant outputs are hard-linked up one level to where they are today. This means that your binaries, dylibs, staticlibs, etc, will all show up where they used to. * The `-C metadata` flag is always omitted for path dependencies now. These dependencies are always path dependencies and already all have unique crate names. Additionally, they're the only crates in the DAG without metadata, so there's no need to provide additional metadata. This in turn means that none of the file names of the generated crates are mangled. Closes #2855
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have the following project:
Cargo.toml
:mylib/Cargo.toml
:mylib/src/lib.rs
:myapp/Cargo.toml
:myapp/src/main.rs
:First, let's just run myapp:
Now we replace "Hello" with "Hey" in mylib:
Let's test the changes:
Now let's run myapp again:
Wait, what? I'm pretty sure I changed "Hello" to "Hey".
The text was updated successfully, but these errors were encountered: