Linking Non-sibling Libraries in an Xcode 5 Workspace

It would be interesting to examine the history of software engineering via solely the history of the process of layering build systems atop each other.

Like any decent human being, your third-party libraries are in a subdirectory in your project folder.


You’ve thus configured your project header import paths, library linking paths, and such with references to ./Externals/.

blahNow, along comes Xcode 5 with its fancy new-fangled ‘workspaces’. If you’re not familiar, Xcode 5 workspaces promises what every build system, ever, has promised: by adding another layer of configuration, we can finally, really, make everything work.

In theory, it’s quite snazzy. Declare your dependencies via the build phase and as long as the library is in your workspace, it will be automatically discovered and built as needed. (Supposedly, it will also properly associate header files and such, but I’ve found that practically, one ends up needing to declare header search paths anyway.)

The dependency analysis works well (at least as well as make) But it turns out that if your dependencies are anywhere but sibling folders, Xcode doesn’t do a very good job putting build intermediates somewhere they’re available for linking, leading to linking errors in any configuration but the command-line default one. Your build logs will show the dependencies being built, so this can be an obscure error to track down.

The solution is simple: manually include ${OBJROOT}/UninstalledProducts as a library search path in the necessary schemas and you’re golden.

Hat tip to Eonil at StackOverflow for the reference to a similar problem in an earlier version of Xcode.