Skip to content

WIP: Darwin iphone friendly cmake

Gregor Jasny requested to merge gjasny/cmake:darwin-iphone-friendly-cmake into master

This merge request is an attempt to improve CMake's handling of non-macOS SDKs. The goal is to provide an convenient way to a project for iOS, watchOS, ant tvOS. So far it just needs some tweaks of the Modules scripts.

Example usage:

cmake -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_OSX_SYSROOT=iphoneos -GXcode .

optionally specify a development team with -DCMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM=ABCDEFG

Ideas behind the implementation

The first thing was chose a system name. Historically CMake uses Darwin for macOS and iOS. The first attempt of those patched tried to use Apple as the new system name which would have triggered the new behavior but I soon realized that I'd have to duplicate lots of functionality from the existing Darwin scripts. So for now I sticked to Darwin. We'll have to find a way to not accidentally trigger some backwards-incompatible behavior.

CMake by default defines some variables describing the target system. So in 80c5752e I do as well define IOS, TVOS, WATCHOS, and MACOS. In case a simulator build is happening SIMULATOR is defined as well. Also CMAKE_CROSSCOMPILING is enforced to be in effect for non-macOS builds to switch of some assumptions that are only true for native macOS builds.

Next thing in fcbded27 was to enforce App Bundle creation for non-macOS SDKs.

In 81622cbb I restrict find_library() to only lookup headers and libraries in the SDKs. As a result for example zlib a must be found only on the SDK directory, not in /usr.

One problem we faced in the past was that you'll have to setup code signing keys to build for the embedded platforms. This was because DetermineCompilerId and try_compile() attempted to build an executable or XCTest. Since a (to be exactly determined) Xcode version it is possible to build static libraries for all SDKs. So I'll changed both built target types to a static library in 673bfcad. This has the advantage that the configuration stage now does not depend on signing keys. If the user-provided targets require code signing and no keys have been set up, the error is now much more prominent and at the expected place.

In case the Xcode generator is used the default CPU architectures for the selected SDK are used. If the Ninja or GNU Makefile generator is used one has to explicitly specify the CPU architectures are usual with: -DCMAKE_OSX_ARCHITECTURES="armv7;x86_64" or similar.

Questions

  1. Is Darwin an acceptable system name? How could we prevent backwards incompatible behavior around the new variable names?
  2. Does using static libraries for DetermineCompilerId and try_compile() have any downsides?

Merge request reports