[cmake-developers] iOS: direction to official support and questions

[Craig Scott]

On Thu, Sep 28, 2017 at 7:40 AM, Brad King <brad.king at kitware.com> wrote:

> On 09/27/2017 08:18 AM, Raffi Enficiaud wrote:
> > For cross-compiling a project on iOS or iOS simulator, and since those 2
> > platforms are still Darwin, I believe that:
> >
> > * from a user perspective:
> >    * CMAKE_SYSTEM_NAME should be set to "Darwin"
> >    * CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator,
> > possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)
>
> Although macOS is based on Darwin, it has historically been a mistake
> to make CMAKE_SYSTEM_NAME "Darwin".  macOS and iOS are different
> enough that they each should have their own platform names/modules.
> Also, CMAKE_SYSTEM_VERSION should always be a number.
>
> > However, I just notice the existence of
> > "Modules/Platform/Darwin-Initialize.cmake" that is setting several
> > variables. When is this file sourced? should be before
> > "Modules/Platform/Darwin.cmake" but I failed to see from where.
>
> See comments here:
>
>   https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/
> Source/cmGlobalGenerator.cxx#L333-372
>
> for how all those files are loaded.  `iOS*.cmake` modules would be
> appropriate for first-class iOS support.  Ideally it should work
> with just `-DCMAKE_SYSTEM_NAME=iOS` without a full toolchain file,
> if that is possible.
>
> > I see several problems with this file if I were to make it iOS aware.
> > For instance it contains variables that are checking for the version,
> > but based only on the macOS scheme.
>
> That's why CMAKE_SYSTEM_NAME should be distinct so we can use a totally
> separate set of modules.  I think that solves most of the other problems
> you raised.
>

(Starting on a tangent, coming back to the above at the end). Note also
that for iOS builds, you don't really want to go fiddling with
the CMAKE_FIND_ROOT_PATH_MODE_... variables, either in toolchain files or
in platform support files that come with CMake. You see this a lot in
toolchain examples online, but that's not really compatible with the way
Xcode allows you to switch between device and simulator builds. There's not
really any 100% satisfactory solution to this in CMake at the moment, as
Eric Wing has summarised rather well in a few recent emails to this list.
As a starting point, I'd recommend only trying to set the minimal things in
iOS platform files which give a successful build. The handling of
find_...() command search paths falls outside of that, in my view.

FWIW, I've been experimenting with this area quite a bit lately after it
became a topic of discussion on this list, in the issue tracker and in
merge requests. At the moment, a minimal toolchain file for iOS which gets
you about as far as you can go seems to be something like this:

set(CMAKE_MACOSX_BUNDLE YES)
if(NOT CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED)
    set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED NO)
endif()

set(CMAKE_OSX_SYSROOT iphoneos)


All but the last line should ideally be unnecessary, but that's the current
state of things at least. The above setting of CMAKE_OSX_SYSROOT works
because Xcode sees the SDK as iphoneos but recognises that there's an
associated simulator configuration. You can then switch the target platform
(device or simulator) at build time without re-running CMake. This is
highly desirable for iOS devs, so it raises the question of how to not
break that if we make CMAKE_SYSTEM_NAME rather than Darwin +
CMAKE_OSX_SYSROOT as the primary way to set up for iOS. Also keep in mind
that, while most projects will probably just be happy to use the latest
installed SDK by default, it's technically possible to specify a specific
SDK version with an appropriate value in CMAKE_OSX_SYSROOT (e.g.
iphoneos9.3, or something like that, can't exactly recall off the top of my
head). If CMAKE_SYSTEM_NAME is taught to recognise iOS as distinct from
Darwin, we'd need to be very careful not to break existing projects that
assume the (fragile but still workable for some projects) method above.




-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170928/a7f1246a/attachment.html>