Re: Including specific headers
Re: Including specific headers
- Subject: Re: Including specific headers
- From: Scott Tooker <email@hidden>
- Date: Thu, 1 Jun 2006 16:11:22 -0700
On Jun 1, 2006, at 2:33 PM, Rick Mann wrote:
On Jun 1, 2006, at 12:53 , Chris Espinosa wrote:
While this is not the recommended way to include framework header
files, it is supported. The twist here is that CoreGraphics is a
subframework of ApplicationServices. If you insist on using this
style of #include, you'll have to add "/System/Library/Frameworks/
ApplicationServices.frameworks/Frameworks" as a Framework Search
Path in all configurations for your target that needs this.
What is the recommended way to include framework header files?
The recommended way is to include the umbrella header, in this case
#include <ApplicationServices/ApplicationServices.h>
Futhermore, is there a way to disable the precompiled header so
that I know when I fail to included a necessary header (without by
chance, disabling the ability to find a symbol in the headers via
the contextual menus)?
Just uncheck the "Precompile Prefix Header" build setting in the
Target inspector. But that generally won't have any effect; your
prefix file will still be included implicitly, and if it #includes
an umbrella framework (like <Carbon/Carbon.h> then pretty much
everything you'll ever use will be brought in, too, just more
slowly. You can comment out the framework includes in the prefix
file, but that will probably result in more breakage than you want
to deal with.
The best thing to do is just to give up on worrying about system-
level #includes. The whole point of framework #includes and
umbrella frameworks on Mac OS X is to reduce the hassle of figuring
out what headers and link libraries you need to add in order to use
standard system functionality.
I suppose I may have to. The biggest reason I like to include the
headers specifically is to support browsing the source (or even
compiling it) outside of XCode. Having each relevant header listed
at the top helps one to quickly determine what dependencies a file
has. Adding them as code is added is fairly painless, especially
when the compiler tells you something's undefined.
You are making the assumption that a given header will continue to
exist under the same framework release after release.
One of the points of umbrella frameworks was to provide the developer
a stable way to include the proper header, while allowing for
reshuffling of headers & code in the sub-frameworks without breaking
that developer's code. And yes, such sub-framework headers have moved
around in pervious versions of Mac OS X.
Using the XCode conventions implies I'll be using XCode exclusively
and forever, and I've found that making such assumptions ends up
causing a lot of trouble. I'd like my files to be as independent of
the surrounding IDE as possible. (imagine ssh-ing in and developing
strictly with command-line tools and vi--it would be much harder to
deal with). (Admittedly, framework-style includes requires that much
support from the compiler).
This isn't an Xcode convention, this is a Mac OS X convention (you
should include umbrella framework headers instead of the specific
header regardless of what you use to develop your Mac OS X app).
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
_______________________________________________
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