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>.

Summary Notes

• accepted-target-cli-flag-and-build-target-config by weihanglo

Managed by @rustbot—see help for details

[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.

[zdivelbiss]

It seems relatively obvious that target supporting host is the way to go with this. Not only is it already mentioned in internal documentation as a potentially useful feature—there's good traction around this issue.

My specific use-case is for a project that supports multiple non-host platforms, and trying to get that to work nicely with Rust Analyzer, without breaking my xtask or the project's crates. Indeed, if I set a default target for Rust Analyzer to use (non-host for this project) that results in Rust Analyzer then miscompiling the xtask crate because it can't find an openssl version to facilitate needless cross-compilation to the non-host target. Being able to specify target = "host" in the Cargo config would solve this handily.

If this can get out of the @S-needs-design phase, or we can get some insight on what further design needs to take place, I would be willing to pick up the implementation of this feature as a first contribution to the Rust project.

Thanks.

[BartMassey]

Hard +1 for this feature. I have a mostly-bare-metal workspace that needs a few build tools compiled for the host deeper in its structure.