[CMake] iOS multi-arch library target and xcodebuild

[Jason Cooper]

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.