[CMake] iOS multi-arch library target and xcodebuild

[Parag Chandra]

No idea if they have plans to merge any toolchain files directly into
CMake. Even if they did, cross-compiling is still a process that requires
explicitly overriding your host computer¹s native toolchain, so it¹s not
something that CMake will sort of do for you automatically - you¹re still
going to have to feed it the toolchain.cmake.

With respect to universal binaries, I have setup my CMake-generated Xcode
projects to build them conditionally. The route I have taken is:

1) Set ³Build Active Architecture Only² to an Xcode variable that I
default to ³Yes² from CMake. This way, when developers are actively
working inside Xcode, they don¹t waste time unnecessarily building for CPU
architectures they¹re not going to use.

2) When building from the command line, this Xcode variable is set to
³No², so that we get a pair of quasi-universal binaries - one containing
x86 + x86_64 for the simulator, and another that contains armv7 + armv7s +
arm64 for devices. This seems to be a limitation of Xcode, or at least I
couldn¹t figure out how to force it to generate a single binary with all 5
CPU archs.

3) To work around this, my CMakeLists add custom ³universal-³ targets
that, when run, lipo together the pair of sort-of-universal binaries into
a truly universal binary. Once again, these ³universal-³ targets only get
executed when building from the command line.

I think you¹re going to face a much more difficult challenge if you decide
to discard Xcode and go with Unix Makefiles for iOS. The toolchain file I
pointed you to did not work well with the Makefile generator, at least in
my limited experience. Plus, you would be discarding one of the biggest
advantages of CMake in my view: the ability to work inside of popular IDEs
with intellisense, debuggers, profilers, etc.


Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410

 <https://ionic.com>

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309











On 4/2/15, 8:15 AM, "Jason Cooper" <cmake at lakedaemon.net> wrote:

>Parag,
>
>On Wed, Apr 01, 2015 at 05:43:25PM +0000, Parag Chandra wrote:
>> You need to cross-compile in order to target iOS, but if I?m reading
>>your
>> command line correctly, you are merely instructing CMake to generate an
>> Xcode build system for the host OS, which is naturally going to produce
>>a
>> project that targets Mac OSX.
>
>I never said I was on the *right* path. ;-)
>
>> The normal way to cross-compile with CMake is to feed it a toolchain
>>file,
>> via the CMAKE_TOOLCHAIN_FILE cmd line option. You may want to take a
>>look at
>> the following project to get an iOS toolchain file from which to start:
>> 
>> https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake
>
>Ok, I had run into that before, but reasoned that the presence of
>Tests/iOSNavApp/ meant there was now a way to accomplish my goal without
>having to add what essentially looks like a cmake module.
>
>Is there a plan to merge the above into cmake as a module?
>
>> You can of course do something similar for Android:
>> 
>> 
>>https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain
>>.cmake
>
>Ah, thanks for the heads up.  I'll need that later.
>
>Back to the iOS.cmake.  I was able to get it to successfully build the
>library dylib by adding the following lines to the same file:
>
># don't need code-signing on libs
>set(CMAKE_MACOSX_BUNDLE YES)
>set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
>
>It's only armv7, so not universal.  But I can use lipo to work around
>that.
>
>This all seems rather complicated and fragile, though.  I wonder if it
>might be simpler to have cmake generate standard Unix Makefiles and then
>use a modified version of the openssl build script.
>
>thx,
>
>Jason.