Different default targets for `cargo build` and `cargo test`?

[phil-opp]

Describe the problem you are trying to solve

Cargo currently provides a build.target configuration key that allows to change the default target triple. This changes the default target for all cargo commands, including cargo build, cargo run, cargo test and cargo bench. For embedded/OS crates it often makes sense to set that key so that the project is automatically built for the bare-metal target system instead of the host system.

The problem is that one might still want to run the cargo test and cargo bench commands on the host architecture because they depend on std (and thus don't work on the embedded target). Currently the only way to do this is to specify the full host triple on each cargo test invocation, which is not portable across different host systems.

Describe the solution you'd like

It would be nice if there would be an additional build.build-target configuration key that overrides the target only for cargo build, cargo check, and cargo run, but not for cargo test and cargo bench.

Notes

I'm happy to create a PR for this if something like this is desired.

[fluffysquirrels]

In case it helps, I personally solved this issue for embedded development with shell scripts or make files for each scenario, so one for running tests on the host, one for flashing the microcontroller, and so on.

[phil-opp]

Thanks for the suggestion! I want to avoid Makefiles and external scripts when possible, since they are not really portable across OSs. However, I found a different solution to my problem in the custom test framework feature, which allows me to run my tests on the target system.

If nobody else is interested in this issue I will close it in a week.

[SomeoneToIgnore]

Not sure if it helps you to find the motivation to submit the actual PR, but I totally agree that this feature is nice to have.
I think at least reopening the issue would be a good thing to do.

[phil-opp]

@SomeoneToIgnore As noted above, I found a better solution to my problem and I don't have the time for implementing a solution to this problem at the moment. However, I already opened a draft PR at #6825, which might be useful if someone wants to implement it (but please consider the review comments in the PR thread).

I'm happy to reopen this issue, though!

[torkeldanielsson]

I would very much like this feature! My target is severely memory constrained so running tests on it is not such a nice proposition.

[josephlr]

We would also find this useful for https://github.com/cloud-hypervisor/rust-hypervisor-firmware.

We want our firmware to be built with one target, and then for our integration tests to be built for the host target.