Warning when specifying the output name with cargo rustc

[kamulos]

Problem
When using the -o option with cargo rustc I get a warning. I do not know what I have should do to fix the warning or if there is a better way to achieve what I am doing.

This is the warning:

warning: due to multiple output types requested, the explicitly specified output file name will be adapted for each output type
warning: ignoring --out-dir flag due to -o flag

Steps

cargo rustc -- -o myoutput

Notes

Output of cargo version:

cargo 1.52.0 (69767412a 2021-04-21)

[Bryysen]

I think when only doing cargo rustc, cargo automatically passes --out-dir target/debug to rustc, so when you additionally specify -o myoutput rustc has to choose between one of the paths. In the end it uses -o myoutput, the warning is just letting you know that the output file will only be written to myoutput in this case. The normal workflow (to avoid this warning) is to only cargo rustc or cargo build, and call the binary inside target/debug or target/release. This way cargo can neatly organize the build artifacts for you all in one place.

[kamulos]

I want to build the binaries for unittests and have them in a specific location to run at a later point. Specifying the output name -o gives me a little bit of control how I can find the correct binary afterwards. But it still appends a hash, which can lead to multiple unittest binaries for the same crate in one directory. My solution is to clean the directory before building and using find my/dir -executable -name "$package-*" to find the binary for a crate.

[Bryysen]

I see, that makes sense. Although i'm curious why not run the unit tests by doing cargo test [test_name]? Sorry if i'm being ignorant or missing something.

[kamulos]

Determining the coverage of unit-tests with -Zinstrument-coverage. I might be doing it wrong, but this is my solution for it.

I don't remember all the details but there were quite a few hurdles to get proper numbers. I think one of the problems that occurred was that the build script was included in the coverage measurements when just executing the test directly. Another issue was that I only wanted to instrument my own crate and not all the dependencies. If I recall correctly this is possible with cargo rustc

[Bryysen]

I see, i think i'm following now. I think the the way you're doing it is quite reasonable. I don't have any experience with instrument coverage myself, but i found some information that may be useful to you? There is some general usage documentation in the unstable book (there is an example for specifically what you are trying to do), also of interest is this attribute that allows you finer grained control of what gets included in the coverage. Hope this helps

[ehuss]

For now, there isn't a great way to have well known path to the test executable (see #3670). One way is with JSON, which tells you the path. For coverage, it might be best to develop a wrapper (something like the older cargo cov) which can use the JSON interface to orchestrate everything.

Otherwise, there isn't a specific way to tell cargo to place the output somewhere else. I think the warnings could be ignored, though using low-level flags like -o is going to have some conflicts with how cargo runs.