iOS cmake build should use a toolchain file

[tlein]

Problem: Currently SFML on iOS builds itself with CMake but it does not use a toolchain file. Instead, it sets the necessary CMake variables itself instead of relying on the external toolchain file. It's worth noting that SFML does use a toolchain file for android.

Suggested Solution: Ship an iOS toolchain file with SFML and have the user specify CMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake instead of IOS=True

[headupinclouds]

There is a nice set of toolchains for iOS maintained in polly (companion project for the hunter package manager).

Random examples:

ios-10-3-dep-8-0-libcxx-hid-sections-lto.cmake
ios-10-3-dep-8-0-bitcode.cmake
ios-10-3-armv7.cmake
ios-nocodesign-10-0-arm64.cmake
ios-10-2.cmake

Usage:
cmake -H. -B_builds/ios-10-3-dep-8-0-bitcode -DCMAKE_TOOLCHAIN_FILE=${POLLY_ROOT}/ios-10-3-dep-8-0-bitcode.cmake

[mantognini]

Could you motivate the need for such toolchain (that needs to be updated and maintained)? The fact that it's used for android seems irrelevant to me. What is currently broken?

[tlein]

Sure! Currently the cmake variables setup in SFML would also have to be updated and maintained. Centralizing iOS logic in the tool chain allows us to simplify the rest of the cmake files. This is the standard pattern when setting up a cmake project for cross compiling.

As for my personal motivation, my team has a build system that pulls down and builds all of our projects dependencies when initiating a build for a given platform and architecture. SFML is one of those dependencies and our build system will blindly set the toolchain file for a cross compiled system. This means all of our dependencies are built with the same toolchain file. It would be a hassle to work around specific dependencies quirks when there is a standard pattern cmake already has.

[mantognini]

Centralizing iOS logic in the tool chain allows us to simplify the rest of the cmake files.

Seems like a reasonable thing to do, indeed.

[eXpl0it3r]

Fixed with #1269