Open solarispika opened 3 months ago
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.
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.
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:
winsdk_version
(also from tools.microsoft:winsdk_version
conf) that will also define the CMAKE_SYSTEM_VERSIONCMAKE_OSX_DEPLOYMENT_TARGET
variableBTW, 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 theCMAKE_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 fromtools.microsoft:winsdk_version
conf) that will also define the CMAKE_SYSTEM_VERSION- To define the
CMAKE_OSX_DEPLOYMENT_TARGET
variable
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.
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?
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: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 byCMAKE_SYSTEM_NAME
beingDarwin
for macOS. Conversely, Conan'ssettings.os
and its version refer to macOS versions.Additionally, Conan may set
CMAKE_SYSTEM_VERSION
toos.version
oros.sdk_version
(which aligns with macOS versions) when cross-building:When I set
os.sdk_version=11.0
, the library failed to configure because the-isysroot
was set tomacosx11.0
, and the compiler couldn't find such a 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?