Add target="host" meaning the current host

[kpreid]

Problem

Cargo defaults to compiling for the host's target triple, which is appropriate for most cases, particularly because this is the only (default) way to build tests that can be run. However, once the target has been overridden by configuration, there is no way to explicitly request on the command line that it be the host.

Proposed Solution

Wherever a target triple is accepted, accept the special string host as an alias for the host platform's target triple.

Notes

Use cases:

• Any build automation that wishes to work with different target triples can unconditionally pass a string without needing a special “absent” case.
• Library code that supports no_std, or is concerned with other platform limitations such as pointer width and atomics, could have an accompanying configuration file which automatically builds for the host, for testing, and another target, as a compatibility check; e.g. build.target = ["host", "thumbv7em-none-eabihf"].
• This could be used as cargo test --target=host to run some platform-independent tests in a package otherwise devoted to being cross-compiled (such that its config.toml has a target specified to enable IDE support and better default behaviors).
• --target=host will not be identical to the behavior with no options specified, due to the behavior differences triggered by using --target at all. This feature will introduce a way to trigger that intentionally without also needing to specify a particular target. This could be considered an alternative to target-applies-to-host = false, but specifically does not introduce any new semantics that are not currently obtainable by --target=<whatever the host triple is>.

[weihanglo]

This also looks pretty symmetric to host-config feature.

[weihanglo]

In RFC 3028 artfiact dependencies target = "host" was also mentioned:

We could specify a target = "host" value to build for the host even for [dependencies] or [dev-dependencies] which would normally default to building for the target. If any use case arises for such a dependency, we can easily add that.

[weihanglo]

Another alternative solution to this issue: A way to unsetting config value #8112

[kpreid]

Unsetting config is a good thing to have, but I don't think it significantly overlaps with this — 3/4 of the use cases I listed won't work with unsetting.

Oh, another cross-reference: #6777 was a PR that implemented essentially this idea — except that it treated --target=HOST as unsetting, which was noted as undesirable semantics, and the PR was closed basically as “guess it's not this simple”.

[bravely-beep]

I'm also running into this issue; specifically, the second bullet point use-case in the original post would be very helpful for my project.