SVGKit header placement #81

Open
MaddTheSane opened this Issue May 12, 2013 · 6 comments

Projects

None yet

2 participants

@MaddTheSane

When I tried including the SVGKit header into my bundle, it complained about missing header files. It seems that the headers aren't that well-designed for OS X frameworks. I tried making the headers work on OS X, but that broke the iOS port for some odd reason (I have not had issues including and using my iOS library in PlayerPRO, so this is baffling me.)

@adamgit

Current setup, if I understand correctly (!), is:

  1. All headers go into "public headers"
  2. This causes Xcode to automatically output them into (BUILD DIR)/usr/include/
  3. Which enables us to do stuff like auto-distribute them even though Apple (for no apparent reason) disabled the "framework" option from Xcode
  4. We have 1 custom post-build script that makes a universal binary for iOS. This used to be built-in to Xcode, but Apple deleted it without a clear explanation - we're using this script: http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4

I recently discovered that Apple has a bug in Xcod where "public headers" in a "drag/drop embedded project" (as opposed to a staic library project) cause Xcode to block you from creating an App Store app (no reason for this -- its a bug in Xcode, and there's no known workaround. You either have to delete the headers, or stop using drag/drop projects).

...so it would be good to re-think this, if someone is confident to re-organize the header layouts and fix all the projects so that they continue to build correctly and makes sure it's still easy to include the output into user-projects. (and makes sure the build scfript still works)

IIRC ... You can make frameworks for iOS, but Apple won't allow you to do it with Xcode - you have to make an OS X framework, then manually rename all the files/fodlers/etc and copy/paster/merge it into an iOS project. This is what the big companies (Amazon, Facebook, etc) have done to ship their iOS stuff as frameworks (as you're supposed to). But it's painful and error prone and very easy to screw up :(.

There's a project to ease the pain of creating iOS frameworks but I found it too difficult to follow (it had some quirks that I struggled to workaround) last time I tried: https://github.com/kstenerud/iOS-Universal-Framework -- if that works, it could be the best way to package the iOS part?

@adamgit

What were the changes you had to make for OS X?

@MaddTheSane

I had to make all the headers have the SVGKit… I don't know what it's called… subdirectory? as opposed to

#import "SVGKImage.h"

they had to be

#import <SVGKit/SVGKImage.h>

On a related note, I found out what was different from SVGKit-iOS and iOSPlayerPROCore: There's a copy phase that every iOS static library has that copies the headers to the "Products Directory". The iOS SVGKit has this, but it is unused. My SVGKit branch namespace copies the headers there (with the subpath being include/SVGKit as opposed to include/${PRODUCT_NAME}) as well as getting rid of the header hacks (Personal note: should probably have done that as a different commit).

@adamgit

OK, I've looked into this in detail just now. iOS SVGKit does the same thing, you need to look at the Run Script phase.

iOS SVGKit copies all headers to "(output folder)/usr/local/include/"

...but you have to explicitly tell Apple that you're using a library, and tell Apple which folder the library has output its headers to. According to Apple docs the correct setting is "User Header Search Paths", and setting this to "$(TARGET_BUILD_DIR)/usr/local/include/" seems to work perfectly.

(The angle-bracket part is probably unrelated - that tells Apple to use system/framework headers (which (according to Apple) is technically wrong here) instead of user headers.)

@adamgit

NB: the above is because Apple won't allow anyone to use frameworks on iOS, for no apparent reason.

(We can hack around this (create an OSX framework, manually edit the source files, convert it into an iOS framework), and everything works fine - but it's difficult to get right :(.)

...if any of that breaks the assumptions of frameworks, that sucks, but I don't have anything to test it against.

@MaddTheSane

My master (and my push branch) now handles SVGKit's headers if they're addressed as on either OS X or iOS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment