Add option to configure a test/binary runner

[jan-hudec]

Cargo can be configured to cross-compile to specific target with

[target.<triple>]
ar = "..."
linker = "..."

this correctly sets up the cross-compiler, but then when I try cargo test --target <triple>, it simply tries to run the built binaries, which for most cross-compilations won't work. However in many cases there is a way to run the tests. When cross-compiling to Windows, they can be run via wine, NaCl has it's own tools for running binaries, for Android script can be written to connect to emulator and run the tests there and so on.

So I'd like to propose adding another key in the target for running binaries. Cargo would then simply prefix commands to execute built binaries with it's content. It should probably be called run or launch and apply to all commands that run built binaries: test, bench and run.

So for example Windows would be configured as:

[target.x86_64-pc-windows-gnu]
ar = "x86_64-w64-mingw32-ar"
linker = "x86_64-w64-mingw32-gcc"
run = "wine64"

[DiamondLovesYou]

run should optionally be a Cargo package; ie a package from crates.io. Your proposal assumes the run command is a program already present on the system. In rust-ppapi's case, if I hadn't already created a hack that basically does this from within the tests themselves, the bin would add some magic to chrome's invocation as well a generate a html+nmf file to host the pexe.

(Though in my case I created a project that allows me to run PNaCl pexes just like one would run a ./bin, abeit with a ->native translation delay. Cargo doesn't notice a thing :) ).

Additionally, we may want to go the extra step and create environment configuration/profiles. For example, there are two different runtime environments for NaCl: the basic sandbox and the sandbox+ppapi (ie hosted in a webpage in chrome).

To sum up (test environment profiles tbd):

[target.le32-unknown-nacl.test-proxy]
package = "crate id thingy w/ optional version"
# or:
command = "..."

Granted this runs afoul crates.io's library only limitation.

[alexcrichton]

I'd definitely love to support something like this, but I'm not certain that the interface should be "run this program with some arguments". As @DiamondLovesYou mentions it'd also be nice to farm out this functionality to crates.io wherever possible (aka see build scripts as well!).

Right now ar and linker are exposed as they're basically just options to pass down to the compiler itself, but we should also arguably allow for more flavorful configuration of those keys as well!

[jan-hudec]

Please, don't let the perfect be the enemy of the good.

"run this program", or rather "prefix the command with this" is totally sufficient. Keep in mind this is the global configuration, not the crate one. The user must go and explicitly set it when configuring their development environment. So even if the command is provided via crate, asking the user to cargo install it is not beyond the scope of what they are doing already.

In fact:

• Extension commands are also just external binaries and all or most of them are provided by crates.
• If the command is, in fact, provided by crate, the crate could add the configuration during its installation (not sure if there is a suitable hook there already, but some "post-inst script" is useful for many things).
• Eventually even a crate pulled in as dev-dependencies could export the configuration (related to Make commands in dev-dependencies available to run #2267).

But in all cases, ultimately it will always be prefixing the executable with an interpreter. So it makes sense to do it the simple way and perhaps later add some more sugar on top.