Skip to content

Conversation

phil-opp
Copy link
Contributor

Right now it is possible to set a default compilation target through a build.target key in a .cargo/config file. Given the hierachical nature of cargo configuration files, this setting automatically applies to all subdirectories too. This is problematic if there are subdirectories with crates that should be compiled for the host architecture, such as special builder or runner crates. Unfortunately, there is currently no way to reset the default target back to the host target.

This PR fixes this problem by interpreting a build.target = "" config key as the host target. This way, subdirectories now have a way to reset the default target if required. Since the empty string was not a valid target before, this change should not break any existing code.

cc #8112

@rust-highfive
Copy link

r? @Eh2406

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 20, 2020
@ehuss
Copy link
Contributor

ehuss commented Sep 1, 2020

The Cargo team discussed this at our meeting, and we are a little uncomfortable using an empty string as an indicator to use the default, since it isn't very obvious or clear. Unfortunately I don't have any ideas for a good alternative. It could be something like "HOST", but that might be confusing since it would be distinctly different from using --target with the host platform. Related to that, I'm uncertain if Cargo will continue with the behavior where "no target specified" runs in a distinct mode (we are talking about removing or changing that notion).

@ehuss
Copy link
Contributor

ehuss commented Jan 13, 2021

Closing due to inactivity. I think something like this needs some design consideration first, and it is not really clear how it should work.

@ehuss ehuss closed this Jan 13, 2021
@phil-opp
Copy link
Contributor Author

Sorry for keeping the PR open, I completely forgot about it. The problem that this PR is trying to solve will likely go away when using a package-specific default target (implemented in #9030), so this PR is no longer relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants