Re: Library Location
Re: Library Location
- Subject: Re: Library Location
- From: Richard Charles <email@hidden>
- Date: Fri, 10 Mar 2017 13:20:46 -0700
> On Mar 10, 2017, at 12:21 PM, Quincey Morris <email@hidden> wrote:
>
> 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.
The library is a dylib. It is embedded in the app bundle in Contents/Frameworks.
> The best solution is to add the library *project* to your app project, not the library *product*.
The library comes from third party and has 1,200 source code files and about a dozen include files. If it is added as a subproject to my app project the build time becomes enormous. Other difficulties also arise when doing this. I have tried this workflow and it is intolerable.
> 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.
Shoot! “Xcode doesn’t apply the concept of configurations to external frameworks.” (It would be great if Apple was as succinct and clear and responsive as you are with the English language. Apple should consider hiring you to take charge of their documentation team.) Dang, are sure about this? No wonder I could never get it to work like I wanted. I was hoping that one of magic location qualifiers (Relative to . . .) would fix it.
> 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.”)
Oh dear, that sounds complicated.
> Another approach is to use two app targets, one for debugging and one for releasing, each target linking against a different library.
That may have some merit.
> 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.
This is the approach I might try next. This might be the least painful and the most productive.
Quincey, thank you so much.
--Richard Charles
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden