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

Dependency in workspace not recompiled after compiler version change #2897

Closed
euclio opened this issue Jul 19, 2016 · 4 comments
Closed

Dependency in workspace not recompiled after compiler version change #2897

euclio opened this issue Jul 19, 2016 · 4 comments

Comments

@euclio
Copy link
Contributor

euclio commented Jul 19, 2016

Steps to reproduce

  1. Create a new crate.
  2. Inside that crate, create another crate. This crate should be both a path dependency and a workspace member of the root crate.
  3. Compile both crates.
  4. Change your compiler version (using rustup, etc.)
  5. Compile the member crate.
  6. Compile the root crate.

You should get an error found crate "member" compiled by an incompatible version of rustc.

Expected behavior

The dependency is recompiled using the new compiler.

You can see this error happening in the rust-rosetta CI here. It seems that the artifacts in the cache were compiled with an older nightly, so the compilation failed.

@IvanUkhov
Copy link
Contributor

IvanUkhov commented Jul 23, 2016

I’ve experienced a similar problem. After updating the compiler, I tried to run the tests in the nested crate, and I got the following error:

error: found crate `foo` compiled by an incompatible version of rustc [E0514]
help: please recompile that crate using this compiler (rustc 1.12.0-nightly (936bfea94 2016-07-20))

I believe it should have been automatically recompiled.

@alexcrichton
Copy link
Member

Thanks for the report! After investigating I've concluded that this is a dupe of #2897, so I'm going to close in favor of that.

@euclio
Copy link
Contributor Author

euclio commented Jul 25, 2016

@alexcrichton looks like you linked back to this issue 😄 what is the dupe number?

@alexcrichton
Copy link
Member

Gah sorry about that! I meant to link to #2855

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

No branches or pull requests

3 participants