Re: MORE: What's With XCode and Paths...
Re: MORE: What's With XCode and Paths...
- Subject: Re: MORE: What's With XCode and Paths...
- From: Scott Tooker <email@hidden>
- Date: Mon, 26 Jan 2004 15:02:22 -0800
On Jan 17, 2004, at 9:30 PM, Lance Drake wrote:
> Well - my questions about XCode and file paths have been answered by
> examining the innards of the 'project.pbxproj' portion of the XCode
> project bundle.
>
> If there is a bug related to paths, it appears to be in the reluctance
> of XCode to fully or completely implement the changes dictated by the
> XCode File Info dialog.
>
> Additionally, there are (evidently) some differences in how paths to
> system files are expected and/or interpreted. For instance, what
> works in 10.2.X as a reference to a file is not accepted by XCode. In
> 10.3.X '#include <Kernel/mach/mach_port.h>' is required to be entered
> as '#include <mach/mach_port.h>'.
>
> Another problem I was having was with files located in parallel
> folders.
> With common code supporting three different versions of builds, I have
> directories names <somewhere>/buildA/src, <somewhere>/buildB,
> <somewhere>/buildC and <somewhere>/buildA/proj,
> <somewhere>/buildB/proj, <somewhere>/buildC/proj.
>
> When I modified the buildB and buildC copies of the XCode project
> bundle to point to the buildA directory, there did not seem to be any
> way (using the XCode interface) I could get the buildB and buildC
> projects to see the files in the buildA/src folder. Files whose
> location was referenced (in buildB and buildC areas) as
> "../buildA/src/file.c" could not be found until I manually edited the
> project.pbxproj file and changed the reference from "sourceTree =
> <group>;" to "sourceTree = SOURCE_ROOT;"
Two things:
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).
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).
>
> 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.
>
> 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).
Scott
> ======================================================================
>
> Thanks very much - Here's hoping this note doesn't sound like a
> complaint - because it's not.
>
> 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.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.