Re: Framework won't link (was: WHy is Xcode such a PITA?)
Re: Framework won't link (was: WHy is Xcode such a PITA?)
- Subject: Re: Framework won't link (was: WHy is Xcode such a PITA?)
- From: Scott Tooker <email@hidden>
- Date: Sun, 16 Dec 2007 11:43:18 -0800
On Dec 15, 2007, at 11:07 PM, Rick Mann wrote:
On Dec 15, 2007, at 10:51 PM, Chris Hanson wrote:
Did you add the framework from / (e.g. from /System/Library/
Frameworks), or did you add it from an SDK directory (e.g. from /
Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks)?
I did. I thought that's what it was for. In the old days, we'd link
against Universal Headers and stub libraries. Seemed to me something
similar was being accomplished with the SDK stuff.
It's unintuitive, but you really need to add frameworks, libraries,
etc. from / rather than from within an SDK directory. The compiler
will automatically tack the SDK directory onto the front of the
path -- that's what -isysroot is for -- and will do so even if the
SDK directory is already tacked onto the front. So be sure that
you dragged ApplicationServices.framework from /System/Library/
Frameworks into your project.
You're right, it's unintuitive.
Yep, right now it is. In the past, an idea I've heard thrown around is
to provide a UI similar to what is done for opening AppleScript
dictionaries. So to add the AppKit.framework, you'd tell Xcode to add
"AppKit.framework" to your project and target, and Xcode would use the
defined SDK to determine the appropriate instance of the framework to
use. Of course, you'd always have the ability to specify a specific
framework on disk to add (for those times when you are using
frameworks that exist outside an SDK).
Also, one other thing I forgot to mention is that you shouldn't
access sub-frameworks directly. If you need to draw using Core
Graphics, just #include <ApplicationServices/ApplicationServices.h>
to get the umbrella header, and it will include all of the
appropriate sub-framework headers to let you draw with Core
Graphics. If you *really* want to access a sub-framework's headers
directly, you'll need to add a header search path that points to
its umbrella framework's Frameworks directory. But be aware that
the real API is actually to include and link against the umbrella
header, and the sub-framework is actually allowed move or change
(within its umbrella) so long as it's transparent to people linking
against and including the umbrella.
This really rubs me the wrong way. I *hate* including a bunch of
stuff I don't really want to use. For one, it makes it a bit harder
to track down the definition of a symbol (when you don't have the
luxury of Xcode's doc features, or it's behaving erratically).
Second, it takes longer/more memory to build. Everyone says this
doesn't appreciably slow things down, but it still consumes
resources. And it rubs me the wrong way.
Before the advent of precompiled headers, you'd be right that you are
eating up more resources, but precompiled headers change the playing
field. Assuming you are only adding headers that change very
infrequently, Xcode/gcc can process the included headers once and
reuse the processed headers again in future builds at little to no
cost. This does point out that you don't want to include or import
headers files in your prefix header that change often (since the one-
time cost of precompiling the prefix header is higher than simply
including the header file directly in your source files). The rue of
thumb I use is that prefix headers should have umbrella headers or
other system headers, but project headers are unlikely candidates
since they change too often.
Scott
--
Rick
_______________________________________________
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