Re: New Target > Cocoa Framework can't handle .c files. (DO try this at home! -- Easy)
Re: New Target > Cocoa Framework can't handle .c files. (DO try this at home! -- Easy)
- Subject: Re: New Target > Cocoa Framework can't handle .c files. (DO try this at home! -- Easy)
- From: Jerry Krinock <email@hidden>
- Date: Sat, 14 Mar 2009 20:30:48 -0700
On 2009 Mar 14, at 19:46, Chris Espinosa wrote:
The good target uses a prefix file that conditionally #includes
AppKit.h only when building Objective-C code.
I said I had changed the Prefix Header and found that it didn't make
any difference, but since you insist I re-changed it and found that,
ARGHHHH, the Configuration (Debug|Release) in my Target settings
window did not match my Active Configuration. ARGHHH!!! (I don't
remember touching either....are the initial settings different?)
So anyhow, now I have confirmed that you are correct.
The bad target unconditionally uses AppKit.h as its prefix file.
Yes, $(SYSTEM_LIBRARY_DIR)/Frameworks/AppKit.framework/Headers/AppKit.h
And the good target uses:
#ifdef __OBJC__
#import <Cocoa/Cocoa.h>
#endif
It's a performance vs. flexibility tradeoff. Using AppKit.h as the
prefix file increases the odds of reusing an already-built pch
file. But it limits you to .m or .mm files, or as you discovered, C
files declared to be Objective-C.
I have to disagree, Chris. Four hours to track down a problem vs.
five minutes rebuilding a pch file is not good performance. My
Lesson: AppKit.h prefix is evil.
But, thanks anyhow -- have a nice remaining-weekend.
_______________________________________________
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