The workspace with the iOS project and related a static library project

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 iO

Answer 1

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:

• Add a build configuration named "Archive" by copying the Release Configuration.
• Move your headers to the Project group of the Copy Headers build phase.
• Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
• Set Skip Install to YES for all configurations.
• Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
• Edit its scheme, set the Build Configuration of its Archive action to "Archive."

How to set up the project linking against the library:

• Add a build configuration named "Archive" by copying the Release Configuration.
• Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
• Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
• Set Always Search User Paths of "Archive" to YES.
• Set Skip_Install to NO for all configurations.
• Edit its scheme, set the Build Configuration of its Archive action to "Archive."

Answer 2

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.

Answer 3

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.

Answer 4

I could use Core Plot as a static library and workspace sibling, with two build configurations:

Release:

• in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
• in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include

AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):

• in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
• in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders

Hope it will help someone to not waste a day on this.

Answer 5

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.

Answer 6

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.