[feature] SDK Version for apple OSes

[NoWiseMan]

This is the second year Apple has made a major change to the SDK within the same major release of Xcode.
With Xcode 12.0 Apple shipped macOS SDK 10.15 and with Xcode 12.1 they changed it to macOS SDK 11.0.
Now it looks the same (probably because iOS 15 came out earlier than macOS 12)
Xcode 13.0 comes with macOS SDK 11.0 and it is sure that one of the next minor updates, probably 13.1, will bring us macOS SDK 12.

Changing an SDK is a big deal as it removes APIs, brings new APIs and can give changes in the behavior of your application. So it's time to have the ability to differentiate Conan packages by SDK version.
The same is true for all other Apple operating systems.

I can add an option myself, or it can become an additional setting under OS

my suggestion would be, these additions in the settings.yml

    Macos:
        version: [None, "10.6", "10.7", "10.8", "10.9", "10.10", "10.11", "10.12", "10.13", "10.14", "10.15", "11.0", "12.0"]
        sdk: [None, "macosx"]
        **sdk_version: ANY**    
        subsystem: [None, catalyst]
    iOS:
        version: ["7.0", "7.1", "8.0", "8.1", "8.2", "8.3", "9.0", "9.1", "9.2", "9.3", "10.0", "10.1", "10.2", "10.3", "11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1", "12.2", "12.3", "12.4", "13.0", "13.1", "13.2", "13.3", "13.4",$
        sdk: [None, "iphoneos", "iphonesimulator"]
        **sdk_version: ANY**    
    watchOS:
        version: ["4.0", "4.1", "4.2", "4.3", "5.0", "5.1", "5.2", "5.3", "6.0", "6.1"]
        sdk: [None, "watchos", "watchsimulator"]
        **sdk_version: ANY**    
    tvOS:
        version: ["11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1", "12.2", "12.3", "12.4", "13.0"]
        sdk: [None, "appletvos", "appletvsimulator"]
        **sdk_version: ANY**    

A consumer of such a package must have the same or higher sdk_version, otherwise there will be linker warnings.
Within a dependency tree there should be no differences in sdk_version for the same package

[franramirez688]

Thanks for reporting the issue @NoWiseMan

Let me know more about your use case. Have you faced any problem consuming any package at some point?
Adding it directly to the current Conan settings is not such a simple thing I'm afraid. The settings are part of the final package_id so we must be careful adding new ones to the existing recipes because we would need to update all of them. That's talking about a global change in Conan repository but you could make it easier for your personal use case.
It would be enough to use customized settings I guess. Some useful links here:

• https://docs.conan.io/en/latest/extending/custom_settings.html#custom-settings
• https://docs.conan.io/en/latest/howtos/sanitizers.html?#adding-custom-settings
• https://docs.conan.io/en/latest/reference/commands/consumer/config.html#conan-config-install

[NoWiseMan]

Thank you for your very fast response.

Yes, custom settings also work. But I see no real difference between custom settings and an option.

But there is a big difference when conan gives an error when the consumer has a lower SDK version than the package.

Apple platforms have, say, this triple of important values.

• Compiler version (due to ABI changes in C++).
• Deployment Target (the minimum version of the operating system required to run the software, which can heavily change the way the dynamic linker works, for example).
• SDK version, this was closely tied to the Xcode version, but this is now no longer certain.
• (Swift version, but we can ignore that for now).

compiler version has an equivalent in conan, since it is linked to settings.compiler.version.
development target has an equivalent in conan, since it is linked to settings.os.version
but the SDK version has no equivalent in conan

We have had this problem since last year. Xcode 12.0 came with macOS SDK 10.15, and Xcode 12.1 brought macOS SDK 11.0 (with support for ARM, and some new APIs).
We worked around this problem by adding an SDK_version as an option to our conan packages. A "native" support for the SDK version would be more appealing, and defining only 2 of the 3 dependencies can lead to issues

[NoWiseMan]

Oh I forget:

The SDK version, can change the behaviour of the whole application

[franramirez688]

Thanks for your great explanation.

Yeah, you're right and it could make sense to have it "natively".
Let me have a look into this issue and I'll bring you some news asap.

[dheater]

We might want to generalize any solution here. I've had a similar problem on Linux where I need to support RHEL 6 with has a very old version of glibc. So maybe some generic solution would allow a setting for sdk version on Mac, libc version of Linux, and there is probably something similar on Windows?

[memsharded]

@dheater The problem with this fine grained subsettings, like something for libc is that they force you into an exact version. Settings do not have ranges of values, every libc will give you a new binary. This might be ok if you want to work with exact libc version all around, but in practice this is not the common thing, but to work with ranges of libc (typical RHEL6 with older libc, modern Debian with modern libc). But the libc version is not a good solution.

As @NoWiseMan is commenting the Apple SDKs seems to be exact matches, as they add new behavior, but can also remove APIs, and completely break. So consumers might want to make sure they all match an exact SDK, always. So I am not sure this can be generalized to the Linux libc one without causing there more pain than the one it tries to solve.

[dheater]

For Mac development I am specifying the minimum SDK. I can build with a newer SDK and it seems to provide backwards compatibility. In my profile:

[env]
CFLAGS=-mmacosx-version-min=10.15

[memsharded]

@NoWiseMan could please you confirm the above Changing an SDK is a big deal as it removes APIs, ? Because that means the SDK doesn't provide backwards compatibility.

@dheater Regarding CFLAGS=-mmacosx-version-min=10.15, that is the OS version, not the SDK one, isn't it? (I am no Mac user). Conan toolchains will map the os.version setting to this compiler flag. The OS might indeed have backwards (mostly runtime) compatibility, while the SDK (mostly buildtime) might not.

[czoido]

We finally decided to wait a bit, until we release the Xcode toolchain and build helper and have more information about how everything works with the Apple sdk's so I'm moving this 1.43 milestone.

[NoWiseMan]

@memsharded Yes, it is possible for an API to be removed, added, or deprecated. There may also be different behavior of the API that is still present. This is more likely in the higher layers of AppKit than in the API for C++ libraries. But yes, there can be big changes.

@dheater
mmacosx-version-min is a different thing, it sets the min os version on which the lib/app runs. This will change the commands used by the dynamic linker for example.
And as memsharded said this is mapped to os.version, so I see no need to have this in the envoirment

[NoWiseMan]

Frameworks created with Xcode 13.1 and macOS SDK 12.0 cannot be used with Xcode 13.0.
macOS SDK 12.0 adds an additional dependency to some of the base OS frameworks that are not present in the macOS 11.x SDKs.
Because of this, we not only received some warnings about an SDK mismatch, we receive hard errors about them.

[memsharded]

This has been implemented in #10608, will be released in 1.46. Feedback once released welcome

[eigenwhat]

I was looking into where this new sdk_version came from, and I'm a bit confused as to why os.version wasn't good enough? The SDK versions were always tied to the version of the operating system they were targeting, e.g. the 10.15 SDK was for MacOS 10.15, i.e. "Catalina". It seems bizarre to ever not have these in lock step with each other. I believe anything built with MacOS SDK 12 specifically targets MacOS 12.0 ("Monterrey"), that is, can't run on Big Sur (11.x).

[eigenwhat]

Is this for situations where you might want os.sdk_version to trail os.version? Like target Monterrey but build with the Big Sur SDK (-s os.version=12.0 -s os.sdk_version=11.0)? But then I'm just not sure how that results in a different build artifact from having os.version=11.0 outside of artificially having a different package ID.

Edit: Okay, I think I answered my own question. Looking at the attached PRs, this is more about having finer grained control over which SDK is chosen by the build tools when building. Setting the SDK version allows for passing -sdk iphoneos15.0 instead of merely -sdk iphoneos, which otherwise will use whichever the latest SDK is supported by the target OS?

[memsharded]

Edit: Okay, I think I answered my own question. Looking at the attached PRs, this is more about having finer grained control over which SDK is chosen by the build tools when building. Setting the SDK version allows for passing -sdk iphoneos15.0 instead of merely -sdk iphoneos, which otherwise will use whichever the latest SDK is supported by the target OS

Yes, I think this is the reason, maybe @czoido can confirm