On Apr 27, 2008, at 1:43 PM, Jerry Krinock wrote:
Graham, welcome to the apparently small club (about 3-4 oddballs)
who care about what version and configuration of their private
framework gets packaged or run.
That group includes most everybody. Everybody wants their tools to
work, and that includes building and running against the proper
versions of their frameworks. Please don't presume that just because
you have hit difficulties or bugs that it's because you're the only
one who cares, thanks.
For more info, search [EMAIL PROTECTED] archives for past
month or two. Here are a couple of interesting facts to get you
started:
1. If you set a "Copy Files" Build phase to "Frameworks", Xcode
will always copy the same Build Configuration regardless of which
configuration you're building. I've found it to always copy
Release, but someone else reported that it always copies Debug.
A Copy Files build phase will always copy whatever is pointed to by
the reference you add to the build phase.
* If that reference comes from another project, and you aren't using a
shared build directory, that reference will point off into space. You
need to ensure you're using a shared build directory if you want to
use the product from a cross-project reference.
* If that reference is in a shared build directory and is "build-
product relative" then you need to ensure it has a path like
"MyFramework.framework" rather than "../Debug/MyFramework.framework".
This can happen if your active configuration is Release but you add a
framework from your shared Debug folder; Xcode will do what you say,
not what you mean, in that situation, and construct a relative path to
the Debug folder rather than chop that part off.
If you've been encountering problems copying embedded frameworks, I
suspect you fall into one of the two situations above.
2. Say you set a private framework to build in the normal way, with
Installation Directory = @executable_path/../Frameworks. In the app
project, set the Build Configuration to Debug and Run in Xcode. The
framework that gets run is apparently the one in your Builds
directory, not the one in the app package. However, if you
doubleclick the app's Debug build in Finder, it runs the one in the
app package, which is what I expect it to do in any case. [1]
This is by design. When running a build product, Xcode tells dyld to
first search your built products directory for frameworks and
libraries that it loads. This is because often you will want to do
things like make a change to a framework and then test your
application against that framework without installing that framework
wherever it needs to be installed.
For some people that's "inside the application's embedded Frameworks
directory" but for others that's "in /Library/Frameworks" - hopefully
it's clear that what Xcode currently does is a huge win in the latter
case.
-- Chris
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
