On Mar 29, 2012, at 09:59 , Conrad Shultz wrote: +1, but a caveat is that I found that at least for me, with fairly
plain-vanilla configurations, Xcode wouldn't find headers for import
unless I manually added ${BUILT_PRODUCTS_DIR} to my user header search
path (and have the headers copied into the build product).
I'm sure there are other recommended ways to do this (especially that
don't involve header copying), and I'd love to hear them. I'm still
getting used to the whole Workspace concept.
I think adding search paths that resolve to anywhere in the derived data folder is a Really Bad Idea (but I'm saying that as opinion, not fact).
Instead, if the additional project is a framework, I've been setting the framework search path (not the header search path) to the folder containing the framework project, and then -- for #imports that appear in the main project -- using the proper <MyFramework/myHeader.h> referencing style.
I've been told that something similar works for regular library projects too, but I'm not using library projects for anything right now, so I haven't had a chance to try it.
The header file thing *is* a bit of a nuisance for private frameworks, but if you classify your framework project .h files properly**, then you just have to add a custom build phase to the apps which deletes the PrivateHeaders folders of the framework after the framework is copied into the app.
It would be nice if Xcode had simple on/off switch for apps that use "private" framework headers, which defaulted to off.
** "project" for headers internal to the framework, "private" for headers used by client apps of the framework but not distributed with the apps, "public" for headers distributed by client apps |