Open jgallagher-cs opened 4 years ago
This makes sense. In general, there's a use case for depending on a crate that provides a cdylib
, a staticlib
, or even a bin
, and then being able to use the resulting artifact at build time.
We discussed this in the Cargo meeting today.
I'd propose the following (sketch of a) solution:
Cargo.toml
should allow specifying dependencies (or build dependencies, or dev dependencies) on a staticlib
or cdylib
or bin
.
CARGO_DEP_<depname>_BIN
, CARGO_DEP_<depname>_STATICLIB
, or CARGO_DEP_<depname>_CDYLIB
.Cool! A couple thoughts on your solution sketch:
cdylib
or staticlib
if those aren't in the dependency's crate-type
, right?bin
s but what if the dependency has more than one?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 https://github.com/integritychain/fips203/pull/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 (3532cf738 2020-03-17)