On Mar 10, 2017, at 10:31 , Richard Charles <email@hidden> wrote:
I am having difficulty setting the location for a linked library that has multiple build configurations and locations.
My main project links to a library and copies the library into the bundle. The library is located in a separate project of my own making.
What does “library” mean? A framework, or an object-code library? Since you talk about copying the library, it seems like you mean a framework.
In principle, it should make no difference which you are using, but Xcode supports frameworks better than it does code libraries, so the same solution might not work for both.
The best solution is to add the library *project* to your app project, not the library *product*. When you tell your app target to link against the library target (e.g. in the project’s Info page), make sure that you specify the library location “Relative to Build Products”, since that’s the only file referencing method that takes the build configuration (Debug or Release) into account. The downside of this approach is that your library is re-build at app archive time. The upside is that it’s much easier to embed a framework library into the final bundle.
If you can’t or won’t add your library project as a subproject of your app, then I think your options are limited. To Xcode, it’s an external framework, even if you have custom build scripts that stuff it into the app bundle, and Xcode doesn’t apply the concept of configurations to external frameworks.
One approach is to use a per-configuration build setting in your app target for the Frameworks search paths setting, entering the appropriate absolute path for each configuration. That should be enough to get your app linked to the correct framework build, but you’re still going to have to figure out how to do the manual embedding properly. (I imagine you can use per-configuration scripts, or have per-configuration build setting tests within scripts, something like. “Left as an exercise for the reader.”)
Another approach is to use two app targets, one for debugging and one for releasing, each target linking against a different library.
Another approach is to choose the library manually. Start out with debug app and debug library, and then actually debug the library functionality until it’s properly tested. Then switch to using the release library on the assumption that you don’t need to debug unoptimized code within the library any more. (Or, if you do, you can switch back temporarily.) Note that you will still have the library symbols available during debugging, even in the library’s archive build, although you may have to issue a debugger command to load the dSYM file if it and the library are not in expected locations.
|