Re: Problems with #include "" vs #include <>
Re: Problems with #include "" vs #include <>
- Subject: Re: Problems with #include "" vs #include <>
- From: Chris Espinosa <email@hidden>
- Date: Fri, 19 Dec 2003 15:31:22 -0800
On Dec 19, 2003, at 2:06 PM, Marshall Clow wrote:
I'm spending the day trying to learn Nitrogen, a set of C++ wrappers
for Carbon.
(it's on SourceForge, for those of you who are interested)
It has a set of headers, with names that are the same as a bunch of
the Carbon headers.
So, in my code I have:
#include "Nitrogen/CFDate.h"
[ I have a source tree pointed at the Nitrogen folder, and $(Nitrogen)
added as a search path) ]
Inside Nitrogen/CFDate.h, this is what I see:
#include <CFDate.h> // Include Carbon's CFDate
namespace Nitrogen {
// lots of stuff here
}
The problem is that the line #include <CFDate.h> just includes the
same file again,
rather than getting the system's one. :-(
I tried adding another search path for "/Developer/Headers/FlatCarbon"
in my project,
before the search path for Nitrogen. No difference. I tried hacking up
the command line
passed to gcc (via Other_C_Flags) to contain "-I-
-I/Developer/Headers/FlatCarbon".
No difference. I updated from XCode 1.0.1 to Xcode 1.1. No difference.
How can I convince XCode/gcc to search for files delimited by "" and
<> differently?
[ Obligatory comment: Dang, this stuff is easy in CodeWarrior. ]
Just to cover all the stuff I've tried with Marshall, and to give some
background:
1) The reference to <CFDate.h>, being unqualified, is ambiguous. It
would be better to use <CoreFoundation/CFDate.h>.
2) That makes use of FlatCarbon problematic. This project is intended
to compile for 9 and X, which is why FlatCarbon is used. I've
recommended that they break up the #includes using
#if TARGET_RT_MAC_MACHO
#include <CoreFoundation/CoreFoundation.h>
#else
#include <CFDate.h>
#endif
Because he doesn't own this code base and is just trying to bring it up
under Xcode he's reluctant to go through that much work.
3) I doubt that his desired solution -- having gcc distinguish between
system and user includes better -- would necessarily help in this
situation. There's not really a distinction between system frameworks
and user frameworks; the difference between "" and <> in a Mac OS X
world, even if well-supported by Xcode, wouldn't necessarily solve this
particular problem.
4) We understand that CodeWarrior lets you have separate search paths
for #include <> and #include "", and that it would be helpful for Xcode
to support a similar feature, and invoke gcc's -I- option correctly to
differentiate them.
Given all that, creative hacks to solve Marshall's problem without
making wholesale changes to the Nitrogen codebase are appreciated.
Chris
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.