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: Fritz Anderson <email@hidden>
- Date: Sun, 16 Dec 2007 11:24:04 -0600
On 16 Dec 2007, at 1:09 AM, Rick Mann wrote:
On Dec 15, 2007, at 10:59 PM, Scott Tooker wrote:
From the limited info you have provided, it appears you are trying
to explicitly include a sub-framework's header file.
I bet you have the following in one of your project source files:
#import <CoreGraphics/CGContext.h>
If so, no cookie for you. Unlike Mac OS 9 where you included
individual header files, with Mac OS X you should include the
appropriate framework (or umbrella framework) header, in this case:
#import <ApplicationServices/ApplicationServices.h>
In addition, you should place any such includes in your prefix
header (and only in the prefix header) so it gets precompiled,
resulting in a much faster build.
That's particularly annoying, if it can ONLY be there, because this
is code that I use in multiple projects. If I can put the
appropriate header in the file that actually needs it, then I can
include just that file in my project. Otherwise, I have to not only
include the file, but then be sure to include any headers it needs
in a separate include.
And that's what you should have done, eight years ago. Computers are
faster now; compilers are better. If you #include <Carbon/Carbon.h> in
your precompiled prefix header, your build will go faster than if you
read the text of <Carbon/Dialog.h> (and the text of each file in its
include tree) repeatedly into each .c file that "needs" it. Even if
you #include only the headers that are "needed."
If you want to find a symbol, command-double-click on it. Or use the
global find window, set to "In Frameworks" and possibly "Definitions."
Or select the Project Symbols group at the bottom of the Groups &
Files list, and use the search field to find the symbol in the detail
list.
Editing {YourProject}_Prefix.pch to add one #include line is not a
huge burden. Once you do, you don't "need" to put #includes for dozens
of individual headers in each of your source files. That's surely
worse, and it's accident-prone.
The umbrella #include does not have to be only in the precompiled
prefix. (Though I am reluctant to disagree with Scott Tooker.) You can
(and should) #include the umbrella header in each of your headers that
need symbols from that framework. The umbrella headers are guarded
against reinclusion, it's good documentation, and if the umbrella
isn't precompiled for some reason, your header will still work.
I'd be amazed if the multiple projects in which you use your code
didn't need the same umbrella headers as your code. #include the
umbrellas in those projects' prefix headers, too.
Today, as a practical matter, umbrella #includes are the only way that
work. Not a consideration to ignore, and not reasonably a thing to
complain about.
— F
_______________________________________________
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