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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
