I am writing integration tests for a test library. The integrations tests should run a test binary and inspect the output to ensure that the interaction between the test library and the Rust test harness is correct. To do this, I need to compile the binary which my test runs in the test harness (i.e., with the rustc flag --test) but otherwise treat it as an ordinary binary, so that the integration test can find it. The test in this binary is supposed to fail, so it should not be run as an ordinary test in cargo test.
I've tried manually running cargo rustc --bin <binary> -- --test followed by cargo test, but the latter then recompiles the binary without the --test flag, so the integration sees the binary without the test harness.
I've tried changing the binary to be a test in the manifest, but then it's placed in a hard to predict filename in target/debug/deps, so the integration test can't find it.
Ideally, there would be a way to specify in the manifest that the --test flag should always be passed to rustc when building that binary, but I don't see a way to do this in the Cargo book.
It's not clear to me what you want, exactly here? It sounds similar, but not quite the same as 3028-cargo-binary-dependencies - The Rust RFC Book which I've been wanting for forever, but doesn't seem like it's going to happen any time soon.
If you're thinking about #[cfg(test)] in the binary, I don't think that's supported in any real sense, sorry!
My best suggestion at the moment is to pop up a level and script cargo to build two regular binaries. There's some cargo plugins like cargo make that might be handy, but honestly I haven't found one I really like yet (suggestions welcome!), while I have had success by using aliases in .cargo/config.toml to define my own, local build helpers. This isn't the complete story, but hopefully it gets you a little closer!
Thanks for the suggestion. I went with a shell script which uses cargo rustc to build the test binary and its support binaries, then runs the test binary directly. I also took the integration tests out of the tests/ directory so that they wouldn't be auto-discovered by Cargo. One now has to run the shell script to execute the integration tests -- they aren't executed directly by cargo test. But it's easy enough to integrate into CI, so the solution works well enough.