Re: Partial includes syntax
Re: Partial includes syntax
- Subject: Re: Partial includes syntax
- From: Andreas Grosam <email@hidden>
- Date: Sun, 4 Sep 2005 22:42:57 +0200
On 04.09.2005, at 19:12, Chris Espinosa wrote:
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.
I apologize for being a bit harsh, i referred to XCode 1.5 only which
had indeed some issues - and frankly, i didn't try this feature in
XCode 2.1. But i'm going to test it now, if a deleted source tree entry
will still be used in the path when dragging a folder.
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.
So I wonder, if SRCROOT is a good choice to be used as a root path,
when dragging a folder/file to the Header Search Paths entry.
What I'm missing is a user-setable build setting variable which is
dedicated to point to the "user project root" - which is not
necessarily the folder containing the xcode project, but this could be
the default.
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.
Yes, you say it. :-)
So, well, why not introducing a predefined build setting variable -
which then can be used when dragging folders (if located below this
root) into the Header Search Path field?
For instance, having this structure:
~/Develop/Projects/MyProject/SubPrj/headers
and TOPROOT explicitly defined as "${HOME}/Develop/Projects/MyProject"
then dragging the folder "headers" into the Headers Search Path field,
XCode would emit this path string:
"${TOPROOT}/SubPrj/headers"
One problem is however, the best name for this build setting variable
would be SRCROOT, ;-)
(and the former should become XPRJROOT ?)
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.
OK, this method is another good alternative.
I suggested previously to define a "source tree", and subsequently
define paths for top level groups/files relative to this source tree.
When using a source tree and you open the info panel for groups or
files in order to specify the path, then you are able to select - from
the popup - your path to be relative to the source tree path. IMO, this
is in fact a very convenient method.
Andreas
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