Re: Library Location
Re: Library Location
- Subject: Re: Library Location
- From: Richard Charles <email@hidden>
- Date: Mon, 13 Mar 2017 14:47:08 -0600
> On Mar 13, 2017, at 12:26 PM, Quincey Morris <email@hidden> wrote:
>
> On Mar 13, 2017, at 08:37 , Richard Charles <email@hidden> wrote:
>>
>> By default, Xcode stores derived data for all projects in ~/Library/Developer/Xcode/DerivedData. This means that build products for all configurations are in the same directory (Debug or Release).
>
> I don’t understand what/why you’re saying this. Xcode stores derived data for each project in a separate project-specific subdirectory of DerivedData. It stores build products for different configurations in different sub-sub-…sub-directories of the project-specific subdirectory.
The location for Xcode project-generated files is specified in the Locations preference. In this preference "Derived Data:" has a Default value which is ~/Library/Developer/Xcode/DerivedData. Inside this directory is the following directory structure.
~/Library/Developer/Xcode/DerivedData/Build/Products/Debug
~/Library/Developer/Xcode/DerivedData/Build/Products/Release
The final build products for all Xcode projects are located directly inside these folders. They are not put in subdirectories by project. For the Debug configuration you get just the debug product. For the Release configuration you get the release configuration plus the dSYM file if specified.
If you embed a custom library into another project (the main project), when building the main project Xcode will look in these common directories (Debug or Release) for the built configuration product to link against assuming the library *product* file location is specified in main project to be “Relative to Build Products”. A Copy Files Build Phase also needs to be added to the main project to actually embed the library in the app package but it will look here for the proper configuration to embed.
In the main project this works great for Run, Test, Profile and Analyze. You just need to remember to build both the debug and release configuration of the library as needed beforehand. It does not work for Archive. It appears that one of reasons it does not work for Archive is because it’s “final” build products are located in a different directory structure somewhere else. However the problem with Archive can be easily solved by folowing the directions previously given.
I have been using Xcode for some time in this fashion except that I was specifying the file location of the library *product* in the main project in a very difficult manner using a configuration file and specifying the LIBRARY_SEARCH_PATHS for the debug and release configuration. This worked, but I could never get Archive to work.
This new way works much better. Simply select the library *product* in the library project and drag it into the main project. Select the library *product* in the main project and change the Location from "Relative to Group" to "Relative to Build Products” in the file inspector. Run, Test, Profile and Analyze now work as advertised with configurations. When you need to Archive simply follow the directions previously given.
This was all inspired by your statement Quincey "Relative to Build Products is the only file referencing method that takes the build configuration into account”.
> This suggests that Xcode is finding the built libraries relative to the build products of the *library* project …
No, I don’t think so.
>> The only thing that doesn’t work is archiving. Because archiving has a different build directory structure you will get a library linker error "No such file or directory”.
>
> It’s possible this is because you never *archived* the library before archiving the app, so the necessary files were never built. However, even if you do (or did) archive the library, it may still fail, depending on the structure of the library archive vs. the subdirectory contents Xcode is expecting for the app archiving process.
No, I tried archiving the library before archiving the app but it did not work. Using the new method I have described, the archive pulls the library built product from the release directory.
~/Library/Developer/Xcode/DerivedData/Build/Products/Release
> What matters here is that the derived data is per-workspace, not per-project. If you open a project and build it, the build products directory is one subdirectory of DerivedData. If you open a workspace containing the project, the build products directory is a different subdirectory of DerivedData.
Well that is true for some of the data but not all of the data. Final built products are put into a common directory (Debug or Release) for all projects. Workspaces just contain projects so final built products from a workspace are also put here.
> The point of all this is that when you have a complex app bundle that contains components from multiple projects, the correct way to do it is to use a workspace that contains each of the projects. . . .
If I remember correctly, when building, all projects in the workspace are built. When cleaning, all projects in the workspace are cleaned. This also happens with subprojects in a project. For a large complex project this may be a counter productive workflow.
> If that’s intolerable, you can continue doing what you’ve arrived at so far, but be aware that the ice you’re standing on might not be quite so thick as you wish.
Walk slowly on concrete or skate fast on ice. So far it feels like I am skating fast on thick ice. But if not I can always fall back to slower approaches.
--Richard Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden