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

[Raffi Enficiaud]

Le 21.09.17 à 23:38, Raffi Enficiaud a écrit :
> Le 08.08.17 à 14:08, Raffi Enficiaud a écrit :
>> Hi CMake ML,
>>
>> I am quite new to the topic of making toolchain files. However I need to
>> build a not so trivial application for iOS and I want to do it with
>> CMake, and if possible walk toward an official support of iOS in CMake.
>>
>> I have looked a bit to the Android toolchains, and I have to say I found
>> those quite complicated as a first reading :)
>>
>> The target application I am building uses Qt and Boost.
>>
>> So far, I have managed to have an IOS toolchain file that is generating
>> a looking good XCode project, that I can compile properly (up until
>> signing).
>>
>> [snip]
>
> Hi there,
>
> Following the thread, I would like to suggest a toolchain file for iOS,
> attached to this post.
>
> I used this to compile a not too small project using Qt, Boost, LSL and
> some other fancy dependencies, and the project runs at least on the
> simulator (waiting for a real device).
>
> The way it works:
>
> - we need different build trees for the simulator and for a real device
> (not same arch nor base SDK). Changing this is way too difficult and the
> workaround of having different build trees, although not very "elegant",
> just work
>
> - for the simulator
> cmake -G Xcode \
>   -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
>   -DIOS_PLATFORM=SIMULATOR \
>   ../some-path
>
> - for a real device
> cmake -G Xcode \
>   -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
>   -DIOS_PLATFORM=OS \
>   ../some-path
>
> - for the device, we need a real certificate for signing that can be set
> directly from within XCode or by setting
> `XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED=YES` and the companion variables
> to the appropriate values
>
>
> Next steps:
> * I can set up a machine for running the tests as I am doing for the
> Matlab package. Those tests would be for the moment compilation tests. I
> would be happy to discuss on how to do real "runtime" tests.
> * I can proceed further with the documentation of course if people are
> happy with this toolchain file
> * I can add other SDKs like watchOS and such, but before proceeding
> further I would prefer to have a feature complete implementation for iOS
> device+simulator (I believe this is the most demanded).
> * I can check how to tweak CROSSCOMPILING_EMULATOR to run things on an
> emulator in case we are on the simulator. I believe add_test should be
> disabled when compiling for a real device
> * I would like to know if there is any direction in indicating the
> bundles structures, as those are different for iOS and macOS. Right now
> I am using a switch like this
>

Hi CMake,

I do not know if anyone here had the chance to try the previous 
toolchain file.

Since then, I have now a real device and some new fixing has started on 
my side. One of the issues I am facing right now is the one concerning 
the RPATH generation on iOS. I think the best approach is to mimic the 
one for OSX/macOS, but I do not know how this would be feasible.

The main question is:
Is it possible to source the default setup and to override some parts 
when a toolchain is given on the command line?
Also, is it possible to check for policies directly from the toolchain 
file, or is it too early?

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/")

and I need to also do this:
set_target_properties(mymainexecutable
   PROPERTIES
     BUILD_WITH_INSTALL_RPATH TRUE
     INSTALL_RPATH "@executable_path/"
)

for the main executable (I need to bundle additional ".dylibs" into the 
main application). For some reason, the CMAKE_* variables do not always 
propagate well to the targets (using cmake 3.7).

Any hint or good practice welcome!

Thanks,
Raffi