-
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
cdylib / staticlib libraries aren't created in the target directory when running cargo test
#8311
Comments
This makes sense. In general, there's a use case for depending on a crate that provides a We discussed this in the Cargo meeting today. I'd propose the following (sketch of a) solution:
|
Cool! A couple thoughts on your solution sketch:
I don't have any experience with cross compilation, so can't comment on the host vs target question. |
I'm experiencing this exact same problem. I want to write an integration test for a cdylib. I can guess the built file's name easily enough, but I can't figure out how to force cargo to build it before (or while) running the test. Is there any better workaround than "run cargo build before cargo test"? |
Any word on this? I'd like to be able to automate these kinds of integration tests in a cdylib crate as well (see integritychain/fips203#13) |
Problem
I'm not 100% sure this is a bug, and as an attempt to avoid an X/Y problem, I'll start by describing what I'm ultimately trying to do (which is related to #7825).
I have Rust crates with
crate-type = ["cdylib"]
orcrate-type = ["staticlib"]
(or both), and I'd like to run what are essentially integration tests written in C to ensure that my header files are correct, the libraries are built correctly, etc. And I'd really like for those tests to run when I runcargo test
.What I'm currently doing which almost works is that I have two crates: one that produces the C library and the other that exists solely to run the integration tests. The testing crate uses
cc
to build C code that calls the library produced by the "real" crate; itsbuild.rs
looks roughly like this (this example is assuming astaticlib
):There are (at least) two problems with this:
target/release
ortarget/debug
based onOUT_DIR
is pretty hacky.target/release/libreal_crate.a
isn't actually built when I runcargo test
(even if it's a dependency); only the hash-suffixed library name (target/release/deps/libreal_crate-XXXXXXXXXXXXXXX.a
) exists.The first problem is a little gross but hasn't seemed to be a big deal in practice, although I assume it's something that might change over time. The second is more problematic; a workaround is to
cargo build
beforecargo test
ing, but it's hard to remember to do that every time, and it's not ideal to have to tell everyone working on the project that that's a requirement.Steps
crate-type = ["staticlib"]
.cargo test
.Possible Solution(s)
I considered finding
target/{release,debug}/deps
viaOUT_DIR
then scanning that directory to find the library-with-suffix and linking that, but that seems even more fragile.Notes
Output of
cargo version
:cargo 1.43.0 (3532cf7 2020-03-17)
The text was updated successfully, but these errors were encountered: