Re: Xcode 4 DerivedData folder and Framework Search Paths
Re: Xcode 4 DerivedData folder and Framework Search Paths
- Subject: Re: Xcode 4 DerivedData folder and Framework Search Paths
- From: Quincey Morris <email@hidden>
- Date: Thu, 30 Jun 2011 10:26:48 -0700
On Jun 30, 2011, at 05:15, Bill Cheeseman wrote:
> What could be the problem? Possible issues:
>
> 1. My build settings still show an old location I used in Xcode 3 for built products, including the Framework Search Paths setting. My understanding is that Xcode 4 ignores these old Xcode 3 build settings and "does the right thing" automatically when the product uses the Xcode 4 DerivedData default location. Is this correct?
The Framework Search Paths setting is not ignored by Xcode 4.
In a project with a similar setup to yours, I have this set to the folder containing the framework project. Note that this isn't the location of the built framework (either intermediate or final), but Xcode figures out the correct location via some magic private recipe. Although the presence of the framework project inside the workspace is the secret sauce that makes this work, it's not the whole reason -- without the Framework Search Path build setting I still get compiler and linker errors.
> 2. I have two workspaces that include the same framework project. One workspace contains only the framework project alone, because i use the framework in several products and want a convenient place to work on it. The other workspace is for this application, and it includes the application project and the same framework project. Both workspaces point to the same framework project folder, and changes I make to the framework project's source code is correctly reflected in the project no matter which workspace I look at.
Are you saying you have both workspaces open simultaneously? Joar made a post on this list a few weeks ago in which he seemed to be saying you shouldn't have the same project open twice at one time, though this deficiency is going to be corrected at some future time.
My framework situation is similar to yours, in that it's shared and I want a convenient place to work on it that's separate from any application that uses it. This works for me because I'm using SCM, and this avoids the above problem.
I have the central git repository on a remote repository provider (BeanStalk), and I have multiple local repositories each tracking the same remote repository. This means that the local Xcode framework projects are each used in only one workspace. The drawback to this approach is that changes pushed from a local repository to a remote repository need eventually to be pulled to all the other local repositories.
(It's a bit messier than this, because the remote repository has multiple branches, and each local repository tracks a different subset of branches. It all works, but keeping my mind wrapped around which branch needs to be pulled where/when is a nightmare.)
Is any of that any help?
_______________________________________________
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