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

add Build::apple_deployment_target function #938

Closed
wants to merge 1 commit into from

Conversation

Be-ing
Copy link
Contributor

@Be-ing Be-ing commented Jan 30, 2024

flag_if_supported doesn't work for this because try_get_compiler adds the Apple deployment target argument before flags_supported is processed, so users can only append a second -mmacosx-version-min flag via flag_if_supported. To work around this, add a function specifically for this purpose.

flag_if_supported doesn't work for this because try_get_compiler
adds the Apple deployment target argument before flags_supported is
processed, so users can only append a second -mmacosx-version-min
flag via flag_if_supported. To work around this, add a function
specifically for this purpose.
@@ -3321,7 +3333,7 @@ impl Build {
Ok(ret)
}

fn apple_deployment_version(
fn get_apple_deployment_target(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we change the return type to Cow<'_, str> to avoid cloning str?

@NobodyXu
Copy link
Collaborator

This seems like related to #902

@NobodyXu
Copy link
Collaborator

NobodyXu commented Feb 4, 2024

cc @Be-ing if you don't mind it, I can update the PR for you.

@Be-ing Be-ing marked this pull request as draft February 4, 2024 22:03
@Be-ing
Copy link
Contributor Author

Be-ing commented Feb 4, 2024

I did some more testing, and the existing flag_if_supported API does work. I am not sure exactly how the CLI arguments are handled by clang. When -mmacosx-version-min is passed twice (first time automatically by cc, second time by user-specified flag_if_supported), it seems to either prefer the second argument or the higher specified version. It might still be a good idea to add this API though because that behavior of clang is not documented and I don't know if it can be relied on long term. Thoughts?

@NobodyXu
Copy link
Collaborator

NobodyXu commented Feb 4, 2024

IMO it's better to add this API, not just due to the order of cmdline arg, but cc-rs seems to have different behavior based on apple deployment target version and build target.

@Be-ing
Copy link
Contributor Author

Be-ing commented Feb 5, 2024

cc-rs seems to have different behavior based on apple deployment target version and build target

Yes, but that can be addressed using the existing flag_if_supported API, so should we add a new API?

@NobodyXu
Copy link
Collaborator

NobodyXu commented Feb 5, 2024

If that can be reliably solved by flag_if_supported() on all compilers, then it is indeed unnecessary.

But I'm not sure if it would work on gcc or msvc.

.or_else(|| rustc_provided_target(rustc, target))
.map(maybe_cpp_version_baseline)
.unwrap_or_else(|| OLD_IOS_MINIMUM_VERSION.into()),

AppleOs::WatchOs => deployment_from_env("WATCHOS_DEPLOYMENT_TARGET")
AppleOs::WatchOs => deployment_from_env("_DEPLOYMENT_TARGET")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like an error maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, yeah that was an accident

@Be-ing
Copy link
Contributor Author

Be-ing commented Feb 12, 2024

I don't think this is needed anymore with #943. If someone wants a lower deployment target than the SDK default, they can set the MACOSX_DEPLOYMENT_TARGET environment variable.

@Be-ing Be-ing closed this Feb 12, 2024
@BlackHoleFox
Copy link
Contributor

@Be-ing On the contrary I think this should still be added. MACOSX_DEPLOYMENT_TARGET only works if you either set it outside of the process in a Makefile, cargo env config, etc or use std::env::set_var at runtime inside build.rs.

That last option is the only programmatic way to do it and manipulating the process' environment variables is an uh, dicey area. Having a proper library API to control this for each target would be nice imo.

@Be-ing
Copy link
Contributor Author

Be-ing commented Feb 13, 2024

Now that the old behavior of defaulting to the SDK's default deployment target has been restored, what is the need for this API? The default is a recent deployment target, so old code builds fine. A crate specifying a lower minimum than the default wouldn't really change anything.

@BlackHoleFox
Copy link
Contributor

A crate specifying a lower minimum than the default wouldn't really change anything.

What do you mean?

@Be-ing
Copy link
Contributor Author

Be-ing commented Feb 14, 2024

If a crate specifies a lower deployment target than the default, it's effectively superfluous because it would have built anyway. Only if every crate in the dependency graph that uses cc specifies the same lower deployment target will the resulting binary actually be usable on the lower deployment target. That's best achieved via the environment variable because that effects every crate that uses cc.

@BlackHoleFox
Copy link
Contributor

Seems like a reasonable take, the well-stated counter-argument is appreciated :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants