Re: Adding obj-c++ file to carbon project changes preprocessed header file types
Re: Adding obj-c++ file to carbon project changes preprocessed header file types
- Subject: Re: Adding obj-c++ file to carbon project changes preprocessed header file types
- From: Jens Miltner <email@hidden>
- Date: Tue, 12 Feb 2008 09:07:35 +0100
Am 12.02.2008 um 07:21 schrieb Jens Alfke:
On 11 Feb '08, at 9:23 PM, Russ wrote:
There are a bajillion .h files from all kinds of places in my app and
supporting libraries. Messing with every .h file is a non-starter.
That's not what I said. I said to edit the prefix file. Go into the
target build settings and look up what prefix file it's using.
If I create an EMPTY file foo.m and add it to the 100% working
project, adding
that EMPTY file to the build causes the compile to bomb horribly.
That's just
unacceptable. (Removing the file from the build and we're all happy
again.)
The file may be "EMPTY", but the project prefix is implicitly
#included in every source file, and the parsing of that prefix is
failing, probably because it #includes C++-specific declarations.
Therefore it is understandable that adding even an EMPTY file to
your project can cause the overall build of the project to fail --
because the project is not properly set up to compile Objective-C.
I'm not too clear on what the build system is doing---I certainly
don't have a
.pch file I have created in my project, that is something the build
system is
creating.
No, the .pch file really is a source file. Xcode creates a generic
one for you as part of the project template, but it's very often
edited to improve compilation times (especially with C++, which
compiles slowly.) Perhaps someone else working on your project
edited it.
This is a stunningly bad idea if true. 0% scalability, 0%
separability, just a
clean architectural botch.
Whatever. I've been working with mixtures of Obj-C, C and C++ in
Xcode for years and never had to do more than add one or two #ifdefs
in a project's .pch file. If the ISO defines 250 new C-based
languages in the near future, then we might be looking at a
scalability problem, but for the time being the number is three and
likely to remain that way.
It might be worthwhile noting that the prefix file is compiled once
for each language dialect, i.e. if you have C++ files and Objective-C
files in your project, you'll see the prefix file being compiled twice
(well actually, I guess it's compiled once for each unique build
setting, so if you build universal binaries, it's actually compiled 4
times, but that's not the issue here).
Thus, if your prefix file includes C++ and/or Objective-C headers and
_some_ of your files are not Objective-C++, it'll be compiled as non-
Objective-C++ (e.g. C++ or Objective-C). If your prefix doesn't
properly #ifdef the header file inclusion of C++ and/or Objective-C
headers in that case, you'll get compiler errors when the prefix is
compiled for that dialect.
So essentially, your 'mixed' prefix file could look something like this:
#include <stdio.h>
#ifdef __cplusplus
#include <iostream>
#endif
#ifdef __OBJC__
#import <AppKit/AppKit.h>
#endif
BTW: if you _should_ find that a single prefix file doesn't work for
you (and like Jens Alfke, I don't think this situation is likely to
arise), you can always adjust your build settings to _not_ use a
prefix file...
HTH,
</jum>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden