On May 22, 2013, at 16:04 , Brian Syme < email@hidden> wrote: That's what I thought too. But the xcode build system allows libraries to mark headers as private, project or public. The public headers are copied to a derived data directory. And this directory is in the default search path. So you would think that's the intended use. Maybe I'm missing something.
The public (and private) headers are copied to the derived data directory because they're a build product, just like object files produced by the compiler. Like object files, that's just an intermediate thing for the build.
If your search path ends up pointing to a derived directory, you should remove that directory from the search path. If you don't, one unintended consequence is that your main project builds always use that particular build configuration, and don't "switch" automatically when you build a different configuration. For example, you might find that you're debugging with the release version of the library, or that you're releasing your product with a debug version of the library.
I can't remember the rules for static libraries (I mostly use private frameworks instead), but you may not need anything in the search paths for libraries included in the workspace, so I'd try that first.
Also IIRC, Xcode 4.6 is better than Xcode 4.5 or earlier at setting up the proper dependency without jumping through hoops. Before 4.6 it seemed easier to end up with the wrong thing. Unfortunately, the way this works isn't very well explained anywhere. In my experience, the best way to configure dependent libraries and frameworks is to use the "+" button in the Link With build phase and choose the library from the list that pops up.
|