The workspace with the iOS project and related a s

Question

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;
• the static library project:
  • add some header files to target's Build Phases > Copy Headers > Public;
  • set SKIP_INSTALL to YES.

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;
• 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)/**;
• the static library project:
  • don't add any header files to Public!;
  • set SKIP_INSTALL to YES.

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?

Answer 1

I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.

rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"

This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.