Capitalisation (?) mismatch between conan and CMake

[robindegen]

Environment details

• Operating System+version: macOS 13.3.1
• Compiler+version: XCode/Apple Clang 14.0.3
• Conan version: 2.0.10
• Python version: 3.11.5
• CMake version: 3.27.5

Steps to reproduce

I'm not 100% sure if this is a configuration issue or a bug.
I made the following profile:

[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu20
compiler.libcxx=libc++
compiler.version=14
os=iOS
os.version=16.0
os.sdk_version=16.0
os.sdk=iphoneos

Inside of the conanfile I set the generator to Xcode with the CMakeToolchain class in generate

When I try to build with this profile I get:

CMake Error at /usr/local/Cellar/cmake/3.27.5/share/cmake/Modules/Platform/iOS-Initialize.cmake:4 (message):
  iphoneos16.0 is not an iOS SDK

If I look inside of this file:

if(NOT _CMAKE_OSX_SYSROOT_PATH MATCHES "/iPhone(OS|Simulator)")
  message(FATAL_ERROR "${CMAKE_OSX_SYSROOT} is not an iOS SDK")
endif()

It seems like this is case sensitive? Or maybe it expects to start with a / for some reason?
however Conan sets it to be lowercase in the conan_toolchain.cmake file:

set(CMAKE_OSX_SYSROOT iphoneos16.0 CACHE STRING "" FORCE)

Can I disable setting the sysroot? Or should this be fixed inside of conan?

On this specific system I tested without setting the sysroot and this builds just fine:

cmake -G Xcode -B build \
    -DCMAKE_SYSTEM_NAME=iOS \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=16.0
xcodebuild -target zlibstatic -project build/zlib.xcodeproj

Though without setting it i'm not really sure how to select the simulator

Logs

No response

[memsharded]

Hi @robindegen

Thanks for reporting this.

Can I disable setting the sysroot? Or should this be fixed inside of conan?

I think this could be something to fix in the CMakeToolchain. If CMake expect it to be case-sensitive, that it seems in your case (I had the understanding that OSX could be case-insensitive, but I am not an OSX user), then would be worth to make sure that CMakeToolchain does the right thing.

Do you have something special in your CMakeLists.txt? Are you passing the iOS toolchain yourself in the command line or elsewhere?

[robindegen]

I'm building zlib 1.2.13 here. I'm not performing any code patches on this.
My conan file is here in case you're wondering about more details.

https://github.com/aleya-dev/devops/blob/master/Conan/thirdparty/zlib/conanfile.py
https://github.com/aleya-dev/devops/blob/master/Conan/aleya-conan-base/conanfile.py

The only change i did that is not in that repo yet is add this to the generate(self):

tc.generator = "Xcode"

MacOS is indeed case insensitive by default, though a case sensitive setting for the filesystem exists. It looks like CMake itself expects it to be capitalized properly; probably for the small amount of people that have enabled case sensitivity.

[robindegen]

I worked out how the sysroot is supposed to work for iOS. It looks like you have to specify the entire path:

cmake -G Xcode -B build \
    -DCMAKE_SYSTEM_NAME=iOS \
    -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=16.1

cmake -G Xcode -B build \
    -DCMAKE_SYSTEM_NAME=iOS \
    -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/ \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=16.1

You can also specify specific versions (depending on whats installed):

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.4.sdk/

That one is symlinked to the PhoneSimulator.sdk directory.

The generated "iphoneos16" doesn't exist on my system. There is only iPhoneOS.sdk and iPhoneOS16.4.sdk (which doesn't seem available in the settings.yml.

Seems like there's quite a bit of logic missing here, which might require a bit of designing, and not just a simple bugfix. I'm not sure if CMake provides any infra to detect these. It seems to work if I don't specify anything, but then I can't select the simulator. I can only seem to select the simulator when i specify this entire path. The difference being that the simulator uses x86_64 system libraries while ios itself uses arm.

If i can somehow override the CMAKE_OSX_SYSROOT from my conanfile i'm basically unblocked. I can just add some logic to check what is in the profile and provide the sysroot myself for now until there is some proper fix. Is that possible?

[robindegen]

Would it be possible to stop it from setting a value if i already provided it manually? That might be the simplest fix for now; considering the complexity of making this generic. The install location of XCode isn't even guaranteed as far as I know.

tc.variables["CMAKE_OSX_SYSROOT"] = '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/'

[memsharded]

Hi @robindegen

Sorry that we didn't follow up, it is becoming increasingly difficult with the high volume.
I haven't commented before, but just in case: there is a conf, named tools.apple:sdk_path that can be used to define the Apple SDK externally from the the profile. Did you know about it, have you tried it? For this kind of thing, recipes should never need to be modified with things like tc.variables["CMAKE_OSX_SYSROOT"] = '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/'

Or also, if you want to set arbitrary CMake variables from the profile, it is possible by injecting CMake toolchains, have you checked https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/inject_cmake_variables.html?

[robindegen]

Thanks, I wasn't aware of this. I will give it a go.

The only issue I can see with this is that the profile determines the sdk path; since if I want to build for the simulator on x86, the path is actually different (iPhoneOS.platform vs iPhoneSimulator.platform). So I could change it in the config and have something working but then I still wouldn't be able to build both profiles right? I would have to update the config every time?

The cmake variable inject could work. That seems the most likely solution to work around this issue.