Re: Relative paths
Re: Relative paths
- Subject: Re: Relative paths
- From: Patrick Coskren <email@hidden>
- Date: Thu, 19 Feb 2004 17:58:06 -0500
On Feb 19, 2004, at 5:38 PM, Mark Lentczner wrote:
One of the source files contains the line
#include <../../nrnconf.h>
... and it fails to build because XCode can't find nrnconf.h, which
is present two directories up from the source file. If I change the
line to #include "../../nrnconf.h", (quotes instead of brackets) it
works.
I think the source code is in error:
I agree. I'm just looking for a way to avoid fixing every file in the
source. :-) Sorry if I didn't make that clear; I was a little rushed
when I drafted the note.
The locations to be searched by <...> and "..." are different, though
implementation defined. The standard only requires that locations
searched for "..." always include the <...> locations. Traditionally,
<...> searches standard system include directories, while "..." looks
in the source directory first.
Many compilers have switches (perhaps on by default) that treat <...>
and "..." exactly the same.
As far as I can tell, XCode doesn't (though I'd love to hear
differently). What's surprising to me is that if I put my source
directory on the system include directory list, "../../" doesn't seem
to work as a header file path. Hopefully I'm doing something wrong.
But perhaps it's a big or even a feature.
Since your include file is explicitly relative to the source directory
of the source file, the "..." is certainly always correct.
Yup, agreed.
If worse comes to worst, I'll just go ahead, change everything, and see
if I can persuade the maintainer.
Thanks for the help,
-Patrick
_______________________________________________
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.