[cmake-developers] iOS support

Brad King brad.king at kitware.com
Thu Oct 2 09:02:08 EDT 2014


On 09/23/2014 11:42 AM, Florent Castelli wrote:
> On 23 Sep 2014, at 16:56, Bill Hoffman wrote:
>> Much of the stuff found in these toolchains:
>> https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake
>> https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake
>> https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake
>> Should be in Platform files.  If we created ios platform files we could
> remove most of the stuff from those toolchain files.
> 
> The problem is that I want a project that is usable by developers directly
> and you can't really force them to target just the simulator. It should work
> for targeting both simulator and real device. So having a generic iOS toolchain
> that can generate both in one project is a requirement for me.

Ideally a toolchain file should have only settings specific to
the local machine where it will be used, such as the paths to
staging prefixes where dependencies built for the target arch
may be installed.  All information that is general to the iOS
platform should be in a module that comes with CMake, and only
the local system info should be the toolchain file (which does
not come with CMake).

To clarify Bill's suggestion, much of the content in third-party
iOS toolchain files is stuff like this:

 set (CMAKE_SHARED_LIBRARY_PREFIX "lib")
 set (CMAKE_SHARED_LIBRARY_SUFFIX ".dylib")
 set (CMAKE_SHARED_MODULE_PREFIX "lib")
 set (CMAKE_SHARED_MODULE_SUFFIX ".so")
 set (CMAKE_MODULE_EXISTS 1)
 set (CMAKE_DL_LIBS "")

 set (CMAKE_PLATFORM_HAS_INSTALLNAME 1)
 set (CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-dynamiclib -headerpad_max_install_names")
 set (CMAKE_SHARED_MODULE_CREATE_C_FLAGS "-bundle -headerpad_max_install_names")
 set (CMAKE_SHARED_MODULE_LOADER_C_FLAG "-Wl,-bundle_loader,")
 set (CMAKE_SHARED_MODULE_LOADER_CXX_FLAG "-Wl,-bundle_loader,")
 set (CMAKE_FIND_LIBRARY_SUFFIXES ".dylib" ".so" ".a")

These kind of settings belong in a CMake Platform/<SYSTEM_NAME>.cmake
file.  For example, see the platform file for OS X:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.0.2

Furthermore, commonly used third-party iOS toolchain files
start with this:

 set (CMAKE_SYSTEM_NAME Darwin)

Instead an iOS toolchain file should start with:

 set (CMAKE_SYSTEM_NAME iOS)

and there should be a Modules/Platform/iOS.cmake file that comes
with CMake to contain settings like those above.  The code for
finding the iOS SDK path should also be in a platform module.  It
should go either in iOS.cmake itself, or in an iOS-Inititalize.cmake
file similar to Darwin-Initialize.cmake:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=f640b2a4

Once such modules come with CMake, toolchain files can be very
short and only need to say they are for iOS and then specify
local system information.

-Brad




More information about the cmake-developers mailing list