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 Alfke <email@hidden>
- Date: Mon, 11 Feb 2008 22:21:31 -0800
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 would help if you could post at least the beginning of the raw
build transcript, up to the first few errors. In the Xcode build pane/
window, click the little show/hide build transcript icon-button at the
bottom, and select everything from the top to where the first error
message appears (that shouldn't be _too_ many lines.)
It would also help if you could hold off on being arrogant to people
who are trying to help you. None of us get paid to do this, you know.
(Like John Cleese in the Argument Sketch, we're arguing in our spare
time.)
—Jens_______________________________________________
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