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

Stabilize target-applies-to-host feature. #9753

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jameshilliard
Copy link
Contributor

Details: #9453, #9322

@rust-highfive
Copy link

r? @alexcrichton

(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 1, 2021
@jameshilliard jameshilliard force-pushed the stabilize-target-applies-to-host branch from 0a3c506 to d5ebab6 Compare August 1, 2021 23:44
@alexcrichton
Copy link
Member

#9322 is quite sprawling and I may not have also made this clear enough, but I personally do not think that this is a candidate for stabilization until the issue fixed in #9634 is resolved. Otherwise this flag I don't believe works with cargo build since the same configuration will be used for all units.

@jameshilliard
Copy link
Contributor Author

Otherwise this flag I don't believe works with cargo build since the same configuration will be used for all units.

I think it works well enough for cross builds since the host build always ends up being used with a non-triple target directory and the target with the triple target directory, they shouldn't really conflict there at least.

@jameshilliard
Copy link
Contributor Author

FYI I've integrated the target-applies-to-host fix into the buildroot ripgrep package build using the recently released stable 1.54.0 toolchain to fix the build script failure and it seems to work fine so far, this should increase the testing coverage for this feature a good bit. I don't think #9634 is required for properly supporting this flag, however #9634 may be needed for some complex multi-target scenarios I think(buildroot does not use cargo's multi-target build capability so I don't expect we will hit issues there).

@alexcrichton
Copy link
Member

I, uh, stand by my previous comment. I don't dispute that the feature works for --target-based builds nor that it's useful for those builds. I want this fixed for cargo build before we stabilize it.

@jameshilliard
Copy link
Contributor Author

I don't dispute that the feature works for --target-based builds nor that it's useful for those builds. I want this fixed for cargo build before we stabilize it.

What issue are we hitting there? Shared dependencies conflicting?

@bors
Copy link
Collaborator

bors commented Aug 6, 2021

☔ The latest upstream changes (presumably #9613) made this pull request unmergeable. Please resolve the merge conflicts.

@jameshilliard jameshilliard force-pushed the stabilize-target-applies-to-host branch 2 times, most recently from 9c61466 to e2b82bf Compare August 20, 2021 12:29
@nitsky
Copy link

nitsky commented Nov 15, 2021

Hi, thank you to everyone here for working on this feature. What is the planned behavior for cargo build without specifying a --target? At the moment I observe that with target-applies-to-host = false, cargo build of a bin ignores both the host and target configuration. In my particular usage, the ideal behavior would be to use the host configuration not just for the build scripts and tests but for the bin as well, because I consider cargo build to be "targeting the host". Is this what is planned? Thank you!

@jameshilliard
Copy link
Contributor Author

jameshilliard commented Nov 15, 2021

What is the planned behavior for cargo build without specifying a --target?

I think it eventually was supposed to be to have the target config only to apply to target artifact builds, currently they apply to host and target builds unless target-applies-to-host = false is set.

It seems progress has stalled a bit here however since it seems nobody doing review really has all that good of an understanding of this area of the codebase.

At the moment I observe that with target-applies-to-host = false, cargo build of a bin ignores both the host and target configuration.

Are you setting both -Zhost-config and -Ztarget-applies-to-host as well? The bin should always use the target configuration either way, the host config is only ever used for host targets like build-scripts and requires the appropriate nightly flags to enable.

In my particular usage, the ideal behavior would be to use the host configuration not just for the build scripts and tests but for the bin as well, because I consider cargo build to be "targeting the host". Is this what is planned?

No, I don't think that makes much sense, the target bin should always IMO pick up its build configuration from the [target] config, even if the target is the same as the host. The purpose of the host configuration is to allow one to configure settings for the build tools(like build-script-build) for the host, it's not intended to be used to configure anything for target artifact builds(whether they will run on the build host or a different system).

@alex-berger
Copy link

Any progress on this? We rely on this feature for cross compiling and I do not feel comfortable with having to set RUSTC_BOOTSTRAP=1 to use this feature from stable Rust. That said, this feature works quite well for us so far.

@jameshilliard
Copy link
Contributor Author

I do not feel comfortable with having to set RUSTC_BOOTSTRAP=1 to use this feature from stable Rust.

IMO setting __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS is probably safer, since it's only picked up/used in essentially one place(which is sufficient to enable this one nightly only feature we need) while RUSTC_BOOTSTRAP=1 is getting used in other places including in rustc.

This seems to have fixed things for us:
https://github.com/buildroot/buildroot/blob/ac573c55aac3cbb4257f5388c91321c81095c654/package/pkg-cargo.mk#L26-L50

Be aware that hacks to enable nightly features like this are likely to break, we can manage this easily since we pin our rust toolchain versions(we do this with our non-rust toolchains as well to various degrees) and have auto-builders that would likely catch any related regressions quickly, we just really don't want to be pinning rust/cargo toolchains to nightly toolchains since we really only want to enable stable features(this one is just not really optional in practice as even basic x86_64 cross compilation breaks without it).

@saurik
Copy link

saurik commented Jan 27, 2022

FWIW, I also ran out of workarounds a month ago after I wanted to upgrade something (either Rust/Cargo or one of the couple Rust libraries I still haven't ported away from... I don't remember the situation, but it involved yet another place where flags were being incorrectly applied to the wrong part of the build process) and have been able to switch to this feature and it is working great (and I will note that even using __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS this is way more stable and less likely to break than all of my prior hacks that were required to make Rust even semi-usable for serious compilation; I also, though, have somewhat controlled toolchain versions). OrchidTechnologies/orchid@3ced403

@bors
Copy link
Collaborator

bors commented Feb 28, 2022

☔ The latest upstream changes (presumably #10395) made this pull request unmergeable. Please resolve the merge conflicts.

@jameshilliard jameshilliard force-pushed the stabilize-target-applies-to-host branch 3 times, most recently from c3f3ef8 to a5f2401 Compare March 1, 2022 08:28
@jameshilliard
Copy link
Contributor Author

rebased

@alexcrichton
Copy link
Member

Thanks for the PR, but I'm going to be stepping down from the Cargo team so I'm going to un-assign myself from this. The Cargo team will help review this when they get a chance.

@alexcrichton alexcrichton removed their assignment Mar 8, 2022
@bors
Copy link
Collaborator

bors commented Jul 16, 2022

☔ The latest upstream changes (presumably #10868) made this pull request unmergeable. Please resolve the merge conflicts.

@jameshilliard jameshilliard force-pushed the stabilize-target-applies-to-host branch from a5f2401 to 0cc2206 Compare October 21, 2022 16:52
@jameshilliard
Copy link
Contributor Author

rebased

@jameshilliard jameshilliard force-pushed the stabilize-target-applies-to-host branch from 0cc2206 to 3c7652c Compare December 3, 2022 22:10
@jameshilliard
Copy link
Contributor Author

@joshtriplett Does this look good to merge?

It would be nice if cross compilation build systems could drop hacks like __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS="nightly".

Having unstable env variables as a hard requirement for a functional cross compilation environment isn't exactly ideal.

@bors
Copy link
Collaborator

bors commented Feb 20, 2024

☔ The latest upstream changes (presumably #13409) made this pull request unmergeable. Please resolve the merge conflicts.

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.

None yet

7 participants