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?
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.
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 is not quite so. Xcode is more a less a front for build commands issued to gcc. It's certainly in the realm of possibility to set up the proper compiler flags in a makefile such that a command-line make builds the same sources as an Xcode project.
But if you need to do command-line-and-vi development, look into the xcodebuild tool. For the compile/link/debug cycle where you're just editing and adding code to existing files, you can do all that via an ssh connection on an existing Xcode project. People around here do it all the time. svn it down, xcodebuild it to build and deploy, debug with gdb, edit code and re-build and re-deploy, then svn commit the changes back. All without opening the IDE. Of course, making structural changes to the project or changing target settings generally requires the IDE (less so if your settings are all in .xcconfig files), but it's definitely doable.
Chris |