use MACOSX_DEPLOYMENT_TARGET when set

[youknowone]

10.4 for c and 10.9 for c++

10.7 for x86 and 11.0 for aarch64.

ref: https://github.com/rust-lang/rust/blob/6365e5ad9fa9e2ec867a67aeeae414e7c62d8354/compiler/rustc_target/src/spec/apple_base.rs#L105-L114
which referred in #703 (comment)

[youknowone]

@Mark-Simulacrum Hi, you seem to maintained this repository recently. Could you review this PR?

[thomcc]

This makes a lot of other changes. Can you remove those (perhaps put them in a different PR)?

I think it's reasonable to take advantage of MACOSX_DEPLOYMENT_TARGET, but I don't think we should default to setting this to something old. I'd actually probably prefer we don't set it if not provided.

Alternatively, we could mirror the logic used by rustc_target, but I'd probably lean on not passing this if it is not set.

Also sorry for the delay here, this crate should be better maintained going forward.

[thomcc]

Oh, I see, the other changes are from #703, which I hadn't seen yet.

[youknowone]

I did it by respecting the policy for other platforms like IPHONEOS. if you want to make different policy for macos, I will change it. Please confirm you want it.

I think it's reasonable to take advantage of MACOSX_DEPLOYMENT_TARGET, but I don't think we should default to setting this to something old. I'd actually probably prefer we don't set it if not provided.

[youknowone]

@thomcc could you review it again?

[colincornaby]

I'm still getting familiar with this project so apologies if I'm misreading something.

On line 2246, Bitcode is enabled if the platform is not Mac.

• This means Bitcode is also enabled for other places where it should not be (by my reading.) iOS Simulator and Catalyst should also not have Bitcode.
• Not sure what the stance should be on Bitcode going forward. Bitcode has been discontinued in Xcode 14.0 and many developers are stripping it out of their pipelines. However - developers that need to support Xcode 13.0 may continue to need it.
• The Bitcode generated will also not be compatible with Xcode anyway in since Rust uses a different version of Bitcode. So enabling this flag may actually break iOS builds.

[BlackHoleFox]

The rustc PR for --print deployment-target just landed (rust-lang/rust#105354), and should be available starting in 1.71 fyi. Ideally that would be queried for the version and then falling back to this hardcoded logic if the compiler is too old.

[francesca64]

@colincornaby this PR is minimally invasive and doesn't actually change the existing behavior around bitcode; bitcode is already being unconditionally generated for all non-macOS Apple platforms on main:

cc-rs/src/lib.rs

Line 2340 in 57853c4

cmd.args.push("-fembed-bitcode".into());

Deciding how cc should handle bitcode going forward should be left to another issue/PR, since landing this PR would be hugely beneficial to anyone developing macOS apps written in Rust.

@thomcc

I think it's reasonable to take advantage of MACOSX_DEPLOYMENT_TARGET, but I don't think we should default to setting this to something old. I'd actually probably prefer we don't set it if not provided.

clang defaults to targeting the same version of macOS currently being run, which is in contrast to Rust defaulting to a specific old version for maximum support. As it stands, it's impossible for someone developing a macOS app with any dependencies that use cc to target macOS versions earlier than what their development machine is running. This is nearly a non-starter for anyone who wants to make binary distributions of macOS apps, as the only workaround is to fork every such dependency to use this PR.

cc should follow the same conventions Rust itself does, since the current behavior is very surprising and leads to countless difficult-to-trace linker warnings about object files targeting too new of a version.

As mentioned, this PR is minimally invasive and merely extends the existing behavior around Apple platforms to account for macOS as well. I've tested this PR, and it solves all of my build problems flawlessly.

[francesca64]

Suggested change

	let is_mac = match os {
	Os::MacOs => true,
	_ => false,
	};
	let is_mac = matches!(os, Os::MacOs);

matches! was added in 1.42, which is below the MSRV.

[thomcc]

Yeah, I'm fine with this PR now. My complaints about the too old version were from an earlier version. I'd be fine with a rebased version of this.

[youknowone]

I wish it can be merged at this time. This is now too old to remember what I thought at the moment. I'm afraid I cannot properly rebase it one day.

[BlackHoleFox]

I opened up #848 to further this PR's changes like said on a previous comment, so it also contains a rebased version of the commit here. Depending on which merges first, the rebase this branch needs (a one line print conflict) might be unnecessary.

[youknowone]

@BlackHoleFox Thank you!

[youknowone]

I rebased this PR just in case if it need to be merged first.
But I totally agree to #848 and also prefer to merge this patch through it.

[BlackHoleFox]

It looks like my forward PR merged with these changes, so this one could be closed as done @youknowone

[thomcc]

Yeah this is done. Sorry for all the delays here.