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

[Raffi Enficiaud]

Le 27.09.17 à 12:34, Brad King a écrit :
> On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:
>> Is it possible to source the default setup and to override some parts
>> when a toolchain is given on the command line?
>
> The toolchain file is loaded very early, before any of the platform
> information files.  It is supposed to provide information, not consume it.
> It is loaded too early to even know CMAKE_SYSTEM_NAME, because it is
> supposed to provide this value.

Thanks for the answers!

 From what I understand, I missed the point of the cross compilation 
file a bit, and I should rather go for platform files.

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)

* inside "Modules/Platform/Darwin.cmake"
    * CMAKE_SYSTEM_PROCESSOR should default to armXX for iOS and 
i386/x86_64 for the simulator
    * I do not think that any other compiler than AppleClang is 
supported, but we leave the detection as it is right now. This should 
default to AppleClang anyway.
    * the detection of the base SDKs should be performed inside 
"Platform/Darwin.cmake"
    * the file "Modules/Platform/Darwin-Clang.cmake" should check the 
"CMAKE_SYSTEM_VERSION" to add appropriate flags when 
CMAKE_SYSTEM_VERSION is iOS or simulator. This should include clang and 
apple clang.

If things work ok and if I understand more or less the scope of those 
files, the base SDKs will then be detected from the 
"Modules/Platform/Darwin.cmake".

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.

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.

Should the CMAKE_SYSTEM_VERSION include the "iOS" or "iOSSimulator" 
part? (like for instance "iOS-10.1" ?) or we stick to a clean version 
name and:

1/ either we change the CMAKE_SYSTEM_NAME to DarwinIOS (we also need to 
distinguish between real device and simulator)
2/ or we carry another variable IOS=TRUE and be careful inside the 
Darwin specific platform files.

My preference goes for 2/ above because:
* having something like DarwinIOS would need to create a full new branch 
of platform support, while the overlap with Darwin is almost 95%.
* iOS is clearly a Darwin platform, just another version, but version 
carries more than a revision number (eg "10.5") that needs to be encoded 
in another variable (eg. IOS=TRUE)
* we will benefit from all the build logic (Darwin, policies, etc) that 
are currently working for OSX

>
>> Also, is it possible to check for policies directly from the toolchain
>> file, or is it too early?
>
> In a project that starts with `cmake_minimum_required(...)` as its first
> call (the recommended approach) then policies it sets will be available
> when the toolchain file is first loaded by a following `project()` or
> `enable_language()` command.  However, toolchain files are not meant to
> be general-purpose infrastructure shared by many projects.  They are
> meant to be specific to a project and host machine.  Common info about
> a platform belongs in CMake's modules, e.g. a Platform/iOS.cmake module
> for use with CMAKE_SYSTEM_NAME set to "iOS".  Lacking that, a toolchain
> file trying to work without it will undoubtedly need to be hacky.

I believe if I integrate well with the platform files, all things would 
be good again, and the policies will apply naturally (so no hack needed).

>
>> This is what I added in the toolchain file, but I feel like this is too
>> hacky:
>>
>> set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
>> set(CMAKE_INSTALL_NAME_DIR "@rpath/")
>> set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
>> set(CMAKE_INSTALL_RPATH "@rpath/")
>
> If that is universally needed when deploying to iOS then CMake should
> be taught this information in a corresponding platform file.

I do not think this is universally needed, I just wanted to mimic the 
default I got when compiling the same source tree but with the OSX 
target platform. Without great success ...


> Keeping
> it in the toolchain file may work but is an example of the hacky nature
> discussed above.  OTOH this looks project-specific to me.  One could
> use `@executable_path/` in INSTALL_NAME_DIR for everything and not need
> any rpath.

Yes, I was not convinced neither and totally fine with removing this.

>> and I need to also do this:
>> set_target_properties(mymainexecutable
>>    PROPERTIES
>>      BUILD_WITH_INSTALL_RPATH TRUE
>>      INSTALL_RPATH "@executable_path/"
>> )
>
> This encodes knowledge of the relative install destination of the
> libraries to the executable, which only the project code itself
> can know.

Here what I wanted to say is that the settings I am placing in the 
toolchain file were not propagating to this bundle project for some 
reason I failed to understand.

Your comments most welcome,
Raffi

PS: how should we proceed with the developments? Having a fork on Gitlab 
based on master and start integrating from there would be ok? Do you 
need a build machine first?