search

kstenerud / iOS-Universal-Framework

An XCode project template to build universal frameworks (arm7, arm7s, and simulator) for iOS / iPhone.
2.95k stars 473 forks source link

Modifying XCSpec files seems fragile #6

Open jweinberg opened 13 years ago

jweinberg commented 13 years ago

I would be curious if its possible to remove the need for that modification.

kstenerud commented 13 years ago

Not as far as I can tell. Building a true static framework requires ProductType "com.apple.product-type.framework.static", which Apple didn't include in the Xcode specification files for iPhoneOS or iPhoneSimulator (that's what the diff files add in). Without those specifications, the best you can do is the relocatable object bundle hack.

Maybe now that I've proven how easily this functionality can be added, Apple will relent and put iOS static frameworks into Xcode.

jweinberg commented 13 years ago

Have you opened a Radar to that effect?

kstenerud commented 13 years ago

http://openradar.appspot.com/radar?id=1194402

kstenerud commented 13 years ago

The latest incarnation side-steps the issue (sort of).

I've re-introduced the "fake" framework templates since I've figured out how to get them to build without embedding build location into the binary, so now you can choose which solution to use.

jweinberg commented 13 years ago

How would I go about linking against the 'fake' version? I can't seem to get Xcode to deal with it in any sane manner

kstenerud commented 13 years ago

I'm not sure what you mean... It should just work by dragging the built framework into your project.

jweinberg commented 13 years ago

Its showing up looking like a standard 'bundle' for me, rather than a framework. Xcode isn't allowing me to add it as a linked file.

kstenerud commented 13 years ago

Can you tell me more about the steps you're taking? I'm doing this:

To test:

jweinberg commented 13 years ago

Ok, so the problem is the FakeFramework target itself isn't linkable. There is no way to use this as a subproject dependancy without some hackery.

kstenerud commented 13 years ago

Right! THAT was the major downside to fake frameworks!

When using a framework project as a subproject, Xcode expects the binary produced to be a library (either static or dynamic), and so the link phase tries to link to it as a library. Since the fake framework is implemented as a relocatable object file, the linker fails to see it.

The only way to successfully link to a relocatable object is via -force_load (which is how I got the unit tests working), but Xcode won't invoke it automatically for a framework dependency, so your only other option is to add it to the linker flags in the project that depends on the framework.

So your choices end up being:

kstenerud commented 13 years ago

Update: -force_load works. You can use it by putting something like this in "Other Linker Flags":

-force_load "$(BUILT_PRODUCTS_DIR)/MyFramework.framework/MyFramework"

It won't get rid of the dependency warning, though.

jweinberg commented 13 years ago

Well thats no fun! Guess I'll have to hold off until apple gets their act together.

jbenet commented 12 years ago

Hey kstenerud,

I just realized I forgot to post here... I found a work-around that sets up a project without having to modify xcode. It's not a strict framework, but actually quite close. It sets up a bundle and manually does all the framework arranging.

The only catch: you have to build for both archs (ios and sim). As in, use the drop down menu and build twice. Perhaps a cleaner way would be to use xcodebuild and have it build both archs as a script.

Works for me; It may work out for you guys too. check it out at my fork: https://github.com/jbenet/iOS-Universal-Framework/blob/master/Real%20Framework/Templates/Framework%20&%20Library/Static%20iOS%20and%20Mac%20Framework.xctemplate/TemplateInfo.plist

It also bundles release tarballs for you :) (only on Release builds)