On Jul 19, 2014, at 1:07 PM, Jens Alfke <email@hidden> wrote:
On Jul 19, 2014, at 10:50 AM, Chris Hanson < email@hidden> wrote: Cross-platform binaries like this aren’t actually supported.
Whether or not they’re supported, they do work. What’s the issue with supporting them?
A Mach-O fat binary container can only distinguish its sub-files by architecture, not by platform.
That’s why Xcode won’t let you create such a thing, and why you can’t build for iOS and iOS Simulator at the same time and generate a single binary: There’s no such thing as a valid fat binary that contains code for both iOS and iOS Simulator.
That you can go around the tools to create one, and that it might happen to work, is unsupported.
You can have platform binaries in different directories derived from the platform name (macosx, iphoneos, iphonesimulator), and have developers add a $(PLATFORM_NAME) component to the Library Search Paths that point to your stuff:
FRAMEWORK_SEARCH_PATHS = JensKit/$(PLATFORM_NAME) $(inherited)
Frameworks are a really nice concept, and it seems pretty clear that it’s great to be able to give someone a framework as a single Finder icon that they can just drag into their Xcode project and build into their app, without having to mess with build settings. And it’s possible to create such frameworks for iOS, and they work … so I don’t understand why they’ve never been supported by Xcode.
You’re conflating “frameworks” with “fat binaries that support multiple platforms” above.
You can only legitimately put the architectures for a single platform in a single fat binary container, regardless of whether that fat binary is an executable, a bundle, a dylib, or a static library.
-- Chris |