Re[2]: MORE: What's With XCode and Paths...
Re[2]: MORE: What's With XCode and Paths...
- Subject: Re[2]: MORE: What's With XCode and Paths...
- From: Lance Drake <email@hidden>
- Date: Mon, 26 Jan 2004 16:30:07 -0700
Hi Scott,
Thanks you so much for taking the time to address the note I posted
to the XCode list. I also understand that it's important for you to
post a response to the list which admonishes people to NOT edit the
project file.
1) Manually editing the project.pbxproj is SO unsupported. Trust me,
if you file a bug with a badly behaving project and we discover you
hand-edited the project file, the 99+% conclusion will be a message
saying to not hand modify the project file (there have been a handful
of problems that we had to temporarily solve with project file editing
by hand, but it is not a recommended technique).
If we were to be sitting next to each other (maybe via TB2 or Apple
Remote Desktop) we could take a copy of my project and either prove or
disprove my assertion that what I was trying to do via the GetInfo
panel was NOT being successfully implemented in the project file.
Truth be told (please!), I only took to editing the file after spending
a great deal of time trying to overcome the problems via 'legal means'.
The last thing I want to do is have to locate info and perform
tweaking in a huge ppbxproj XML file. Still, your warning is duly
noted.
2) The real way to fix this from the IDE, is to Get Info on the file
reference and set the path to be relative to the project instead of
the group. My guess is that the group that holds these items is either
using the wrong reference style or all the items in the group do not
share a common directory in their path. If the former, you ccould just
fix the group itself and the other references will be fixed ("Relative
to Enclosing Group" just means that the file reference looks to it's
enclosing group when figuring out the actual absolute path for the
reference).
I hear you - but trying ALL possible such 'Relative...' settings did
not provide any remedy for me. Examining the pbxproj file showed that
settings for the item (such as sourceTree = "<WHATEVER>";) were not
changing.
XCode is still an infant with many bugs and I imagine, given time, such
wrinkles will all disappear. However, there's no doubt in my mind that
my project had gotten into some state from which it was not possible
for me to extricate it except by hand-editing. Perhaps part of the
problem is that the material was originally a PB project? It was not
needed to edit the PB version of this project - and all the file
references, etc, were resolving.
BTW - in the case of the mach_port.h file reference, the reference of
the Kernel.framework was massaged to: B6085188045655650001230A = {
fallbackIsa = PBXFileReference;
isa = PBXFrameworkReference;
lastKnownFileType = wrapper.framework;
name = Kernel.framework;
path = /System/Library/Frameworks/Kernel.framework;
refType = 0;
sourceTree = "<absolute>";
};
That fixed the 'cannot find file' error I was getting.
======================================================================
Again, everything you hand-edited here can be properly changed via the
Get Info or inspector windows for the given reference.
I believe you when you say this is the desired/imagined behavior of the
IDE - but this was not my experience.
Which leads me to the question that has now bubbled up to the top of
the list...
Although I describe an 'install location', the final materials
always end up in the 'build' directory which is a GLOBAL reference to
XCODE.
With several difference versions of the same project being
generated - the only difference being which version of the MacOS they
are intended to be run under, what is the suggested method of getting
things to be constructed and deposited into the proper place with
having to set the XCode global preference settings every time you
want to build something?
If you Get Info on the project you can set a per-project location for
both the built products ($SYMROOT) and build intermediates ($OBJROOT)
locations. If you get really tricky you can even set these at the
per-target or per-build style level (though there are bugs with the UI
that you'll run into).
Ah yes - This is really helpful - as has been your entire response.
Again - thanks for your attention to my questions.
Lance Drake
_______________________________________________
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.