[CMake] iOS multi-arch library target and xcodebuild

[Parag Chandra]

Jason,

I¹ll have to get back to you on that. The problem is the snippets I¹m
referring to are part of a much larger build system I¹ve created for Mac,
Windows, Linux, iOS, Android, Windows Phone, and Native Client, and so you
would likely need a lot of other supporting files to make sense of them.
I¹ll have to check with management to see if I could share those. In the
meantime, here is what I hope is a small block of CMake code that will get
you started creating the ³universal-³ targets I mentioned previously:


add_custom_target("universal-${artifactName}"
  COMMAND ${CMAKE_COMMAND} -E make_directory
"${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-universal"
  COMMAND lipo -create -output
"${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-universal/${destFile}"
    "${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-iphoneos/${destFile}"
    
"${CMAKE_CURRENT_BINARY_DIR}/$(CONFIGURATION)-iphonesimulator/${destFile}"
        )

The next line shows you how to set the Xcode variables:

set_target_properties (${artifactName} PROPERTIES
XCODE_ATTRIBUTE_MY_BUILD_ONLY_ACTIVE_ARCH ³YES²)

set_target_properties (${artifactName} PROPERTIES
XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH "\${MY_BUILD_ONLY_ACTIVE_ARCH}²)


If you look at the generated Xcode project after executing those two
lines, you will notice that the ³Build Active Architecture Only² setting
in the Build Settings view will be set to the value ³Yes -
${MY_BUILD_ONLY_ACTIVE_ARCH}², which tells you that the setting is taking
its value from another variable. Now that it is a variable, you can
override this behavior simply by passing ³MY_BUILD_ONLY_ACTIVE_ARCH=NO² to
xcodebuild when you run it on the command line.

Hope this helps.

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, 12:02 PM, "Jason Cooper" <cmake at lakedaemon.net> wrote:

>Parag,
>
>On Thu, Apr 02, 2015 at 02:32:13PM +0000, Parag Chandra wrote:
>> 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.
>
>Ok, misunderstanding on my part.  Thanks for clearing that up.
>
>> 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.
>
>Would you mind sharing the relevant file(s)?
>
>> 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.
>
>Well, from my end, I'm build an automated system, so I won't be using the
>IDE.
>I'll be providing binaries (static/shared libs) for the devs to use.
>
>Whichever method gets me there reliably that I don't have to fiddle with
>too
>often will work.
>
>I'm only working with cmake because the upstream project uses cmake and I
>hope
>to have my changes incorporated into mainline.  Other upstream projects
>use
>Makefiles, so I'll not push cmake on them.
>
>thx,
>
>Jason.