Always build libraries into the same location #2919
Conversation
|
@alexcrichton: no appropriate reviewer found, use r? to override |
|
r? @brson |
Besides making the file names prettier, does this accomplish anything else? |
| let src_dir = src.parent().unwrap(); | ||
| if !src_dir.ends_with("deps") { | ||
| continue | ||
| } |
There was a problem hiding this comment.
Why would these two negative conditions exist (the continues)? Is the data bogus? Can you add a comment?
|
r=me |
Yeah whenever you build the "main crate" you don't want these hashes. For example you don't want your main binary called We can add |
alexcrichton
force-pushed
the
workspace-rebuild
branch
2 times, most recently
from
f908a52
to
05a0197
Compare
|
@bors: r=brson |
|
📌 Commit 05a0197 has been approved by |
alexcrichton
force-pushed
the
workspace-rebuild
branch
from
05a0197
to
e6d0ecb
Compare
|
@bors: r=brson e6d0ecb |
|
⌛ Testing commit e6d0ecb with merge e5ff7e9... |
|
💔 Test failed - cargo-win-msvc-64 |
alexcrichton
force-pushed
the
workspace-rebuild
branch
from
e6d0ecb
to
fa649df
Compare
|
@bors: r=brson |
|
📌 Commit fa649df has been approved by |
|
⌛ Testing commit fa649df with merge fabb42a... |
|
💔 Test failed - cargo-win-msvc-64 |
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
alexcrichton
force-pushed
the
workspace-rebuild
branch
from
fa649df
to
0863469
Compare
|
@bors: r=brson |
|
📌 Commit 0863469 has been approved by |
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
|
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
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:
depsdirectory, regardless of whetherit's a root output or not.
up one level to where they are today. This means that your binaries, dylibs,
staticlibs, etc, will all show up where they used to.
-C metadataflag is always omitted for path dependencies now. Thesedependencies 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