Always set MACOSX_DEPLOYMENT_TARGET in build scripts

[madsmtm]

Problem

The environment variables MACOSX_DEPLOYMENT_TARGET, IPHONEOS_DEPLOYMENT_TARGET, TVOS_DEPLOYMENT_TARGET and WATCHOS_DEPLOYMENT_TARGET are standard environment variables on Apple targets, and are used by compilers to get the desired minimum supported operating system version.

When not specified, compilers usually choose some default. The default that rustc chooses can be retrieved with rustc --target x86_64-apple-darwin --print deployment-target, and e.g. the cc crate has support for detecting this, and passing it on to a C compiler.

The problem(s) is that:

• This kind of logic that cc has, has to be implemented by every build.rs script that wants to call an external compiler.
• Spawning a new rustc process to determine this is inefficient (although probably negligible).
• It is not really discoverable for users. (IMO the most important)

Proposed Solution

Cargo always sets these in build scripts when building for the relevant Apple targets.

That is, it sets MACOSX_DEPLOYMENT_TARGET when building for macOS, IPHONEOS_DEPLOYMENT_TARGET when building for iOS, and so on.

As an example, as an author of a build.rs script, I would like to be able to do the following (once a version of Cargo that supports this is in my MSRV):

if std::env::var("TARGET").unwrap() == "x86_64-apple-darwin" {
    // Note that I'm allowed to `unwrap` here because Cargo always sets it for this target.
    let deployment_target = std::env::var("MACOSX_DEPLOYMENT_TARGET").unwrap();
    // ...
}

(Note: In contrast to all other environment variables that Cargo sets for build scripts, these are explicitly target dependent).

Notes

CC @BlackHoleFox whom implemented the rustc --print deployment-target flag.

I'd volunteer to do the implementation work if this feature is desired?

[ehuss]

Can you say why this would not be handled in rustc? Generally we try to avoid having cargo have explicit target knowledge. Fixing this in rustc is tracked in rust-lang/rust#118204.

[madsmtm]

Hmm, that issue is only tangentially related: this is about setting MACOSX_DEPLOYMENT_TARGET when running the build script, which is something that only Cargo can do, since it's an input to the build script.

[ehuss]

Ah, thanks for the clarification, I misunderstood.

[BlackHoleFox]

So one thing that concerns me about doing this (though I know it would be extremely helpful) is compatibility. As cc has seen, most people don't actually set their deployment target variables and instead rely on the active SDK's DefaultDeploymentTarget. As a result, @thomcc and I have been thinking about removing the --print sourcing from cc and relying on the SDK instead to avoid widespread breakage. That's not very ontopic for this issue though so I digress.

Since subprocess C compilers would inherit variables and that rustc's --print deployment-target is assumed always lower then the SDK's default (what clang uses if you don't specify MACOSX_DEPLOYMENT_TARGET), I get the fear this is going to break people's builds.

[madsmtm]

Yeah, that's a reasonable fear.

I would argue that most of those users would benefit from this, as they'd get to realize that their build doesn't actually work on older macOS versions, and that they need to either do more work to support that, or explicitly raise their supported version.

Though without something like rust-lang/rfcs#3379, it will be kinda hard to know what to tell users to do, even if we do the breakage across an edition.

[madsmtm]

cc went with using the current platform SDK's DefaultDeploymentTarget, see rust-lang/cc-rs#943.

So perhaps that's also a viable option for Cargo? This wouldn't have the same backwards compatibility issues, and I think it would provide a step forwards for better Cargo integration with deployment targets.

[weihanglo]

This might also be a good candidate for the build scipt API: #12432.

[ehuss]

The cargo team discussed this today, but did not come to a specific conclusion. We had some reticence to including this directly in cargo for a few reasons. One is that maintaining target-specific support in cargo is something we've generally tried to avoid, and this seems like something that would be a challenge. We also noted that updating this logic is difficult to do in cargo due to release timing, and inability to change for older toolchains (whereas a crate can be updated at any time). We also weren't enthusiastic about having cc creep into cargo, as there isn't a clear stopping point.

For now I think we would prefer to keep this in a separate crate, whether it is cc, one of the build-script specific crates like our own build-rs (or maybe an extension crate to that), or a separate dedicated crate, we don't know.

[madsmtm]

Thanks for discussing it! In any case, I think we should wait 'till after rust-lang/rust#136113 has been fixed, since cc-rs and cmake-rs are by far the largest crates that'd be affected by such a change.

Let's see if I can mark this:
@rustbot blocked

maintaining target-specific support in cargo is something we've generally tried to avoid
updating this logic is difficult to do in cargo due to release timing

In terms of implementation, the way I'd want Cargo to do it would be without depending on target-specific information; instead, we'd update the TargetInfo stuff it already does today to also request something like rustc --target $TARGET --print=build-script-env-vars, which would then output the extra *_DEPLOYMENT_TARGET environment variables that rustc deems necessary for the given target.

(Or, if a little dependence on target tuples are acceptable, it could be implemented today without changes in rustc, by invoking rustc --target $TARGET --print=deployment-target, but only when the target name contains the substring "apple").

[rustbot]

Error: The "Blocked" shortcut only works on pull requests.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[epage]

Something else that was left off is that by pushing this to Cargo, it has to be run if build scripts are present, even if they don't use it. We do have caching though which helps.

We also noted that updating this logic is difficult to do in cargo due to release timing, and inability to change for older toolchains (whereas a crate can be updated at any time).

Part of our thought with this was about decoupling the update schedule of Cargo from Apple. However, it appears that even the *_DEPLOYMENT_TARGET variables are known within rustc, not just the versions
https://github.com/rust-lang/rust/blob/f85c6de55206dbee5ffedfd821df1503a7b92346/compiler/rustc_codegen_ssa/src/back/apple.rs#L101-L108

`rustc --target $TARGET --print=build-script-env-vars, which would then output the extra *_DEPLOYMENT_TARGET environment variables that rustc deems necessary for the given target.

That is a bit cargo-specific to be included in rustc.