Re: Partial includes syntax
Re: Partial includes syntax
- Subject: Re: Partial includes syntax
- From: Chris Espinosa <email@hidden>
- Date: Sun, 4 Sep 2005 10:12:06 -0700
On Sep 4, 2005, at 8:09 AM, Andreas Grosam wrote:
On 02.09.2005, at 15:13, Philippe Casgrain wrote:
Le 05-09-02 à 01:23, Andreas Grosam a écrit :
Well, XCode finds the headers, but the compiler doesn't.
I think, you have to specify the path to the xxx/Project/Document
folder in the Header Search Path build settings.
For instance, if your Project folder is located in ~/Develop/ you
may add (space seperated) the following path string in the Header
Search Path:
$(HOME)/Develop/Project/Document
For the record, I have just discovered that if you drag-and-drop a
folder from the Finder into Xcode's "Header Search Paths" window (the
one that comes up when you click "Edit" when the Header Search Paths
is highlighted) will create a folder name with the proper build
variable. For instance, when I drag my "Headers" folder, I get
"${SRCROOT}/Headers" as a Header Search Path. Nice!
As always, i wouldn't rely on a rarely used feature - which exact
function isn't even documented. In fact, in XCode 1.5, this method
does not work reasonable (not tested in XCode 2.1, yet). For instance,
XCode more or less chooses randomly which path variable will be used
as a prefix. It is sometimes SRCROOT, sometimes SYSTEM_CPP, or maybe a
defined source tree, or a source tree which had been defined once, but
has been deleted in the meantime, etc.
In truth, this is an intentional and supported feature, and it's even
documented on page 312 of the Xcode 2.1 User Guide:
"If you are entering file paths, you can simply drag the file or folder
from the Finder into the text field or table, instead of typing the
paths in yourself. Xcode will insert the path to the file. You can also
drag a file, folder, or group reference from elsewhere in Xcode; Xcode
automatically determines the relationship between the path and the
project directory and, if possible, uses a relative path. "
We improved its heuristic a good deal in Xcode 2.1. If you find
behaviors where you get unexpected relative references, please write a
bug.
btw, SRCROOT points to PWD, or to the current working directory, if
PWD is empty or undefined (means to the location where the xcode
project is located). If you move the xcode project relative to your
source root, then the paths get broken, unless you specify PWD.
This is generally misleading, but I think I see where you're coming
from. When you open a project file, Xcode sets the $(SRCROOT) to the
directory containing the project file bundle, and all "unrooted"
references are assumed relative to that. When you build the project,
at each build step Xcode issues a cd to $(SRCROOT) so that things like
unroooted header search paths will be resolved correctly. (For
example, if you have a Headers folder that's peer to your .xcodeproj
bundle, the search path is simply "Headers/")
If you move the project file relative to the sources and headers that
it uses, all "project-relative" references are broken. This happens
most often when your Xcode project file is not in the top-level
directory of what you consider your project. For example, if you have
Fooproj/ that contains Sources, Headers, and ProjectFiles, and your
Xcode project file is in
Fooproj/ProjectFiles/Mac/Xcode/Fooproj.xcodeproj, all your references
will be to "../../Sources/" and "../../Headers/". Moving
Fooproj.xcodeproj up one directory will, indeed, cause these to break.
One solution is to define a build setting that refers to the top-level
project directory relative to the Xcode project file (e.g. TOPROOT =
$(SRCROOT)/../../..), then make your paths relative to $(TOPROOT)
instead of $(SRCROOT). Then if you move the project file, you just fix
up the definition of TOPROOT and things fall into place.
For references in the Groups and Files tree, you can make the top-level
references (like "Sources") project-relative, then all files and groups
under them "Relative to Enclosing Group." So again, if you move the
project file, you just fix up the one project-relative reference, and
all others follow suit.
Chris
_______________________________________________
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