I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
- the app project:
- add to target's Build Phases > Link Binary With Library a product (
libmystaticlib.a
); - set
USER_HEADER_SEARCH_PATHS
to$(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include
;
- add to target's Build Phases > Link Binary With Library a product (
- the static library project:
- add some header files to target's Build Phases > Copy Headers > Public;
- set
SKIP_INSTALL
toYES
.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa
in this case. :(
Solution #2
I have also tried another configuration:
- Xcode preferences:
- set source tree for the static library, e.g,
ADDITIONS_PROJECT
;
- set source tree for the static library, e.g,
- the app project:
- add to target's Build Phases > Link Binary With Library a product (
libmystaticlib.a
); - set
USER_HEADER_SEARCH_PATHS
to$(ADDITIONS_PROJECT)/**
;
- add to target's Build Phases > Link Binary With Library a product (
- the static library project:
- don't add any header files to Public!;
- set
SKIP_INSTALL
toYES
.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa
.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution. Any suggestion how better to link a static libraries?
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location. I set the Public Headers Folder path to ../usr/local/include This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to: $(OBJROOT)/usr/local/include $(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case. Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
How to set up the project linking against the library:
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to
../../Headers/YourLib
In your app config set the Header Search Paths to
$(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code
#import <YourLib/YourFile.h>
Don't forget the
Skip Install = YES
option in your static lib.We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem. This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
Hope it will help someone to not waste a day on this.