Re: Re[4]: Editing pbxproj manually
Re: Re[4]: Editing pbxproj manually
- Subject: Re: Re[4]: Editing pbxproj manually
- From: "Clark Cox" <email@hidden>
- Date: Wed, 6 Jun 2007 11:36:29 -0700
On 6/6/07, Peter Mulholland <email@hidden> wrote:
Hello Clark,
Wednesday, June 6, 2007, 3:00:12 PM, you wrote:
> How is the path not correct? What is wrong with the path? Why do you
> have to re-add the files? Why can't you use the inspector inside of
> Xcode to make your changes.
The path is an absolute path, in this case
"/Code/Domination/Original_Source". It's marked as absolute. If i
change it to Project Relative, all that happens is it becomes
"../../../Code/Domination/Original_Source" which is still not correct.
I cannot edit the path. I see no way to change it other than by
removing the affected files and readding them.
OK, if I understand you, your situation is something like this:
You had a project, where everything was referenced by absolute path
You (or somebody else) moved the project (or copied it to another machine, etc.)
You saw that the paths no longer pointed to the actual source files
(i.e. their names were red in Xcode)
If this is the case (as has happened to me before). Then you can, in Xcode:
1) Select all of the affected files that belong in the same directory
2) Open the inspector (cmd-opt-I)
3) Click "Choose…"
4) Select the directory in which the files are actually located.
At this point, the files should no longer be red (but they still use
an absolute path)
5) In the inspector, change the Path Type popup to "Relative to Project".
If I've understood you, this should get you what you want.
> If there's something that you think you should be able to do within
> Xcode that you can't, then file a bug requesting that the
> functionality be added. (<https://bugreport.apple.com/>, requires a
> free ADC membership).
Well, being able to edit this base path would be a good idea!
Again, if I understand you, the "base path" is exactly what the "Path
Type" popup in the inspector edits.
> Then file a bug with Apple, attach the project bundle, and explain
> exactly what isn't working for you (please be more specific than it
> "screws up"). That's the only way we'll see your problem and be able
> to even start to look at it.
Not sure I can attach the bundle - will have to check that with my
manager.
> Regardless of the file format used, it is not a public format. Even if
> it used XML you couldn't assume that you would be able to meaningfully
> edit it.
Well, I've never had a problem editing .vcproj files!
That may be, but whether or not XML or a text plist is used is
immaterial to whether or not the tool supports people hand-editing it.
> No, all doesn't seem correct. If all seemed correct, Xcode wouldn't be
> displaying the Internal Error dialogs; they're there for a reason.
> Please include the contents of these dialogs in the bug(s) you file.
It "seems correct" because once it's done whining, it compiles OK.
It's only when I try to modify anything in the group where I changed
the path, that it whines again.
It's wining because something is wrong. Once you see that dialog, you
shouldn't try to continue working as you don't know what is wrong with
Xcode's internal state nor do you know how it could affect your data
later on. (I'm certainly guilty of continuing to work after seeing
such dialogs, and it has come back to bite me many times).
I'm also wondering - why doesn't it fix this on save?
Personally, as a user of Xcode, I'm thankful that it does not attempt
to "fix" issues like this. Frequently, when something like this
happens (i.e. corrupt data) there is no way to determine with any
accuracy what the data is "supposed" to be.
--
Clark S. Cox III
email@hidden
_______________________________________________
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