On Mar 8, 2012, at 20:13 , Matt Neuburg wrote:
I'm not sure what you mean by "relative to the project file". Things are not marked "relative to project" but "relative to group". Maybe this isn't the same issue, but that's the thing that I find daunting.
It's just a tree structure with the project at the root, files as leaf nodes and groups as branch nodes. Each node has a subpath attribute, and non-group nodes additionally have a filename attribute.
In the initial project, source file nodes are "filename.c" (or whatever) with path "" relative to their group. The group has path "innerCrud" relative to *its* parent group, which is the project node. The project node has "projectname.xcodeproj" as its filename , and its path is [conceptually via $SRCROOT] "projectname.xcodeproj/..". The actual path to the source filename is just the result of concatenating all the pieces:
"projectname.xcodeproj/../innerCrud/filename.c"
It's all perfectly regular, and it's all relative to the project file in the sense that that if you move it and the "innerCrud" folder, everything still works. The absolute path to the "outerCrud" folder isn't recorded anywhere in the project AFAIK.
If I create a new Xcode project called Crud, I get an outer Crud folder containing the project file and an inner Crud folder; the code files are in the inner Crud folder. Meanwhile, the project navigator shows me this:
Crud [project]
Crud [relative to group, represents actual inner Crud folder on disk]
AppDelegate.h [relative to group]
AppDelegate.m [relative to group]
etc.
The problem here is that the correspondence between the second Crud (the group "folder") and the Crud folder on disk is real. On the one hand in Xcode it's "just a group", so within Xcode you can move files out of it with no harm done (nothing moves on disk, and nothing is lost track of). On the other hand in the Finder it's real, so if you try to do any reorganization there things go pear-shaped: for example, if you were to rename Crud (the inner Crud) in the Finder, Xcode would lose track of all the code files constituting the project. Similarly, if you were to move a code file that's in the inner Crud folder out of it, Xcode would lose track of it.
It's that special status of that inner Crud folder that gives people trouble. Other groups in the project navigation are just groups; they correspond to nothing in the Finder world. But the Crud group, although it isn't blue (it's not a folder reference), corresponds to the Crud folder; it has a path.
I think this is where I'd diverge. The Crud group doesn't have a path, it has a subpath attribute. That attribute tells you where the group's children are, that's all.
And all the files participate in that path (as illustrated by the fact that if you rename the Crud folder on disk, all is lost).
Not at all lost. If you re-choose the group's location via the button in the file inspector, then all the files will be back again.
BTW, I believe this is a design choice. OS X has long had the ability to track files and folders through name changes. Xcode *could* have been designed to use this to follow actual files and folders, but the choice was to base everything on names, not file system objects.
It's not hard to see how that fact could cause a user to freeze up. Once you've seen references go red in the project navigator you're very scared to touch anything ever again.
The problem was that in Xcode 3 and earlier, it was easy to get into a situation where filenames turned red and then Xcode could never recover from that. Specifically, in Xcode 3, when the files turned red, its as if their paths all became "absolute path", so that fixing the parent group didn't put things back to the way they should be. Xcode 4 is much, much better at getting this right.
m.
PS It might also help if the location "relative to group" were a bit more informative. I always feeling like asking: really? What group would that be? And what's the "location" of the group itself to which you are relative? All quite confusing really.
It's recursive. Files are relative to their parent group. Groups are relative to their group parents, with the project node being the parent of the top-level groups.
All of this is under the assumption that every node is set to "relative to group". Setting a node to "relative to project" just omits the intermediate groups from the scheme, and setting a node to "absolute path" has the obvious effect.