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

cargo test without cargo build won't create target/debug/libfoo.rlib while cargo build does #6131

Closed
LukasKalbertodt opened this issue Oct 4, 2018 · 8 comments
Labels
A-layout Area: target output directory layout, naming, and organization Command-test S-propose-close Status: A team member has nominated this for closing, pending further input from the team

Comments

@LukasKalbertodt
Copy link
Member

LukasKalbertodt commented Oct 4, 2018

I always expect that cargo test basically runs a cargo build before doing anything test specific. But that's apparently not the case.


Minimal example:

Cargo.toml

[package]
name = "foo"
version = "0.1.0"
authors = ["me"]
edition = "2018"

src/lib.rs

pub fn foo() {}

tests/main.rs

use foo::foo;

#[test]
fn main() {
    foo();
}

Executing cargo test will compile the foo crate and execute tests. Fine. BUT: cargo clean && cargo test won't create the file target/debug/libfoo.rlib while cargo clean && cargo build does create that file. This is very unexpected.

Tests on rustc 1.31.0-nightly (5597ee8a6 2018-10-03)

@LukasKalbertodt LukasKalbertodt changed the title cargo test without cargo build won't create target/debug/libfoo.so while cargo build does cargo test without cargo build won't create target/debug/libfoo.rlib while cargo build does Oct 4, 2018
@dwijnand
Copy link
Member

dwijnand commented Oct 4, 2018

I wonder: why is this a problem?

My thinking is, if cargo test correctly runs the tests, but in doing so doesn't create libfoo.rlib, isn't that kind of cargo's implementation details?

@LukasKalbertodt
Copy link
Member Author

Mhhh maybe?

The reason I noticed this is because I am writing my own test runners which call rustc with an --extern parameter. There I pass the path to my library (the .rlib file). So for my test runners it is important that this file exists.

Of course, maybe I shouldn't use this file as it's implementation detail. That would be fine. So far I've been using the build-plan feature to get the correct path. But I still think it's strange that cargo test doesn't run a normal cargo build beforehand. I think it's surprising and not what the user would expect.

@matthiaskrgr
Copy link
Member

Perhaps you need something like

[lib]
name = "foo"
path = "src/lib.rs"
test = true #  <-

@alexcrichton
Copy link
Member

Interesting! I don't think it's necessarily problematic that we don't do this but I don't see a great reason to not create these artifacts. Seems good to me to fix!

@ehuss
Copy link
Contributor

ehuss commented Oct 4, 2018

I think this is behaving as expected. This is a result of #5460. Because the lib is not an explicit target in this case, it is not uplifted out of deps. Previously @alexcrichton you said that you didn't think rlib should ever be uplifted, so changing that would be the opposite of the direction you previously indicated. I think in this case using the true path in deps is the correct thing to do.

@alexcrichton
Copy link
Member

Heh I do flip flop a bit. If it can be made to work without uplifting then we shouldn't implement this, but if uplifting is required then I don't think it should be too much of a problem to do so.

@epage epage added A-layout Area: target output directory layout, naming, and organization S-propose-close Status: A team member has nominated this for closing, pending further input from the team labels Oct 24, 2023
@epage
Copy link
Contributor

epage commented Oct 24, 2023

As far as I can tell, this is working as expected. cargo test is focused on building and preparing what is needed for running tests. It is not a superset of cargo build. I'm going to propose to the cargo team that we close this.

@weihanglo
Copy link
Member

Agree with closing. Thank you for the triage.

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale Oct 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-layout Area: target output directory layout, naming, and organization Command-test S-propose-close Status: A team member has nominated this for closing, pending further input from the team
Projects
Development

No branches or pull requests

7 participants