CMAKE_OSX_SYSROOT being set to incorrect value on Xcode 14.3.1

[kibiz0r]

Using v0.7.x and v0.8.0 of this lib, I see a CMake error when building for iOS using Xcode 14.3.1.

It looks like CMake is somehow trying to use iPhoneSimulator16.2.sdk instead of 16.4. (16.4 is the only one actually installed with Xcode 14.3.1)

I tried to reproduce this at the CMake level by just exporting all the same env vars, using a bare bones CMakeLists.txt, and invoking cmake the same way the rnss target invokes it, but CMake correctly found 16.4 in that case.

My project compiles successfully with the old rnss, and includes other libs that use CMake. So I figure it has to be specific to this lib's CMake files.

Relevant output below (full log attached)

CMake Warning at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/Platform/Darwin-Initialize.cmake:303 (message):
  Ignoring CMAKE_OSX_SYSROOT value:

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

  because the directory does not exist.
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/Platform/iOS-Initialize.cmake:1 (include)
  /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/CMakeSystemSpecificInitialize.cmake:21 (include)
  CMakeLists.txt:1 (project)

CMake Error at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/Platform/iOS-Initialize.cmake:4 (message):
   is not an iOS SDK
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/CMakeSystemSpecificInitialize.cmake:21 (include)
  CMakeLists.txt:1 (project)

-- Configuring incomplete, errors occurred!
Command PhaseScriptExecution failed with a nonzero exit code

react-native-static-server cmake error.txt

[birdofpreyru]

For the record, I have double-checked that I'm using Xcode 14.3.1 for a while now, it has iPhoneSimulator SDK 16.4, and when building an app using the latest rn-static-server v0.8.0 for the iPhone Simulator I have no issues with the build. Also I checked that the build config of the library never passes around CMAKE_OSX_SYSROOT value explicitly. Thus, I am not sure at the moment what to look at next to troubleshoot this issue.

Can it be that you got CMAKE_OSX_SYSROOT value effectively cached somewhere from previous builds done with older Xcode, and it just tries to re-use it now with the new Xcode version? Do you get the same error if you clean up all build artefacts and do a completely clean build?

[birdofpreyru]

As there was no further feedback, I guess it is not an issue anymore, thus closing.

[zifeo]

@birdofpreyru Thanks for the pointer. Got the same issue and found cached cmake data in ~/Library/Developer/Xcode/DerivedData (or so called Xcode derived data). It seems that this project is the only one where this is happening, maybe there is still a setting to change somewhere?

[birdofpreyru]

Ok. Let's re-open.

It seems that this project is the only one where this is happening,

The only one among what? Perhaps, most RN projects (and iOS projects in general) don't rely on CMake at all, thus no problem :man_shrugging:

maybe there is still a setting to change somewhere?

I bet there is... I am just not that knowledgeable regarding CMake, and it is a low priority for me to invest my time into figuring out this one, especially if the problem is avoided by a clean build. Thus, no promise I'll look into it much any time soon.

Anyway... it will be helpful if you share details, how did you run into the issue? Did you build for Simulator, and then for a real device? Or anything else? Cause I haven't encountered this issue myself yet (but I mostly build everything on iOS for real devices).

[zifeo]

@birdofpreyru That sounds correct, the best repro I could find is to build the project with one version of Xcode, upgrade (major) Xcode and then rebuild. I suppose a cmake clean or similar on error should do the job?

[birdofpreyru]

@zifeo well... if it only happens when you upgrade major Xcode version, thus changing your build environment, then I guess we have nothing to do here — I might be wrong, but I believe CMake (and not only) philosophy in such case is to expect that you manually clean any artifacts cached from previous builds with a different environment. (On the other hand, I have no idea how a project can detect it automatically and do cmake clean in such case).