[question] settings.os.version vs CMAKE_SYSTEM_VERSION for macOS

[solarispika]

What is your question?

I have encountered an issue with a library that uses CMAKE_SYSTEM_VERSION to disable a feature. When cross-compiling it on macOS Apple Silicon for macOS Intel, CMAKE_SYSTEM_VERSION is not set, leading to inconsistent behavior between native and cross-compilation builds. Although the cross-compiled version does not function correctly, this is a separate issue.

I want to resolve this by correctly specifying CMAKE_SYSTEM_VERSION. According to Conan's documentation:

CMAKE_SYSTEM_VERSION: tools.cmake.cmaketoolchain:system_version conf if defined, otherwise os.version subsetting (host) when defined

This raises confusion about which version to use.

CMake's CMAKE_SYSTEM_VERSION refers to the OS version, which for macOS is the Darwin version. This is supported by CMAKE_SYSTEM_NAME being Darwin for macOS. Conversely, Conan's settings.os and its version refer to macOS versions.

Additionally, Conan may set CMAKE_SYSTEM_VERSION to os.version or os.sdk_version (which aligns with macOS versions) when cross-building:

• Conan cross-building documentation
• Conan toolchain block code

When I set os.sdk_version=11.0, the library failed to configure because the -isysroot was set to macosx11.0, and the compiler couldn't find such a sysroot:

clang: warning: no such sysroot directory: 'macosx11.0' [-Wmissing-sysroot]

It only worked when setting the version through tools.cmake.cmaketoolchain:system_version.

Could you please advise on the correct way to set these versions?

Thanks.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @solarispika

Thanks for your question

I have encountered an issue with a library that uses CMAKE_SYSTEM_VERSION to disable a feature.

Maybe I would challenge the approach in the first place? What is the feature that is being disabled? Isn't it better to have it defined explicitly (in an imperative way)? In general being explicit about what features of a library to enable/disable is better than letting the build systems to guess or autodetect things.

It is possible for a recipe to just patch the build system script to do exactly what you want when you want.

[solarispika]

Hi @memsharded

The library is not owned by us, and it is FSEvents of macOS that is disabled when Darwin version is not greater than 9, maybe due to it's only available for newer versions of Darwin.

Since the libray is not listed in conan index, so we provided a simple recipe for it ourself.
We did not notice the problem until we started cross compile x64 on arm recently.

We can patch CMakeLists.txt of the library, and it looks more reasonable.
Thanks for your advice on this.

BTW, I still would like to know how those version settings work together, can you help me on it?
Thanks.

[memsharded]

The library is not owned by us, and it is FSEvents of macOS that is disabled when Darwin version is not greater than 9, maybe due to it's only available for newer versions of Darwin.

That wouldn't be a blocker. Tons of ConanCenter recipes do patches to the libraries that they don't own, to be able to correctly package them. If that helps you, it is ok to patch the CMakeLists.txt (or other build scripts) of the library, it is not uncommon that build scripts are not perfect for all scenarios, specially for cross-compiling or other advanced scenarios, that maybe the original authors didn't take into account.

We can patch CMakeLists.txt of the library, and it looks more reasonable.
Thanks for your advice on this.

Good, yes, I think it can make sense for this case.

BTW, I still would like to know how those version settings work together, can you help me on it?

I think it goes like this:

• os.sdk_version is used exclusively by Apple system when cross compiking to define the CMAKE_SYSTEM_VERSION
• os.version is used:
  • to set CMAKE_SYSTEM_VERSION for non-Android systems that are cross-compile (with CMAKE_SYSTEM_NAME Generic or QNX
  • to define the winsdk_version (also from tools.microsoft:winsdk_version conf) that will also define the CMAKE_SYSTEM_VERSION
  • To define the CMAKE_OSX_DEPLOYMENT_TARGET variable

[solarispika]

BTW, I still would like to know how those version settings work together, can you help me on it?

I think it goes like this:

• os.sdk_version is used exclusively by Apple system when cross compiking to define the CMAKE_SYSTEM_VERSION

What values am I supposed to give? Those values defined in default settings are macos versions, but I thought it should be Darwin version per CMake's documentation on CMAKE_SYSTEM_VERSION.
Do I misunderstand something?

• os.version is used:
  • to set CMAKE_SYSTEM_VERSION for non-Android systems that are cross-compile (with CMAKE_SYSTEM_NAME Generic or QNX
  • to define the winsdk_version (also from tools.microsoft:winsdk_version conf) that will also define the CMAKE_SYSTEM_VERSION
  • To define the CMAKE_OSX_DEPLOYMENT_TARGET variable

[czoido]

Hi @solarispika,

Thanks a lot for reporting. I have just opened an issue as I think that we are not setting the correct value for CMAKE_SYSTEM_VERSION, it should be the Darwin version and not the sdk version. Anyway, the recomendation for cross-building is always to set these values via the conf or using an user toolchain.

[solarispika]

Hi @czoido
It's great to see that this behavior will be fixed in the future. Thanks!

My last question on os.sdk_version where setting it caused CMake failing to compile due to -isysroot pointing to non-existing path, macosx11.0 for example.

Will #16282 also fix that or do I overlook something?