Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for custom target-specific runners #3954
This allows to run tests when cross-comping Rust projects.
This is not a complete solution and might be extended in future for better ergonomics to support passing extra arguments to the runner itself or overriding runner from the command line, but it should already unlock major existing use cases.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.
referenced this pull request
Apr 26, 2017
Looks good to me! I'm ok punting on CLI support for now, but I do think that we'll eventually add it (it's more ergonomic for the gdb/strace use case).
I wonder though if we can perhaps soup up the configuration here, where a change may otherwise be backwards incompatible. For example:
That way we can support passing arguments, doing so in an ergonomic fashion for easy cases, and then also supporting the fully general case.
Ah sorry meant to respond sooner. My intention is that we interepret strings as space-separated lists of arguments, so the interpretation today (just an opaque name for a binary) would be backwards incompatible with the space-separated interpretation. For example
runner = 'C:\Program Files\nodejs\bin\node'
Today that'd be valid but if we started interpreting spaces as separators it'd break. Instead that'd ideally be specified as:
runner = ['C:\Program Files\nodejs\bin\node']
@alexcrichton Ah yeah. I just thought - if we don't add support for space-separated arguments, then
could be valid now and
could be added later without breaking backward compatibility (basically supporting two syntaxes).
Anyway, yeah, adding arguments should be quite trivial - I'll try to do that soon.