Unset .cargo/config key for subdirectory

[phil-opp]

Describe the problem you are trying to solve

I'm writing a crate that sets a default target through the build.target key in the .cargo/config file. I now want to create an utility crate for building the project in a subdirectory (as a replacement for a Makefile). So the file layout looks like this:

project
|  .cargo
|  |  config
|  Cargo.toml
|  src
|  | …
|  utility
|  |  Cargo.toml
|  |  src
|  |  |  main.rs

The utility sub-crate should be executed on the host system. However, since the .cargo/config file of the main project is in a parent directory, its build.target key applies to the sub-crate as well.

Unfortunately, there seems to be no platform-independent way to reset the target to the host system again. I can pass --target x86_64-unknown-linux-gnu, but that won't work on other host systems such as Windows.

Describe the solution you'd like

I can imagine different solutions to this problem:

• Provide a way to unset/remove a specific configuration key in a .cargo/config file. This way, the build.target key could be unset for the subdirectory, so that it builds for the native target again.
• Add a way to opt-out of hierarchical merging with parent files for a .cargo/config file.
• Add some kind of target alias for the host system. This way, the subdirectory could set the host system in build.target in a platform independent way. (I already proposed something like this for the --target flag in Add --target HOST alias for host target #6777.)

Notes

One example that the ability to remove configuration keys is useful in practice is the std::env::remove function of the standard library. Like for .cargo/config values, an environment variable set to the empty string "" is not equal to a variable that is not set. Therefore it makes sense to provide a way to go back to the "unset" state, which is especially useful if the variable was set by the parent program.

[epage]

As a heads up, config usually represents environment information and having a config tied to a package will only work if you only operate on the package within the subdirectory.

We have #12738 for tracking adding the missing project information that people fall back to configs.

Some things of note for this

• Tracking Issue for per-package-target #9406
• Allow specifying a set of supported target platforms in Cargo.toml #6179
• Target configuration for binaries #9208