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

Crate in workspace doesn't rebuild against changed dependency, if said dependency was already built within the workspace #2855

Closed
crumblingstatue opened this issue Jul 11, 2016 · 1 comment · Fixed by #2919

Comments

@crumblingstatue
Copy link

We have the following project:

Cargo.toml:

[workspace]
members = ["myapp", "mylib"]

mylib/Cargo.toml:

[package]
name = "mylib"
version = "0.1.0"

mylib/src/lib.rs:

pub fn gimme_string() -> &'static str {
    "Hello"
}

#[test]
fn test() {
    assert_eq!(gimme_string(), "Hello");
}

myapp/Cargo.toml:

[package]
name = "myapp"
version = "0.1.0"

[dependencies.mylib]
path = "../mylib"

myapp/src/main.rs:

extern crate mylib;

fn main() {
    println!("{}", mylib::gimme_string());
}

First, let's just run myapp:

[myapp]$ cargo run
   Compiling mylib v0.1.0 (file:///tmp/ws/mylib)
   Compiling myapp v0.1.0 (file:///tmp/ws/myapp)
     Running `/tmp/ws/target/debug/myapp`
Hello

Now we replace "Hello" with "Hey" in mylib:

pub fn gimme_string() -> &'static str {
    "Hey"
}

#[test]
fn test() {
    assert_eq!(gimme_string(), "Hey");
}

Let's test the changes:

[mylib]$ cargo test
   Compiling mylib v0.1.0 (file:///tmp/ws/mylib)
     Running /tmp/ws/target/debug/mylib-f6404eab34ef39c8

running 1 test
test test ... ok
...

Now let's run myapp again:

[myapp]$ cargo run
   Compiling myapp v0.1.0 (file:///tmp/ws/myapp)
     Running `/tmp/ws/target/debug/myapp`
Hello

Wait, what? I'm pretty sure I changed "Hello" to "Hey".

@alexcrichton
Copy link
Member

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants