Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to unset a default target by setting build.target to the empty string #8638

Closed
wants to merge 1 commit into from

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