[CMake] iOS multi-arch library target and xcodebuild

[Ruslan Baratov]

On 25-Jun-15 12:14, Eric Wing wrote:
>> * iOS toolchains I'm using: https://github.com/ruslo/polly (used to
>> switch between different SDKs + to add some flags, like -std=c++11)
> Do you have to use a different toolchain for every different variant
> and different OS version? That's rather unfortunate if so. My current
> tweaks don't require this.
Can you clarify what you mean by "different variant"? Yes different OS - 
different toolchain. So what is the alternative? I think '--toolchain 
ios-8-2' is shorter than '-DCMAKE_TOOLCHAIN_FILE=/path/to/iOS.cmake 
-DIOS_OS_VERSION=8.2 -B_builds/ios-8-2'.
>
>> * when I run "Archive" for preparing my application for uploading to
>> AppStore Xcode uses only device architectures. Just set "Build Active
>> Architecture Only" to NO and universal application for device will be built
> I think I saw this mentioned elsewhere and am employing that. Still,
> I'm a little concerned this might be a hack that is working around a
> more underlying problem that could break.
...
>
>> * I see no point of using frameworks for managing 3rd parties. Plain
>> `<root>/include` and `<root>/lib` layout works for iOS (and for all
>> others platforms like MSVC, MinGW, ...)
> Frameworks vs. dylibs isn't the issue at all here and completely
> misses the point. The point is the way FIND_LIBRARIES anchors absolute
> paths to everything. This won't work with SYSTEM framewoks because the
> paths dynamically change depending on device or simulator.  3rd party
> fat binaries installed in a single location regardless of frameworks
> or dylibs. This is annoying because you must remember whether you are
> dealing with a system provided library or a third party library in the
> way you write your CMake files now.
I guess it's a general problem, not just about iOS. To avoid absolute 
paths problem you need to use `find_package(... CONFIG` and add @rpath 
to RPATH. See this overview: 
https://github.com/ruslo/hunter/wiki/example.find_package.config#relocation-challenge
>
> A disgression: my understanding is that for iOS, officially for 3rd
> party dynamic libraries, only frameworks and not dylibs are supported.
Well Xcode is not "officially" CMake-friendly and CMake do not 
"officially" support iOS. We are just sharing some solutions that 
*really* works.
>
>
>
>> * Hunter automatically set CMAKE_PREFIX_PATH and <package>_ROOT to the
>> root directory of 3rd party libraries so `find_package` works fine
> Okay, I think I've done something similar by setting the
> CMAKE_ROOT_PATH to look in the CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH,
> CMAKE_INCLUDE_PATH. I needed this for Android's NDK Module system
> convention too.
This works for Android too.
>
>
>
>> * toolchain used to switch between different SDK's. You just need to set
>> environment variable IOS_X_Y_DEVELOPER_DIR. See
>> https://github.com/ruslo/polly/wiki/Toolchain-list#ios
> Okay, I think my tweaks have done better than this. I don't need to
> set any environmental variable changes. I can use the built-in Xcode
> UI to switch between SDKs and my tweaks are mostly agnostic to which
> iOS SDK version you have. (It always detects the default installed.)
IOS_X_Y_DEVELOPER_DIR can point to different Xcode locations. I guess 
you use xcode-select to set current Xcode and then you use SDKs 
available from `xcodebuild -showsdks` (?) It's not hard to add such 
feature. My current workflow: just set new IOS_X_Y_DEVELOPER_DIR 
environment variable to .bashrc when new Xcode available. I can use all 
Xcodes I have in such way.

Also it's possible to add default one. Actually there was simple `ios` 
toolchain in collection that works such way. I've removed it because I 
think it's quite convenient to use version explicitly because it not 
break things "suddenly" because you install new Xcode or add new SDK.
> My concerns are not merely one-shot automation builds. I do manual,
> every day development in Xcode and expect/follow a mostly natural
> Xcode developer work flow and other developers on the platform expect
> the same. Being able to switch between simulator and device without a
> roundtrip CMake generation is extremely useful (and expected), along
> with being able to test the different architecture variants (32-bit,
> 64-bit).
I guess it's not related to SDK's switching. As I mentioned earlier you 
can use one Xcode instance to run device/simulator for all available 
architectures.
>
>
> I plan to do a write up of some kind to show my workflow and present
> my tweaks I made to try to improve things for all the platforms I work
> on to make the every day workflows more natural for each respective
> platform.
>
>
> But I do suspect the fat device/simulator binary build patch would be
> very useful to have.
>
> Thanks,
> Eric